RESTfulな「PUT」操作で何かが返された場合

437

PUTレスポンスボディで何も返さない（null）RESTfulな操作についての人々の意見は何だろうと思っていました。

— AwkwardCoder
ソース

613

HTTP仕様（RFC 2616）には、適用可能ないくつかの推奨事項があります。これが私の解釈です：

200 OK既存のリソースへの更新の成功したPUTのHTTPステータスコード。応答本文は必要ありません。（セクション9.6に従って、204 No Contentさらに適切です。）
201 Created新しいリソースの正常なPUTのHTTPステータスコード。新しいリソースの最も具体的なURIがLocationヘッダーフィールドに返され、その他の関連するURIとリソースのメタデータが応答の本文にエコーされます。（RFC 2616セクション10.2.2）
HTTPステータスコード409 Conflictによる3に失敗したPUT用^のRD未遂更新とレスポンスボディで現在のリソース間の違いのリストで、パーティの修正。（RFC 2616セクション10.4.10）
400 Bad Request失敗したPUTのHTTPステータスコード。PUTが失敗した理由を説明する自然言語のテキスト（英語など）が応答本文に含まれます。（RFC 2616セクション10.4）

— システムポーズ
ソース

25

@stian面白い！RFC 2616（特にセクション10.2 Successful 2xxおよび10.2.1 200 OK）で200、PUT、DELETE、またはその他のメソッドの使用を明確に除外するものは何も見つからないため、これはMozillaの部分ではかなりおかしいようです。私は何か見落としてますか？MozillaがW3やIETFのボスになるなど？;）または、おそらくPostelの堅牢性の原則を聞いたことがありません。

— システム一時停止2013年

52

@stian：その文は2013年2月3日に削除されました。おそらく誰かがここで読んだためです。;）developer.mozilla.org/en-US/docs/HTTP/...

— クリスチャンStrempfer

6

PUTメソッドのセマンティクスは、リソースの現在の状態を無視することです。したがって、サードパーティによる変更が原因で失敗したPUTに対して409の競合を返すことは、リクエストが条件付きの場合にのみ意味があります。

— Pedro Werneck

8

@systemPAUSEいい答えです。1つの小さな点：成功した操作に応答本文を返さない場合は、204のみを使用することをお勧めします。一部のクライアント（jQuery Ajaxなど）は、0以外の長さの応答を期待しているのに取得できない場合に窒息します。この例は、この質問で確認できます。

— nick_w 14

3

これが回答されてから、おそらくRFC2616が更新されています。9.6ではNo response body needed200に関して言及されていません。実際、応答本文はPUTに関してまったく言及されていません。それだけを述べています

If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

— ジェームズ

163

ここでのほとんどの回答とは対照的に、PUTは（もちろんHTTPコードに加えて）更新されたリソースを返すはずだと思います。

リソースをPUT操作の応答として返す必要があるのは、リソース表現をサーバーに送信すると、サーバーがこのリソースに何らかの処理を適用できるため、クライアントはこのリソースの処理方法を知りたいからです。リクエストが正常に完了した後のようになります。（それ以外の場合は、別のGET要求を発行する必要があります）。

— LiorH
ソース

3

「サーバーはこのリソースにいくつかの処理を適用することもできます」：これはこれが初めてです。それは本当にRESTfulですか？

— Raedwald 2012

22

@Raedwald確かにそうです。RESTは、一般的に推奨されていますが、PUTでリソース全体を更新する必要はありません。一部のフィールドは更新しても意味がない場合があります。たとえば、作成日や最終更新日は、おそらくPUT本体に含めるべきではありませんが、PUTの結果として変更される可能性があります。そうは言っても、PUTがリソースの返却をもたらすはずであるというLiorHには同意しません。更新されたリソースを取得するには、PUTの後にGETが必要です。

— Randolpho

19

@Randolpho RESTでは、PUTでリソース全体を更新する必要はありません。これはPATCHの場合ではないのですか？

— Marco Ciambrone、2013年

14

@MarcoCiambroneはい、同意し、以前のコメントを取り消します。RESTとPUTの調整を変更しました-PUTは常にべき等であり、部分的な更新には使用しないでください。PATCHがサポートされていない限り、POSTが唯一の代替手段です。その場合、PATCHが適切な代替手段になる可能性があります。PATCHは新しい動詞ですが、一部のサーバー側フレームワークではサポートされていない場合があります。

— Randolpho

2

回答はrfc7231のかなり前に書かれていましたが、セクション4.3.4で、「PUTメソッドは、ターゲットリソースの状態を作成するか、要求メッセージのペイロードで囲まれた表現で定義された状態に置き換えることを要求しています」

— aaaaaa

3

サーバーがPUTに応答してコンテンツを返すことは可能だと思います。サイドロードされたデータを可能にする応答エンベロープ形式（ember-dataによって消費される形式など）を使用している場合、データベーストリガーなどを介して変更された可能性のある他のオブジェクトを含めることもできます（サイドロードされたデータは明示的に削減されます）リクエストの数。これは最適化するのに最適な場所のようです。）

PUTを受け入れるだけで、報告するものがない場合は、ステータスコード204を本文なしで使用します。レポートするものがある場合は、ステータスコード200を使用し、本文を含めます。

— ショーン
ソース

2

HTTP / 1.1仕様（セクション9.6）は、適切な応答/エラーコードを論じています。ただし、応答の内容は扱いません。

何を期待しますか？単純なHTTP応答コード（200など）は、私には単純明快です。

— ブライアンアグニュー
ソース

はい。ただし、PUTまたはPOSTの後にdbに挿入されたデータが本当に必要な真のデータを表しているかどうかを確認したい場合はどうでしょう。HTTPが応答の本文を送り返すことができれば、より良いでしょう。

— tnkh

1

@tnkhあなたが提案するものは実に恐ろしい考えです。更新が成功した後、別のGET呼び出しを実行して、目的の結果を達成します。この部門で問題が発生している場合は、パフォーマンスを確保するためにキャッシングレイヤーを導入してください。私たちは「すべてがうまくいく」種類のロジックをいじくってこれらの問題を解決することはできません。2020年に常識となるはずの「しっかりした」基本的なプログラミング原則をいじらないでください。それは恥ずべきことです。

— XDS

@XDSコメントの最初の部分を認めます。しかし、その後私の目をロールバックするために停止することはできません。陽気なコメント

— tnkh

なぜあなたはそれが陽気だと思うのかについて詳しく説明してくれてありがとう。

— XDS

2

REST APIのバックエンドがSQLリレーショナルデータベースの場合、

更新可能なすべてのレコードにRowVersionがあるはずです（失われた更新の問題を回避するため）
PUTの後は常に新しいレコードのコピーを返す必要があります（新しいRowVersionを取得するため）。

失われた更新を気にしない場合、またはPUTの直後にクライアントにGETを強制する場合は、PUTから何も返さないでください。

— ジョン・ヘンケル
ソース

1

クライアントが新しく作成されたリソースを見つけることができる場所を指す「Location」ヘッダーとともに、「Created」の201のHTTP応答コード。

— dc360
ソース

5

PUTオブジェクトは新しく作成されたリソースではない（またはすべきではない）

— kdazzle

9

@kdazzle PUTは確かに新しく作成されたリソースであり、多くの場合はそうなります。w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

— チャーリーシュリー

3

私のコメントをもう少しよく説明します。PUTは、このアイテムをこの特定の場所に置き、現在あるものを置き換えます（該当する場合）。

— user1751825 16

3

右、「現在あるものを置き換える」がキーワードです。それはすでに存在しているはずであり、置き換えられています。PUTは、新しいリソースを作成するためのものではありません。

— ケビンM

3

@KevinM最新のRFCドキュメントrfc7231のように、リソースを作成できると記載されています：「PUTメソッドは、ターゲットリソースの状態を作成または置換するように要求します [...]」と、PUTが作成できないと考える理由新しいリソースは、必ずしも新しいリソースの場所がわからないためです。しかし、その場所/識別子がわかっていれば、まだそこにない場合でも作成できます。

— レオ・レイ

0

私はサービスでRESTful APIを使用しましたが、これが私の意見です。まず、共通のビューに到達する必要がありPUTます。作成または取得しないリソースを更新するために使用されます。

私は次のリソースを定義しました：Stateless resourceとStateful resource：

ステートレスリソースこれらのリソースについては、空の本文を含むHttpCodeを返すだけで十分です。
ステートフルリソース例：リソースのバージョン。この種類のリソースの場合、変更するときにバージョンを提供する必要があるため、完全なリソースを返すか、バージョンをクライアントに返します。これにより、クライアントは更新アクションの後にget要求を送信する必要がなくなります。

しかし、サービスやシステム、それを維持するためにsimple、clearly、easy to use and maintain最も重要なことです。

— ブルース
ソース

6

「PUTは、作成または取得されないリソースを更新するために使用されます。」-それは真実でも一般的でもありません。仕様により、PUTはリソースを作成できます。クリア=一般的に知られている仕様に従う。

— ImrePühvel18年

-3

空のリクエストボディがGETリクエストの本来の目的と一致し、空のレスポンスボディがPUTリクエストの本来の目的と一致するように。

— アンソニーWジョーンズ
ソース

-3

大丈夫そうです...私は成功/失敗/投稿された時間/＃バイト受信/などの初歩的な兆候だと思います望ましいでしょう。

編集：私はデータの整合性および/または記録保持の線に沿って考えていました。MD5ハッシュや受信時刻のタイムスタンプなどのメタデータは、大きなデータファイルに役立つ場合があります。

— ジェイソンS
ソース

1

ステータス応答ヘッダーで200 OKはどうですか？「ありがとうございます」と言っても十分だと思いますか。

— AnthonyWJones 2009

応答ヘッダーにはステータスコードが含まれますが、はい、この時点でHTTPについて話しています:)

— AwkwardCoder '28

-4

理想的には、成功/失敗の応答を返します。

— cgp
ソース

13

ただし、応答本文にはありません。HTTPステータスコードは、そのための場所です。エラーが発生した場合、ビディレスポンスで拡張エラー情報が返される可能性があります

— ポール

-4

HTTP応答のヘッダーと本文には違いがあります。PUTは本文を返すことはありませんが、ヘッダーで応答コードを返す必要があります。成功した場合は200、失敗した場合は4xxを選択してください。ヌルの戻りコードなどはありません。なぜこれをしたいのですか？

— アレクサンダーヨハネセン
ソース