Java Webの学習（8）RESTfulな設計

、 RESTfulな設計

RESTは：のセットを指し建築制約と原則。
RESTfulな：これらの制約と原則満たすアプリケーションを設計するか、それがあります。

RESTの原則

リクエスト間、クライアントとサーバの間の相互作用があるステートレスで。
クライアントからサーバーへの要求を理解するために必要な情報が含まれている必要があり、要求ごとに。
場合は、サーバー要求間の任意の時点で再起動する、クライアントは通知されません。
ステートレスリクエストは、任意の利用可能なサーバによって応答することができるように、クラウドコンピューティング環境に非常に適しています、。
クライアントがあり、データをキャッシュし、パフォーマンスを向上させることができます。

RESTfulな特長

各URIのリソースの一種の代わりに（固有のアドレス）
症状にリソースを操作することにより、オペレーティング・リソース
リソースの症状があるXMLまたはHTML
ユニフォーム・リソース・インターフェース異なるリソースがアクセスに同じインタフェースを使用して、持っていることを操作冪等（GET、HEAD、PUTおよびDELETE操作を、複数の操作の結果が一致しています）
クライアントとサーバー間の要求との間の相互作用があるステートレス、要求を理解するために必要な情報が含まれている必要があり、クライアントからサーバへの各要求。
クライアント使用してGET 、POST、PUTを、DELETE動詞4は、サーバのリソース操作の動作モードを示しています。新しいリソースのためのリソースを取得するために、GET、POST（リソースを更新するためにも使用することができますが）、PUTは、リソースを更新するために使用されますリソースを削除するには、[削除]

ステートレスとステートフル

差：サーバが含まれているか否かを、イニシエータからの二つの同一のリクエストコンテキストを。

ステータス要求があります。一般的な情報要求を保存するために必要とされているサーバは、各要求は、以前のデフォルト要求情報を使用することができます。

一般的なアプリケーション：MSN、オンラインゲームや他のサーバー。各接続のための状態情報を保持するサーバは、各接続コンテキスト情報を送信するための要求を受信したサーバは、ローカルストレージから再生することができます。

ステートレス要求：プロセス・サーバは、自身が格納されているすべての要求において搬送される情報、および他のサーバを処理することができなければならない、と共通の情報がすべての要求のために使用することができます。

一般的なアプリケーション：WEBサーバー。各HTTP要求の前に、ちょうどターゲットURIを取得するために何をしました。

PS：クッキー、認証または識別をもたらすにログインする場合、この一般的なシナリオは、の状態への遷移のステートレスであり、ステートレスの過程で、ステートフルな情報は、コンテキストを維持し、添加されます。

二、 RESTfulなアーキテクチャ

　　定義： RESTfulなアーキテクチャは、リンクされた異なるサービスと事前定義されたインターフェースを用いて形成されたMVCアーキテクチャの改良のためのフレームワークです。RESTfulなアーキテクチャでは、ブラウザはPOSTを使用して、URLリソースへの方法の4種類が指定されたDELETE、PUTとGETリクエストは、CRUD操作しました。そのため、経由RESTfulな URIは、強力な拡張、明確に構造の特徴で、管理し、リソースへのアクセス。

　　構造：フロントエンドサーバーおよびバックエンドサーバーは、二つの部分、サーバーに分割され、フロントエンドサーバーは、ユーザーのためのモデルを提供しないビューを、バックエンドサーバは、フロントエンドサーバ提供するインターフェースを。

　　呼び出さ：ブラウザがフロントエンドサーバーにビューを要求し、AJAX機能によって開始インタフェース要求取得モデルは、ビューに含まれています。

　　◎：

チームを助けるRESTfulなアーキテクチャプロジェクトの開発、導入の並行開発を。
RESTfulなアーキテクチャでは、HTTPリクエストのほとんどは、サーバーの負荷を軽減、フロントエンドサーバーに転送されるので、故障モデルを撮影した後方端面図も提示することができます。

×：

RESTfulなアーキテクチャは、すべてのプロジェクトに適用されないプロジェクトはRESTfulなアーキテクチャを使用しなくても小さい場合、プロジェクトはより複雑になってきています。

三、URI、URL、URN

URI：統一資源識別子抽象的または物理的なリソース文字列を識別します。
URL ：文字列は、リソースの場所を特定するため、ユニフォームリソースロケータの位置情報を指定します。標準のURLが含まれている必要がありますプロトコル、ホスト、ポート、パス
URN ：ユニフォームリソース名は、名前のインターネットリソースである、という概念は今URIに置き換えられました。

URI

構造：

①アクセス機構
②ホスト名リソースに保存されています
③資源自体の名前

例：

https://www.cnblogs.com/riches/p/12069323.html

解像度：

①このリソースは、HTTPSプロトコルを介してアクセスすることができます
ホスト上にある②資源www.cnblogs.com
③一意に識別することができる（/riches/p/12069323.htmlによってこのリソースPSは：これは必ずしも完全なパスではありません）

URL

構造：

①契約
ストレージリソースの②ホストIPアドレス（時には、ポート番号を含みます）。
そのようなディレクトリやファイル名など③ホストリソース特定のアドレス、。

例：

http://127.0.0.1:18083/login/pageInit

解像度：

①このリソースは、HTTPプロトコルを介してアクセスすることができます
②資源は、ホスト上に127.0.0.1:18083
③/ログイン/ pageInitによってリソースにアクセスすることができます

URN

構造：

いいえ固定構造ありません

例：

URN：ISSN：1535-3613（国際標準逐次刊行物番号）

TEL：+ 139-000-12345

解像度：

URN名は、リソースのみが、リソースを検索する方法を指定しません。たとえば：ちょうどあなたがしている人を教えていない、あなたは人の名前を教えてください。

三つの違いとの関係

URIは、比較的広い概念です。
URIは、ロケータ（みなすことができるのURL）、ネーム（URN）、またはその両方。
URLとURIは、リソースが何であるかを定義しますが、URLは、アクセスリソースをどのように定義しています。
URLが特定されているURI、それはURIのサブセットは、一意のリソースを識別するだけでなく、リソースを配置に関する情報を提供するだけでなく。
URNは、何かのアイデンティティを定義し、URLがものを見つけるための方法を提供します。
URN人の名前ととしてURL人のアドレスの代わりに。

参考記事：