RESTfulなWebサービス
全体として適用される場合RESTアーキテクチャは、制約のセットを提供し、それがカプセル化レガシーシステムを残し、相互作用成分スケーラビリティ、独立した展開汎用性、インタフェースコンポーネント、および対話待ち時間を低減するため、強化されたセキュリティを重視します中間部品。
リチャードソン成熟度モデル
レベル0：それはURI HTTPすべての要求を処理するための方法は、非常に混乱して使用してRESTに実質的に全く使用しない
が、区別するために、リソース要求、またはURIのHTTPオペレーションすなわちA処理要求の使用：レベル1
レベル2：ポストプロセッシングを扱うときにどのようなURLを言う異なるHTTPMETHODを区別し、その取得する
レベル3：ハイパーメディアハイパーメディア・ドライブを使用します
RESTfulなWebサービスを実現する方法
次のカテゴリに分類：
- リソースを特定
- 適切なリソースの粒度を選択
- デザインURI
- 適切な方法とHTTPリターンコードを選択します
- デザイン・リソース表現
リソースを特定
- 名詞のエリア検索
•使用名詞のCRUD操作
などに使用される前とcoffeeorder操作が行わコーヒーHTTPなどを - 組織は、リソース（すなわち、リソースの集合）の集合体である
、すべてのコーヒーはコーヒーが一緒に配置されるすべてのcoffeeorderのコレクションを入れているとして一緒なcoffeeorderのコレクションです - 複合リソースにまとめたリソース
セットとリソースの複合セットを形成するためのコーヒーですcoffeeorder - 計算や管理機能を処理する
よう、上海から北京に計算され
適切なリソースの粒度を選択
検討して、ビューのサーバー点を立ち
- ネットワーク効率の
多くのもののような、ネットワークの相互作用の過程で - どのように多くの表現
どのくらいのデザイン表現 - 使いやすクライアント
クライアントを使用することが便利ですか
検討して、クライアントの観点に立ち、
- キャッシュ可能性
どのくらいの頻度で更新されたキャッシュを許可されている場合など、キャッシュを許可するかどうか - 周波数を変更します。
- 変動の
情報は、変数であります
より良いURIを構築
- 論理グループや部門への資源のドメインやサブドメインを使用します
- デリミタは、リソース間の階層関係を表すために、URIパス（/）の一部をスラッシュ
- （;）、コンマ（、）とセミコロンURIパスの一部に非階層要素を表すために
- 長いパス（具現化ハンプルール）の名前の読みやすさを改善するために、アンダースコア（_）ハイフン（ - ）を使用します
- パラメータを分離するために使用URI問合せ部「および」記号（＆）で
- 避けファイルの拡張子は、URIに表示されます（例の.php、.aspxのとは.jsp）
HTTPメソッドの理解
べき等：私はリソース要求を要求した回数に関係なく同じである
安全性：私は、コンテンツのさまざまなリソースを変更しないだろう
と組み合わせて、HTTP URIの方法
HTTPステータスコードの理解
すべてのステータスコードの状態の初めに2が成功したコードです
ジャンプして、関連するすべてのキャッシュリダイレクトステータスコードを始め、すべての3つのステータスコード
のすべての4ステータスコードクライアントエラーステータスコードに始めている
すべての5つのステータスコードの始まりをすべてのサーバーのエラーステータスコード
適切な表現を選択
次のカテゴリに分かれて：
JSON（メイン）
- MappingJackson2HttpMessageConverter
- GsonHttpMessageConverter
- JsonbHttpMessageConverter
（読み取りを与える）XML
- MappingJackson2XmlHttpMessageConverter
- Jaxb2RootElementHttpMessageConverter
HTML
いるProtobuf
- ProtobufHttpMessageConverter
