web-dev-qa-db-ja.com

PUTとPOSTリクエストはリクエストボディを持つ必要がある/期待されていますか？

私はRESTful APIを作成しており、ユーザーがキーを作成するプロセスについて考えています。次の可能性があります。

  • /new/<keyname>へのGETリクエスト-非常に簡単ですが、GETは情報の取得や一覧表示を行うためのものだと聞いたので、これは使用しないと思います。
  • /<keyname>へのPOSTリクエスト-これは簡単でシンプルなように思えますが、リクエストの本文でデータを渡しません。このようにできますか？これは変ですか？
  • /keysへのPOSTリクエストリクエスト本文"keyname=SomeKey"を渡す-これは正しい方法ですか？

私は joyentからのこのAPI とそれらのすべてのPUTおよびPOSTリクエストで、リクエストの本文にデータを渡します。これは期待されていますか？これは予期されていますか？ PUTおよびPOST requestにリクエスト本文が必要ですか？

httprestposthttpwebrequestput
27
João Pinto Jerónimo

私はHttp-WGでこの質問をしました。これが私が得た最も正確な答えでした http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0276.html

要約すると、POSTは本体を必要としません。同じ理由がPUTにも適用できると思います。

15
Darrel Miller

RFC2616はHTTP 1.1のベースRFC

最も一般的な形式では、HTTPメッセージは次のとおりです（オプションの本文に注意してください）。

generic-message = start-line 
 *（message-header CRLF）
 CRLF 
 [message-body] 
 start-line = Request-Line |ステータスライン

さらに読むとこれが得られます：

9.5 POST 
 
 POSTメソッドを使用して、リクエストに含まれる
エンティティを、リソース
は、Request-LineのRequest-URIによって識別されます。..

そして

9.6 PUT 
 
 PUTメソッドは、囲まれたエンティティが
で提供されるRequest-URIに格納されることを要求します。 ... 
 
 POSTとPUT要求の基本的な違いは、
がRequest-URIの異なる意味に反映されています。URI in 
 POSTリクエストは、囲まれた
エンティティを処理するリソースを識別します。そのリソースは、データ受け入れプロセス、
他のプロトコル、または注釈を受け入れる別のエンティティ。
対照的に、PUTリクエストのURIは、リクエストで囲まれたエンティティを識別します。
-ユーザーエージェントは、意図されているURIと
サーバーは、他のリソースにリクエストを適用してはいけません。

POSTとPUTの両方に、要求に囲まれたフレーズentity。

私の読書に基づいて、POSTとPUTの両方でボディが望ましい（非規範的な説明、わかっています）と思います。

RESTのコンテキストでは、[〜＃〜] post [〜＃〜]が作成され、[〜＃〜] put [〜＃〜] は更新です。空のオブジェクト（おそらく将来の情報のためのプレースホルダー）を作成することは想像できますが、空の更新をあまり使用しないと思います。

6
DwB

必須ではありません。本文なしでPOST/PUTリクエストを送信し、代わりにクエリ文字列パラメーターを使用できます。ただし、パラメーターにHTTP有効ではない文字が含まれている場合は、それらをエンコードする必要があるので注意してください。

たとえば、POST 'hello world'とエンドポイントを指定する必要がある場合は、次のようにする必要があります。 http://api.com?param=hello% 20world

0
marko982