RESTリチャードソン成熟度モデル

リチャードソンサービス成熟度モデルは、彼は、アプリケーションが4つのレベルに分かれてREST、RESTサービスの規範モデルと発展パスを説明します。

レベル0

唯一の伝送チャネルとしてHTTP

レベル1

センターのためのリソース

レベル2

HTTPを使用アクションセマンティクス

レベル3

ハイパーメディアの使用を制御

RESTサービスの実装の段階及びプロセス仕様の4レベルの記述。モデル全体を4つのレベルに分割されているが、一般的に、実際には、第三の層を達成するために、第4層部分の到達は、実質的に全体のAPI構造が明確で一貫した維持することを可能にします。入口APIの変更の一般的な部分、APIの変更に対応する他のほとんどのエントリと一緒にリソースへのリンクに加えて、いくつかは実現することができるLEVEL3。

理解のこれらの4つのレベルについてのトーク：

レベル0

レベル0の要件は、選択された送信モードを統一輸送モードだけでなく、フォローアップのより高いレベルの基盤へとしてHTTPを使用します。

レベル0は、HTTPを使用する方法を指定しませんので、レベル0のサービススケジューリングスタイルは、さまざまな方法することができたときに、表現は変えることができる、例えば：

RPCスタイルのURL

次のようなスタイルを作成するには、RPCのURLは次のようにすることができます
```
 http://example.com/createUser?name=foo
 http://example.com/getOrder?id=bar
```
リンク多様なリソースへのリードは、リンクが一度だけ使用することができますこの方法では、呼び出し側は常に、対応するドキュメントを検索する必要があります
動きを制限することなく、ステータスのhttp

ムーブメントには、タスクのhttp制限は、リソース制限の明確な状況が存在しません
```
 GET http://example.com/createUser?name=foo  404
 GET http://example.com/getOrder?id=bar      200
```
リソースとアクションのhttpセマンティック紛争の取り扱い、それが唯一のGETメソッドは、完全にHTTPのセマンティクスを活用しませんでした。

ステータスコード404は、元のユーザーが存在しない、または障害が作成することを表し、人々が曖昧になることを示していますか？

レベル0は、成熟度の非常に低いレベルであるレベル0でユーザーに良い経験をもたらすことはできません。HTTP呼び出しを行うための方法を知っているユーザーが、コール各インターフェイスには、戻り値のスタイルの一貫性のない、対応するインターフェースのドキュメント、URLスタイルとインターフェイスパラメータを参照する必要があります。

レベル1

リソース中心：LEVEL1は、多くの変更を持っていました！

資源の中心として機能するには、入り口には、リソースの管理周りのソリューションを提供するための希望のプロバイダとユーザインタフェースがあります。インタフェースの設計におけるプロバイダ、最初のリソースが外部に露出されているかを考え、ユーザーが使用している場合は、最初にあなたがリソースにアクセスしたいのかを検討します。

リソース・センターは、デザインのURLに反映されます。

/users/
/users/?name=foo
/users/1
/orders/
/orders/1

各露出インタフェースは、リソースは、そのようなユーザーのセット、単一ユーザとして、第1の構造で示されます。（ここでは物議を収集するために、一部の人々は、それはタイプを示すために、単数形であるべきだと思う、一部の人々は、表現のセットを使用することを好む複数の利用は、個人のコレクションを表していると思います）。

リソースに基づいて、あなたは適切なクエリのフィルタ条件を追加し、そのページの参照下にすることができます。

これは、リソースの演算の結果がなく、カプセル化の結果は、複数の意味表現ある程度、一般的なリソースで表される返します。

レベル2

HTTPプロトコルは、アクション、クエリ、ハイパーリンクは、http、資源中心のモデルは、優れたフレームワークを提供して与えることで、良好な応答コードが行くように、リソース中心のモデルにマッピングされていることができます。

httpプロトコルを最大限に活用するには、一貫性のないデザインの多くを減らすことができます。

HTTPアクションマップが動作するためのリソースを提供します：

GET     获取资源，无副作用，具备幂等性
POST    创建资源，有副作用，不具备幂等性
PUT     创建或更新资源，有副作用，具备幂等性
PATCH   部分更新，有副作用，具备幂等性
DELETE  删除资源，有副作用，具备幂等性

しかし、運転状態のリソースを変更します、これは副作用です。結果は同じままときに、これは多くの意味を実現するための冪等分散環境、冪等と呼ばれています。

この2つの概念が露出し、HTTP動詞の種類を使用するためにどのようなアクションを決定するのに役立つことができます。

クライアントの一部は、アクションの完全なリストをサポートしていない、我々は隠されて、フォームでは、このような春の隠された方法の方法として、支持体上にいくつかの代替方法を使用する必要があることに注意してください_methodサーバー側HiddenHttpMethodFilterと相まってアクションは、共同でサポートしているフィールド：

<form method="POST" action="/users/1">
    <input type="hidden" name="_method" value="PUT">
</form>

一例として、天候にリソース、システムは、クエリが、天候の状態を変更しない、あなたは以下の方法を使用することができ、天気予報APIのクエリを提供します

GET /weather/

しかし、このURLは、各地域の電力要件を満たすことができない、天気は毎日違うので、一緒に地域と時間と

GET /weather/cn/guangzhou/20191201

このようなURLの冪等は、各クエリの要件はある程度同じ結果を得ることができます満たすことができる、それはまた、ブラウザやCDN上にキャッシュすることができます。

応答コードで、それはまた、一般的なHTTPのセマンティクスと整合的であるべきです

200 成功
404 找不到资源
301/302 永久/临时转移

レベル3

REST全体の構造に基づいていくつかのレベルの前、と非常に明確であるが、問題の処理が行われていなかった：リソースの位置変更、外部リソースへの参照。

アップグレードでは、資源のありそうな場所は、他の場所に転送されます放棄されることがあります。リファレンスリソースに、むしろ単にJSON又はXMLデータより、表現を連結するいくつかの方法を使用する必要があります。

REST関連書籍では、このようにHATEOAS（アプリケーション状態のハイパーテキストとしてザ・エンジン）を参照するには、リソース間をナビゲートするためのリンクと、対応するリンク・リソースに結合されています。

このように、スマートクライアントは自動的に対応するリソースを見つけることができるように、ある程度実装することができます。

春-HATEOAS上の例を参照してください。

{
  "_links": {
    "self": {
      "href": "https://myhost/person/1"
    },
    "curies": {
      "name": "ex",
      "href": "https://example.com/rels/{rel}",
      "templated": true
    },
    "ex:orders": {
      "href": "https://myhost/person/1/orders"
    }
  },
  "firstname": "Dave",
  "lastname": "Matthews"
}

リソースは、現在のサービスノードに含まれていないクライアントが正常にこのリソースを見つけることができるように、注文の全体の外観は、HALの方法を使用すると、このリソースへのリンクを示します。

レベル3の実装は比較的少ないAPIのほとんどが唯一のJSONの結果を必要とする、前述したように、複雑になるが、それはシステムコールを横切ることになるならば、HATEOASは避けられないピットです。

ない銀の弾丸

成熟度のこの4つのプログレッシブレベルは、私たちの思考のREST APIの設計を導くのに役立ちますが、システムのニーズの実態は多様であり、そしてどれもどこでも無敵のソリューションを適用することはできません。

システムの極端な性能要件については、組み合わせて使用するのに適切でないかもしれないのhttp +はJSONを休ま、あなたはよりコンパクトなRPC + protobuffプログラムを使用したい場合があり、レガシーシステムとの統合も、いくつかの技術的なアーキテクチャを考慮する必要があり、何の脳は、RESTを選択しません。リアリティシステムは常にさまざまなシナリオでオフを取引する私たちを必要とします。