RESTインターフェースを介したVMのシャットダウン
これは実際には2009年にティム・ブレイが発表したやや有名な例です。
問題について議論しているロイ・フィールディングは、この見解を共有しました：
私は個人的に、監視状態（電源ステータスなど）を編集不可として扱うシステムを好みます。
つまり、監視状態の現在の表現を返す情報リソースが1つあります。その表現には、その状態への変更を要求するフォームへのハイパーメディアリンクが含まれる場合があり、フォームには（各）変更要求を処理するリソースへの別のリンクがあります。
セス・ラッドはこの問題に関する重要な洞察を持っていました
ランニングを、人の単純な状態から、作成、更新、話し合うことができる真の名詞に変えました。
これをマシンの再起動に戻します。/ vdc / 434 / cluster / 4894 / server / 4343 / rebootsにPOSTすることをお勧めします。投稿したら、この再起動を表すURIがあり、ステータスの更新のためにそれを取得できます。ハイパーリンクの魔法により、再起動の表現は再起動されるサーバーにリンクされます。
URIスペースの作成は安価で、URIはさらに安価だと思います。名詞としてモデル化されたアクティビティのコレクションを作成し、POST、PUT、およびDELETEを実行します！
RESTfulプログラミングは、Web規模でのVogonの官僚主義です。あなたはどのように行うのですか何のRESTfulは？新しい書類を作成し、書類をデジタル化します。
やや手の込んだ言語では、「VMをシャットダウンする」ためのドメインアプリケーションプロトコルを定義し、そのプロトコルを公開/実装するために必要なリソースを特定しています
あなた自身の例を見る
PATCH /api/virtualmachines/42
Content-Type:application/json
{ "state": "shutting down" }
それで大丈夫です; リクエスト自体を個別の情報リソースとして扱っているわけではありませんが、管理することはできます。
変化の表現を少し見落としています。
ただし、PATCHの場合、囲まれたエンティティには、オリジンサーバーに現在存在するリソースを新しいバージョンを生成するためにどのように変更する必要があるかを説明する一連の命令が含まれています。
たとえば、JSON Patchメディアタイプは、JSONドキュメントを直接変更しているように命令をフォーマットします
[
{ "op": "replace", "path": "state", "value": "shutting down" }
]
あなたの代替案では、アイデアは近いですが、明らかに正しいわけではありません。 PUTは、ターゲットURLのリソースの状態を完全に置き換えるものであるため、単一のエンティティの表現のターゲットとして、コレクションのようなスペルを選択することはおそらくないでしょう。
POST /api/virtualmachines/42/actions
キューにアクションを追加するというフィクションと一致しています
PUT /api/virtualmachines/42/latestAction
キュー内のテールアイテムを更新するというフィクションと一致しています。この方法で行うのは少し奇妙です。最も驚きの原則では、すべてのPUTを1か所にまとめて複数のリソースを同時に変更するのではなく、各PUTに固有の識別子を与えることをお勧めします。
URIのスペルについて説明している限り、RESTは気にしません。/cc719e3a-c772-48ee-b0e6-09b4e7abbf8bは、RESTに関する限り、完全なcromulent URIです。変数名と同様に、読みやすさは別の懸念事項です。RFC 3986に準拠した綴りを使用すると、人々はずっと幸せになります。
CQRS
複数の集約の更新につながる可能性のある、または具体的なリソースとサブリソースのCRUD操作にマッピングできない「アクション」（別名コマンド）が多数あるCQRSドメインがある場合はどうなりますか？
CQRSのGreg Young
CQRSは、他の方法では存在しない可能性のあるアーキテクチャの多くの機会を可能にする非常に単純なパターンです。CQRSは結果整合性ではなく、イベント発生ではなく、メッセージングではなく、読み取りと書き込みのモデルが分離されておらず、イベントソーシングも使用されていません。
ほとんどの人がCQRSについて話すとき、彼らは実際にアプリケーションのサービス境界を表すオブジェクトにCQRSパターンを適用することについて話します。
HTTP / RESTのコンテキストでCQRSについて話していることを考えると、この後者のコンテキストで作業していると仮定するのは合理的なように思えます。
驚くべきことに、これは前の例よりもさらに簡単です。その理由は簡単です。コマンドはメッセージです。
Jim Webberは、1950年代のオフィスのアプリケーションプロトコルとしてHTTPを説明しています。メッセージを受け取って受信トレイに入れることで作業が完了します。同じ考えが成り立ちます-フォームの空のコピーを取得し、私たちが知っている詳細を記入して配信します。タダ
具体例で可能な限り多くのコマンドを具体的なリソースで作成または更新し（例Iの最初のアプローチに従って）、残りの部分に「アクションエンドポイント」を使用してみてください。
はい、「具体的なリソース」がドメインモデルのエンティティではなくメッセージである限り。
重要なアイデア：REST APIはまだインターフェースです。クライアントがメッセージを変更しなくても、基礎となるモデルを変更できるはずです。新しいモデルをリリースすると、ドメインプロトコルを取得して新しいモデルに適用する方法を知っているWebエンドポイントの新しいバージョンをリリースします。
CQRSモデルは、APIのようなRPCにより適していますか？
実際はそうではありません-特に、Webキャッシュは「最終的に一貫した読み取りモデル」の優れた例です。各ビューを個別にアドレス指定可能にし、それぞれに独自のキャッシングルールを設定すると、多くのスケーリングが無料で提供されます。読み取りに対する排他的RPCアプローチには比較的魅力がありません。
書き込みに関しては、より厄介な質問です。すべてのコマンドを単一のエンドポイントまたは単一のエンドポイントファミリーの単一ハンドラーに送信することは確かに簡単です。RESTは、エンドポイントがクライアントに対してどこにあるかを見つける方法を本当に重視しています。
メッセージを独自のリソースとして扱うことには、PUTを使用できるという利点があり、メッセージの処理がべき等であるという事実を中間コンポーネントに警告するため、エラー処理の特定のケースに参加することができます。（注：クライアントの観点から、リソースが異なるURIを持っている場合、それらは異なるリソースであることに注意してください。すべてがオリジンサーバー上で同じリクエストハンドラコードを持っている可能性があるという事実は、ユニフォームによって隠された実装の詳細ですインタフェース）。
フィールディング（2008）
また、上記はまだ完全にRESTfulではなく、少なくともこの用語の使用方法に注意してください。私がやったことは、RPCにすぎないサービスインターフェイスの説明だけです。RESTfulにするには、ハイパーテキストを追加してサービスを導入および定義し、フォームやリンクテンプレートを使用してマッピングを実行する方法を説明し、視覚化を便利な方法で組み合わせるコードを提供する必要があります。