CANCELアクションをRESTfulな方法でモデル化するにはどうすればいいですか？

Question

現在、私たちはモノリスから小さなサービスを争っています。私たちのドメインは発券システムと非常に似ています。私たちは、ドメインの取り消し処理から始めることを決めました。

キャンセルサービスにはチケットのIDを取り込む単純なエンドポイント「キャンセル」があります。内部的には、IDを取得し、それに関連するいくつかの操作を実行し、ストア内のエンティティの状態を更新します。ストアの観点からは、キャンセルされたチケットとライブチケットの唯一の違いはいくつかのプロパティです。

私が読んだものから、PATCHはリソースで唯一の単純なプロパティを更新していますように、この場合に使用する正しい動詞のようです。

PATCH /api/tickets/{id} 
Payload {isCancelled: true} 

ただし、isCancelledはエンティティの実際のプロパティではありません。エンティティの一部ではないペイロード内のプロパティを送信するのは公正でしょうか、またはこのリクエストをモデル化する他の形式を考えるべきですか？それが大きいので、ペイロードの一部としてエンティティ全体を送信したくありません。

私は新しいリソースCancelledTicketsを作成すると考えられてきたが、私たちのドメインで、我々はキャンセルチケットのGETへの必要性を持っていることはありません。したがって、すべてのヘルプは大幅に

おかげK

Answer 1

正確RESTful wayが何であるかを見てみましょう をいただければ幸いです

新しいリソースを作成することから離れていました。チケットを消したい場合はisCancelledのペイロードとしてPATCHリクエストを送信しても、DELETEを送っても問題ありません。それでもRESTfulです。

あなたの必要に応じて移動します。あなたは

を言ったように、私は新しいリソースCancelledTicketsを作成すると考えられてきたが、私たちの ドメインに我々はキャンセルチケットのGETへの必要性を持っていることはありません。

DELETEを送信します。あなたは物理的にそれを削除する必要はありません。取り消すことができない場合は、isCancelledの仕組みを実装してください。それは単に味の問題です。リソースのGETインタフェースを公開

Answer 2

は必須ではありません。例えば

、キャンセル要求を提出する

PUT /api/tickets/{id}/actions/cancel 

を使用しています。実際には複数のキャンセルリクエストが存在することはないので、PUTを選択します。

希望すると便利です。