SSM + RESTfulな+ ajax-- JavaのWeb開発

　　友人とゲームの時に出席の大学にいくつかの時間前には、単純なWebフォーラムプロジェクトを取得するには、技術の使用は、その上のSSMは、MySQL、アヤックス、jqueryの、htmlとしています。開発時間の初めに分離計画の終了前と後、以前の経験から、私は書き込みをしくじったので。このプロジェクトは、データが含まれていない、バックエンド・インタフェースは、ページを入力するときは、HTMLのフロントエンドに返されるデータを記入したURL、呼び出しインターフェースを提供するために、おそらくHTMLで書かれた優れたフロントエンドです。最後に、プロジェクトの受け入れの際には使用RESTfulなを持っていないよう求めてきた、聞いたけれども、しかし慎重にインターネット上のビットを理解するために簡単なので、理解し、そして記録されませんでした。

RESTfulな何かであります：

　　RESTfulな設計と開発は、ネットワークアプリケーションへの道です。分離アイデアは、フロントのバックエンドを成長し始めた後、フロント静的なページが指定されたデータを取得するために、理解しやすいの設計方法APIを呼び出す必要があり、使用するAPIが問題となり、RESTfulなAPIはの制約を調節するために使用されます。

　　RESTfulな、URLの場所によってリソースは、どのような機能を完了するために、HTTPメソッド（POST、GETなど）によって定義されます。

　　RESTfulなスタイルでは、同じURLを使用して、さまざまなビジネスを実現するために、異なるHTTPメソッド（POST、GETなど）を合意しました。

　　概して

CRUD操作	HTTPメソッド
作ります	役職
読んだ	取得する
更新	PUT / PATCH
削除	DELETE

　　以前は、データは次のようになります:(コントローラクラスの増加は、外側RequestMappingで宣言され、実際のアクセスURLはポスト/ addPostする必要があります）

1  / ** 
2       *发帖
 3       * @paramのポスト
 4       * @return 
5       * / 
6      @RequestMapping（値= "/ addPost"は、= "アプリケーション/ JSONを、文字セット= UTF-8"を生成）
 7      パブリック@ResponseBodyストリングaddPost （HttpSessionのセッション、RequestBodyポストポスト@）{
 8          // 具体操作省略
9      }

AJAXを使用したフロントエンド、アクセス/ addPost URLはデータを増やすために実施。

　　Spring4.3後、RESTfulなスタイルをサポートするために、@ PutMapping、@ GetMapping、@ DeleteMapping、@ PostMappingこれらのノートを追加し、直接属性が結合法を@RequestMappingすることができ、データの最初の増加があることができます：

1   @PostMapping（値= "/ {ID}" ）
 2      公共@ResponseBodyストリングaddPost（ロング@PathVariable ID）{
 3つの          // データ処理    
4      }

　　このような機能は、唯一増加したデータアクセスPOSTポストを介して達成することができます。

RESTfulな仕様

　　1、パラメータの命名

　　　　パラメータこぶ命名法や下線名前。

　　2、URLの命名規則

　　　　RESTfulなアーキテクチャでは、各リソースのURLを表し、それぞれがリソースのURLのURLを表すので、唯一の名詞を動詞を持つことができない、また、複数名詞を使用する必要があります。実装は、これらのリソースを操作することができ、適切な動詞のHTTP GET、POST、PUT、PATCH、DELETE、HEADを使用する必要があります

非標準のURL、冗長性は意味がない、フォームが固定されていない、別の開発者は、呼び出す前に文書を理解する必要があります。
https://example.com/api/getallUsers GET 获取所有用户 
https://example.com/api/getuser/1 GET 获取标识为1用户信息 
https://example.com/api/user/delete/1 GET/POST 删除标识为1用户信息 
https://example.com/api/updateUser/1 POST 更新标识为1用户信息 
https://example.com/api/User/add POST 添加新的用户 
RESTfulなURLの仕様の後、HTTP動詞と名詞のユーザーに応じて読める定形は、これらのリソースを操作することができます
https://example.com/api/users GET 获取所有用户信息 
https://example.com/api/users/1 GET 获取标识为1用户信息 
https://example.com/api/users/1 DELETE 删除标识为1用户信息 
https://example.com/api/users/1 Patch 更新标识为1用户部分信息,包含在body中 
https://example.com/api/users POST 添加新的用户

　　3、復帰への統一データ・フォーマット

　　　　　正当な要求を含むべきであるそのようなJSON返されたデータとして、統一されたデータフォーマットを返すべきです。

　　　　　　　コード - HTTPレスポンスステータスコードの整数タイプを含みます

　　　　　　　ステータスは - テキストが含まれています：「成功」、「失敗」または「エラー」。、「失敗」として500-599の間の応答のHTTPステータスコードが「エラー」400から499までの間、他は（ステータスコード1XX、2XX、及び3XXに応答して、例えば：）「成功」です。この事実は、中に起こることができない実際の状況に基づいています。

　　　　　　　表示エラーメッセージに使用された場合message--状態は「失敗」と「エラー」が効果的です。一方のみ、または両方を含むが含まれており、セパレータで分離されてもよい情報の番号またはコードを含んでいてもよい国際（il8n）標準を参照します。

　　　　　　　応答を含むdata--体。状態が「失敗」または「エラー」である場合には、構成するデータは、エラーまたは例外名の原因、またはnullも可能です。

正常な応答JSON形式を返します。

1  {
 2    "コード"：200 、
 3    "メッセージ"： "成功" 、
 4    "データ" ：{
 5      "userNameに"： "123456" 、
 6      "年齢"：16 、
 7      "アドレス"： "北京"
 8    }
 9 }

失敗応答形式のJSONを返します。

1  {
 2    "コード"：401 、
 3    "メッセージ"： "エラーメッセージ" 、
 4    "データ"：ヌル
5 }

　　4、HTTPステータスコード

1 **の要求は成功しませんでした
リクエストが成功した2 **、ステータスコードの処理が成功した要求を示します。
3 **要求は、要求を満たすために、リダイレクトされるさらなる操作の必要性を示しています。一般的に、リダイレクトのためにこれらのステータスコード。
4 **リクエストエラーステータスコードは、処理サーバを防止する、要求が間違っている可能性が示しています。
5 **（サーバーエラー）これらのステータスコードは、要求を処理しようとしているときに内部サーバーエラーが発生したを示しています。これらのエラーはありませんリクエストで、間違ったサーバー自体であってもよいです。

　　この記事では、設計仕様の非常に詳細な説明を文書化

　　　　　https://github.com/Highflyer/REST_API_DESIGN_GUIDE

　　エラーがある場合だけ、インターネット後のこの記事では、大物が指摘することができるようにしたい、自分の書かれた個人的な理解を理解します