PUT
応答本文で何も返さない (null) RESTful 操作について、人々の意見はどうなっているのだろうと思っていました。
12 に答える
HTTP 仕様 ( RFC 2616 ) には、適用可能な推奨事項が多数あります。これが私の解釈です:
200 OK
既存のリソースへの更新の PUT が成功した場合のHTTP ステータス コード。応答本文は必要ありません。(セクション 9.6による204 No Content
と、さらに適切です。)- 新しいリソースの成功した PUT のHTTP ステータス コード
201 Created
。新しいリソースの最も具体的な URI が Location ヘッダー フィールドに返され、その他の関連する URI とリソースのメタデータが応答本文にエコーされます。( RFC 2616 セクション 10.2.2 ) - サード
409 Conflict
パーティの変更が原因で失敗した PUT のHTTP ステータス コード。試行された更新と応答本文の現在のリソースとの相違点のリスト。( RFC 2616 セクション 10.4.10 ) 400 Bad Request
失敗した PUT のHTTP ステータス コード。PUT が失敗した理由を説明する自然言語テキスト (英語など) が応答本文に含まれます。( RFC 2616 セクション 10.4 )
ここでのほとんどの回答とは対照的に、実際には PUT は更新されたリソースを返す必要があると思います (もちろん HTTP コードに加えて)。
PUT 操作の応答としてリソースを返す理由は、リソース表現をサーバーに送信するときに、サーバーがこのリソースに何らかの処理を適用できるため、クライアントはこのリソースがどのように動作するかを知りたいからです。リクエストが正常に完了した後のように見えます。(それ以外の場合は、別の GET 要求を発行する必要があります)。
サーバーが PUT に応答してコンテンツを返すことは可能だと思います。サイドロードされたデータ (ember-data によって消費される形式など) を許可する応答エンベロープ形式を使用している場合は、データベース トリガーなどを介して変更された可能性のある他のオブジェクトを含めることもできます (サイドロードされたデータは、明示的に削減するために使用されます)。リクエストの数、これは最適化するのに最適な場所のようです.)
PUT を受け入れるだけで、報告するものが何もない場合は、本文なしでステータス コード 204 を使用します。報告することがある場合は、ステータス コード 200 を使用し、本文を含めます。
HTTP/1.1 仕様(セクション 9.6) では、適切な応答/エラー コードについて説明しています。ただし、応答の内容には対応していません。
あなたは何を期待しますか?単純な HTTP 応答コード (200 など) は、単純明快で明白に思えます。
"Created" の 201 の HTTP 応答コードと、クライアントが新しく作成されたリソースを見つけることができる場所を指す "Location" ヘッダー。
大丈夫だと思います...ただし、成功/失敗/投稿された時間/受信バイト数/などの基本的な表示だと思います。が望ましいでしょう。
編集:私はデータの完全性および/または記録管理の方針に沿って考えていました。MD5 ハッシュや受信時刻のタイムスタンプなどのメタデータは、大きなデータファイルの場合に役立ちます。
空のリクエスト ボディが GET リクエストの本来の目的に適合し、空のレスポンス ボディが PUT リクエストの本来の目的に適合するのと同様です。
理想的には、成功/失敗の応答を返します。
HTTP 応答のヘッダーと本文には違いがあります。PUT は本文を返すことはありませんが、ヘッダーで応答コードを返す必要があります。成功した場合は 200 を選択し、失敗した場合は 4xx を選択します。null 戻りコードなどはありません。なぜこれをしたいのですか?