私はAWS S3 REST APIを使用しています。署名に関する厄介な問題を解決した後、うまくいくようです。ただし、リソースを作成するために正しい REST 動詞を使用すると、つまりPOST
が得られ405 method not allowed
ます。同じリクエストがメソッドで正常に機能しPUT
、リソースを作成します。
何か間違ったことをしていますか、それとも AWS S3 REST API は REST に完全に準拠していませんか?
私はAWS S3 REST APIを使用しています。署名に関する厄介な問題を解決した後、うまくいくようです。ただし、リソースを作成するために正しい REST 動詞を使用すると、つまりPOST
が得られ405 method not allowed
ます。同じリクエストがメソッドで正常に機能しPUT
、リソースを作成します。
何か間違ったことをしていますか、それとも AWS S3 REST API は REST に完全に準拠していませんか?
はい、CRUD を HTTP メソッドにマッピングするのは間違っています。
ここ Stack Overflow での高評価の回答を含め、一般的な使用法と広範な誤解にもかかわらず、POST は「リソースを作成するための正しい方法」ではありません。他のメソッドのセマンティクスは HTTP プロトコルによって決定されますが、POST のセマンティクスはターゲット メディア タイプ自体によって決定されます。POST は、HTTP で標準化されていない操作に使用されるメソッドであるため、作成に使用できるだけでなく、更新や、他のメソッドでまだ実行されていないその他の操作にも使用できます。たとえば、GET が標準化されているため、POST を取得に使用するのは間違っていますが、クライアントが何らかの理由で PUT を使用できない場合、リソースの作成に POST を使用しても問題ありません。
同様に、PUT は「リソースを更新するための正しい方法」ではありません。PUT は、現在の状態を無視して、リソースを完全に置き換えるために使用される方法です。サーバーが期待する全体の表現がある場合は作成に PUT を使用でき、変更しない部分を含む完全な表現を提供する場合は更新に PUT を使用できますが、部分的な更新に PUT を使用するのは正しくありません、サーバーにリソースの現在の状態を考慮するように要求しているためです。PATCH はそれを行う方法です。
非公式の言葉で言えば、各メソッドがサーバーに伝える内容は次のとおりです。
POST : このデータを取得し、指定された URI で識別されるリソースに適用します。リソース メディア タイプについて文書化したルールに従います。
PUT : 指定された URI によって識別されるものをすべてこのデータに置き換えます。既に存在するものがある場合は無視します。
PATCH : 指定された URI によって識別されるリソースが、最後に見たときと同じ状態のままである場合は、この diff をそれに適用します。
create または update は言及されておらず、これらのメソッドのセマンティクスの一部ではないことに注意してください。POST と PUT で作成できますが、現在の状態に依存するため、PATCH では作成できません。それらのいずれでも更新できますが、PATCH では更新元の状態を条件とする更新があり、PUT ではエンティティ全体を置き換えることで更新するため、これはべき等操作であり、POST ではサーバーに実行を依頼します。事前に定義されたルールに従います。
ところで、REST は仕様や標準ではなくアーキテクチャスタイルであるため、API が REST に準拠していると言うことに意味があるかどうかはわかりませんが、それを考慮しても、REST に準拠している API はほとんどありません。ほとんどの場合、REST であると主張しているものは実際には RESTful であり、ハイパーテキスト駆動ではないためです。AWS S3 は間違いなく RESTful ではありませんが、質問に関係するところでは、HTTP メソッドの使用はほとんどの場合 HTTP 標準に従います。
+--------------------------------------+---------------------+
| POST | PUT |
+--------------------------------------+---------------------+
| Neither safe nor idempotent Ex: x++; | Idempotent Ex: x=1; |
+--------------------------------------+---------------------+
@Nicholos に追加するには
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.htmlから
役職:
投稿されたエンティティは、ファイルがそれを含むディレクトリに従属している、ニュース記事が投稿先のニュースグループに従属している、またはレコードがデータベースに従属しているのと同じように、URI に従属しています。
POST メソッドによって実行されるアクションは、URI によって識別できるリソースにならない場合があります。この場合、応答に結果を説明するエンティティが含まれているかどうかに応じて、200 (OK) または 204 (コンテンツなし) のいずれかが適切な応答ステータスです。
オリジン サーバーでリソースが作成されている場合、応答は 201 (Created) である必要があります。
置く:
PUT メソッドは、囲まれたエンティティが指定された Request-URI の下に格納されることを要求します。Request-URI が既存のリソースを参照している場合、同封されたエンティティは、オリジン サーバーに存在するエンティティの修正版と見なされる必要があります (SHOULD)。Request-URI が既存のリソースを指しておらず、その URI が要求しているユーザー エージェントによって新しいリソースとして定義できる場合、オリジン サーバーはその URI を使用してリソースを作成できます。新しいリソースが作成された場合、オリジン サーバーは 201 (Created) 応答を介してユーザー エージェントに通知する必要があります。既存のリソースが変更された場合、リクエストが正常に完了したことを示すために、200 (OK) または 204 (コンテンツなし) の応答コードを送信する必要があります (SHOULD)。
IMO PUT を使用して、囲まれたエンティティを作成または変更/置換できます。