web-dev-qa-db-ja.com

RESTful API、ステータスの変更とイベントを実装する最良の方法は何ですか？

たとえば、「注文書」のステータスを「下書き」から「送信済み」に更新する必要があります。これを行う最良の方法は何ですか？

クライアント側のステータスフィールドを更新してから、POSTエンティティ全体を/ purchase_order/1に更新しますか？

そして、イベントはどうですか？たとえば、すべての注文書が「送信済み」に設定されるようにトリガーしたいのですが、エンドポイントとクライアントの責任の観点から、これに対するベストプラクティスは何ですか？

restclient-server
6
wnoveno

「REST部分更新」をググるとたくさんの意見が寄せられます。

とは言っても、私の考えをお伝えします。

リソースの完全な更新にはPUTを使用する必要があるため、/ purchase_order/1へのPOSTの方が適切な1つのパラメーターのみを変更し、ステータスフィールドを下書きから送信済みに変更した/ purchase_order/1へのGETの最近の結果。

別のオプションとして、PUTを/ purchase_order/1/statusに送信された値で送信することもできます。これは、サーバー側でリソースPurchase_orderのサブリソースステータスの更新として解釈されます。/purchase_order/1リソースをポイントして303を返すことで、クライアントが操作したリソースとは異なるリソースが変更されたこと、およびそのリソースの場所をクライアントに知らせることもできます。

PATCH動詞を検討することもできますが、セマンティクスに正しく従っている場合は、要求された状態を送信するだけでなく、適用する一連の操作をリストするように指定するコンテンツタイプを送信する必要があります。

アクションに副作用がある場合は、APIでこれを明確にする必要があります。したがって、べき等になるように設計されたPUTを使用するときは注意してください。

5
Encaitar

これをチェックしてください Stackoverflow 質問。

基本的に、2つの可能性があります。

  • PATCHリクエストを使用する
  • 更新する部分データを含むPOSTリクエストを使用して、303 HTTPステータスコードを返します。これは、POST要求が実行され、リソースが変更されたことを示すために使用されます。これは、変更されたリソースの場所も返します。

私のアプリケーションでは2番目のアプローチを使用しています。例えば。変更された注文の場合：

{
  "id": 1,
  "status": 2
}

次に、サーバーで注文を変更し、変更された注文の場所を含む303ステータスコードを返します。

イベントの場合：理論的にはREST方法論に正確に従うために、各注文に対してPOST変更されたステータスのリクエストを作成し、ただし、実際には、変更された注文の配列をサーバーに送信し、リソースの場所のリストを受け取ることができます。

1
devz