web-dev-qa-db-ja.com

RESTful-DELETEレスポンスボディには何を含めるべきか

ユーザーを取得できるAPIがあるとします。

GET /RESTAPI/user/

また、次の方法でユーザーを削除できます。

DELETE /RESTAPI/user/123

DELETEの応答本文に含めるべき内容についてRESTful規則とは何ですか？これは、ID 123のユーザーをもう含まないすべてのユーザーの新しいリストになるはずだと思っていました。

周りをグーグル検索しても満足のいく答えが得られませんでした。私はそれを行う方法についての意見だけを見つけましたが、RESTfulサービスの厳密な定義はありませんか？

これは の複製ではありません。RESTfulAPI POST/DELETEは本文で何を返す必要がありますか？ および What REST PUT/POST/DELETE呼び出しは、慣例によって返されるべきですか？ この質問はDELETEに関する厳密な定義を要求するためです。

resthttprestful-url
40
tmuecksch

難しい答えが得られない理由は、RESTfulな難しい標準がないためです。したがって、ハード標準を作成し、独自のAPI内でそれに従うことをお勧めします。

これをRESTfulサービスのガイドとして使用しました http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

204ステータスと空のボディで応答すると言います

私はこれらの標準に固執し、私のAPIを使用したい人のためにそれらを適切に文書化します

44
Leon

204 No Contentは、DELETEの人気のある応答であり、場合によってはPUTも応答します。

ただし、HATEOASを実装している場合は、フォローするリンクを含む200 OKを返す方が理想的です。これは、HATEOAS REST APIがクライアントにコンテキストを提供するためです。削除コマンドを正常に発行した後、ユーザーアプリケーションが移動する場所を考えます。これについてのさらなる議論を含む短い記事の抜粋を以下に示します。より完全な議論については、ブログ記事を参照してください。

HATEOASアプリケーションを構築している場合は、204応答を避けます。

これは、非自明なREST APIの構築中に学んだREST API設計に関するレッスンです。クライアントを可能な限りサポートするために、REST APIは204（No Content）応答を返さないでください。

サービスの観点からは、204（コンテンツなし）応答は、POST、PUT、またはDELETE要求に対する完全に有効な応答である可能性があります。特に、DELETEリクエストの場合、非常に適切なようです。他に何と言うことができますか？

ただし、適切なHATEOAS対応クライアントの観点からは、フォローするリンクがないため、204応答は問題があります。ハイパーメディアがアプリケーション状態のエンジンとして機能する場合、リンクがない場合、状態はありません。つまり、204応答はすべてのアプリケーション状態を破棄します。

この記事では、POST、PUT、DELETE、およびGETについて説明します。 DELETEに関する具体的な説明は次のとおりです。

DELETEリクエストへの応答

DELETE要求は、リソースを削除する意図を表します。したがって、サービスがDELETEリクエストを正常に処理した場合、204（コンテンツなし）を返す以外に何ができますか？結局のところ、リソースは削除されたばかりです。

多くの場合、リソースはコレクションのメンバーであるか、コンテナによって「所有」されています。例として、 http://foo.ploeh.dk/api/tags/rock は「ロック」タグを表しますが、別の見方をすると、/ rockリソースがタグコンテナ（それ自体がリソースです）。これはAtom Pubユーザーになじみがあるはずです。

http://foo.ploeh.dk/api/tags/rock リソースを削除するとします。その目標を達成するために、あなたはそれに対してDELETEリクエストを発行します。クライアントが取得するすべてが204（コンテンツなし）である場合、そのコンテキストは失われています。そこからどこへ行くのですか？クライアントの状態を保持しない限り、どこから来たのかわかりません。

204（No Content）を返す代わりに、APIが役立ち、行くべき場所を提案します。この例では、提供すべき明らかなリンクの1つは、 http://foo.ploeh.dk/api/tags -クライアントがリソースを削除したばかりのコンテナーです。おそらく、クライアントはより多くのリソースを削除したいので、それが役立つリンクになるでしょう。

9
Grokify

DELETEの応答本文に含めるべき内容に関するRESTful規則とは何ですか？

RESTは、彼の論文の chapter 5 でFieldingによって定義されたアーキテクチャスタイルであり、このアーキテクチャで構築されたアプリケーションの一連の制約について説明しています。 RESTはprotocol indenpendentとなるように設計されていますが、同じ論文の chapter 6 how REST=はHTTP経由で適用されます。

RESTアプリケーションがHTTPプロトコルの上に設計されたら、HTTPセマンティクスに注意する必要があります。HTTP/ 1.1プロトコルのセマンティは、現在 RFC 7231 。

成功した DELETE 要求の応答ペイロードは次のとおりです。

  • 空か、
  • アクションのステータスの表現を含めます。

また、次の応答ステータスコードは、成功した DELETE リクエストに適しています。

  • 202 ：要求は処理のために受け入れられましたが、処理は完了していません。
  • 204 ：サーバーは要求を正常に処理し、応答ペイロード本体に送信する追加コンテンツがないことを確認しました。
  • 200 ：リクエストは成功し、リクエストペイロードにはアクションのステータスの表現が含まれます。

RFC 7231 からの次の引用を参照してください。

DELETEメソッドが正常に適用された場合、Originサーバーは202（承認済み）ステータスコード。アクションが成功する可能性が高いがまだ実施されていない場合は、204（コンテンツなし）ステータスコード。アクションが実行され、それ以上の情報が提供されない場合、または200（OK）アクションが実行され、応答メッセージにステータスを説明する表現が含まれている場合、ステータスコード。

6
cassiomolin