web-dev-qa-db-ja.com

S3 REST AP​​IおよびPOSTメソッド

AWS S3 REST AP​​I を使用していますが、署名に関する厄介な問題を解決した後、機能しているようです。ただし、リソースの作成に正しいREST動詞、つまりPOSTを使用すると、405 method not allowedが返されます。同じリクエストがPUTメソッドで正常に機能し、リソースを作成します。

何か間違っているのですか、AWS S3 REST AP​​Iは完全にRESTに準拠していませんか？

restamazon-web-servicesamazon-s3
57
vartec

はい、CRUDをHTTPメソッドにマッピングするのは間違っています。

ここでのスタックオーバーフローに関する高評価の回答を含む、一般的な使用方法と広範な誤解にもかかわらず、POSTは「リソースを作成する正しい方法」ではありません。他のメソッドのセマンティクスはHTTPプロトコルによって決定されますが、POSTのセマンティクスはターゲットメディアタイプ自体によって決定されます。 POSTは、HTTPで標準化されていない操作に使用されるメソッドであるため、作成に使用できますが、更新、または他のユーザーによってまだ実行されていない他の操作にも使用できます方法。たとえば、取得にPOSTを使用するのは間違っています。GETが標準化されているためです。ただし、クライアントがPUTを使用できない場合、リソースの作成にPOSTを使用しても構いません。何らかの理由。

同様に、PUTは「リソースを更新するための正しい方法」ではありません。 PUTは、現在の状態を無視して、リソースを完全に置き換えるために使用される方法です。サーバーが期待する表現全体がある場合は作成にPUTを使用でき、変更しない部分を含む完全な表現を提供する場合は更新にPUTを使用できますが、部分更新にPUTを使用するのは正しくありません、サーバーにリソースの現在の状態を考慮するよう要求しているためです。 PATCHはそれを行う方法です。

非公式の言語では、各メソッドがサーバーに言うことは次のとおりです。

  • POST：このデータを取得し、リソースメディアタイプについて文書化したルールに従って、指定されたURIで識別されるリソースに適用します。

  • PUT：指定されたURIで識別されるものはすべて、このデータで置き換えます。すでに存在するものは無視します。

  • PATCH：指定されたURIで識別されるリソースが、前回見たときと同じ状態のままの場合、このdiffを適用します。

Createまたはupdateは言及されておらず、それらのメソッドのセマンティクスの一部ではないことに注意してください。 POSTおよびPUTを使用して作成できますが、PATCHは現在の状態に依存するため、作成できません。いずれでも更新できますが、PATCHでは更新元の状態を条件とする更新があり、PUTで​​はエンティティ全体を置換することで更新するため、i等操作であり、POSTで更新できます事前に定義されたルールに従ってサーバーに実行を依頼します。

ちなみに、RESTはアーキテクチャではないので、APIがREST準拠であると言うのが理にかなっているかどうかはわかりませんstyleまたは標準ですが、それを考慮しても、RESTであると主張するAPIはほとんどありません。ほとんどの場合、 ハイパーテキスト駆動 ではないためです。 AWS S3は間違いなくRESTfulではありませんが、質問に関係する場合、HTTPメソッドの使用はほとんどの場合HTTP標準に従います。

222
Pedro Werneck
+--------------------------------------+---------------------+
|                 POST                 |         PUT         |
+--------------------------------------+---------------------+
| Neither safe nor idempotent Ex: x++; | Idempotent Ex: x=1; |
+--------------------------------------+---------------------+
6
Premraj

@Nicholosに追加するには

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html から

POST：

投稿されたエンティティは、ファイルが含まれるディレクトリに従属する、ニュース記事が投稿先のニュースグループに従属する、またはレコードがデータベースに従属するのと同じように、URIに従属します。

POSTメソッドによって実行されるアクションは、URIで識別できるリソースにならない場合があります。この場合、応答に結果を記述するエンティティが含まれているかどうかに応じて、200（OK）または204（No Content）が適切な応答ステータスです。

Originサーバーでリソースが作成されている場合、応答は201（作成済み）である必要があります

PUT：

PUTメソッドは、指定されたRequest-URIで囲まれたエンティティを保存することを要求します。 Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、Originサーバーに存在するエンティティの修正バージョンと見なされる必要があります。 Request-URIが既存のリソースを指しておらず、そのURIが要求ユーザーエージェントによって新しいリソースとして定義できる場合、OriginサーバーはそのURIでリソースを作成できます。新しいリソースが作成される場合、Originサーバーは201（作成済み）応答を介してユーザーエージェントに通知する必要があります。既存のリソースが変更された場合、200（OK）または204（No Content）応答コードのいずれかを送信して、要求が正常に完了したことを示す必要があります

IMO PUTを使用して、囲まれたエンティティを作成または変更/置換できます。

3
Ram Bavireddi

元のHTTP仕様 では、POSTリクエストのペイロードで指定されたリソースは、「指定されたオブジェクトに従属すると見なされます」（つまり、リクエストURL）。 TimBLは以前に（参照が見つからないため）それが NNTPの同じ名前のメソッド でモデル化されていると言っています。

2
Nicholas Shanks