「RESTイデオロギー」によると、PUT/POST/DELETEリクエストのレスポンスボディには何が含まれるべきですか?
リターンコードはどうですか？
HTTP_OK十分ですか？もしあれば、そのような慣習の理由は何ですか?
POST/PUT の違いを説明している良い投稿を見つけました: POST vs PUT しかし、それでも私の質問には答えていません。
128277 次
5 に答える
134
軽率なことを許してください。ただし、REST over HTTP を実行している場合、RFC7231は、GET、PUT、POST、および DELETE から期待される動作を正確に説明しています。
更新 (14 年 7 月 3 日):
HTTP 仕様では、POST または DELETE から返されるものを意図的に定義していません。仕様は、定義する必要があるものだけを定義します。残りは実装者の選択に委ねられています。
于 2010-11-24T16:18:48.100 に答える
25
全体として、規則は「Web ページを配信しているだけだと考えてください」です。
PUT の場合、直後に GET を実行した場合と同じビューを返します。その結果は 200 になります (もちろん、レンダリングが成功すると仮定します)。POST の場合、作成されたリソースにリダイレクトします (作成操作を行っていると仮定します。そうでない場合は、結果を返すだけです)。成功した作成のコードは 201 です。これは、300 の範囲にないリダイレクトの実際の唯一の HTTP コードです。
DELETE が何を返すべきかについて、私は満足したことがありません (私のコードは現在、HTTP 204 を生成し、この場合は空の本文を生成します)。
于 2010-11-24T16:01:02.007 に答える
3
通常、リソースの作成は POST にマップされ、新しいリソースの場所を返す必要があります。たとえば、Rails scaffold では、CREATE は新しく作成されたリソースの SHOW にリダイレクトします。更新 (PUT) についても同じアプローチが理にかなっているかもしれませんが、それはあまり規則的ではありません。更新は、成功を示すだけで済みます。おそらく、削除も成功を示すだけで十分です。リダイレクトしたい場合は、リソースの LIST を返すのがおそらく最も理にかなっています。
成功は HTTP_OK で示されます。はい。
上で述べた唯一の厳格なルールは、CREATE が新しいリソースの場所を返さなければならないということです。それは私には簡単なことのように思えます。クライアントが新しいアイテムにアクセスできる必要があることは完全に理にかなっています。
于 2010-11-24T16:02:22.410 に答える
1
RFC7231 では問題ではなく、空である可能性があります
プロジェクトで json api 標準ベースのソリューションを実装する方法:
post/put: オブジェクトの属性を get のように出力します (フィールド フィルター/リレーションも同じように適用されます)。
削除: データには null のみが含まれます (欠落しているオブジェクトを表すため)
標準削除のステータス: 200
于 2018-07-07T09:22:51.513 に答える