5922

RFC 2616 によると、§ 9.5がリソースの作成POSTに使用されます。

POST メソッドは、オリジン サーバーがリクエストに含まれるエンティティを、Request-Line の Request-URI で識別されるリソースの新しい従属として受け入れるように要求するために使用されます。

RFC 2616 によると、§ 9.6 は、リソースの作成または置換PUTに使用されます。

PUT メソッドは、囲まれたエンティティが指定された Request-URI の下に格納されることを要求します。Request-URI が既存のリソースを参照する場合、同封されたエンティティは、オリジン サーバーに存在するエンティティの修正版と見なされる必要があります。Request-URI が既存のリソースを指しておらず、その URI が要求しているユーザー エージェントによって新しいリソースとして定義できる場合、オリジン サーバーはその URI を使用してリソースを作成できます。

では、リソースを作成するにはどの HTTP メソッドを使用すればよいでしょうか? それとも両方をサポートする必要がありますか?

4

38 に答える 38

4626

全体：

作成には PUT と POST の両方を使用できます。

何を使用すべきかを区別するには、「何に対してアクションを実行していますか?」と尋ねる必要があります。質問をするための API を設計しているとしましょう。POST を使用する場合は、質問のリストに対してそれを行います。PUT を使用する場合は、特定の質問に対して行います。

どちらも使用できるので、RESTful 設計ではどちらを使用する必要がありますか。

PUT と POST の両方をサポートする必要はありません。

どちらを使うかはあなた次第です。ただし、リクエストで参照しているオブジェクトに応じて、正しいものを使用することを忘れないでください。

いくつかの考慮事項:

  • 作成した URL オブジェクトに明示的に名前を付けますか、それともサーバーに決定させますか? それらに名前を付ける場合は、PUT を使用します。サーバーに決定させる場合は、POST を使用します。
  • PUT は冪等性を仮定するように定義されているため、オブジェクトを 2 回 PUT しても、追加の効果はありません。これは素晴らしいプロパティなので、可能であれば PUT を使用します。PUT-べき等性が実際にサーバーに正しく実装されていることを確認してください。
  • 同じオブジェクト URL で PUT を使用してリソースを更新または作成できます
  • POST を使用すると、URL を変更する 2 つの要求を同時に受け取ることができ、オブジェクトの異なる部分を更新する可能性があります。

例：

これに関する SOの別の回答の一部として、次のように書きました。

役職：

リソースの変更と更新に使用

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

以下はエラーであることに注意してください。

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

URL がまだ作成されていない場合は、名前を指定するときに POST を使用して作成しないでください。<new_question>はまだ存在しないため、「リソースが見つかりません」というエラーが発生するはずです。<new_question> 最初にリソースをサーバーにPUT する必要があります。

ただし、POST を使用してリソースを作成するには、次のようにすることもできます。

POST /questions HTTP/1.1
Host: www.example.com/

この場合、リソース名が指定されていないことに注意してください。新しいオブジェクトの URL パスが返されます。

置く：

リソースの作成または上書きに使用されます。リソースの新しい URL を指定します。

新しいリソースの場合:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

既存のリソースを上書きするには:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

さらに、もう少し簡潔に、RFC 7231 セクション 4.3.4 PUTの状態 (強調を追加)、

4.3.4. 置く

PUT メソッドは、ターゲット リソースの状態が 、要求メッセージ ペイロードに含まれる表現によって定義された状態であることを要求しますcreated。replaced

于 2009-03-10T14:29:46.930 に答える
2392

あなたは言うウェブ上のアサーションを見つけることができます

どちらもまったく正しくありません。

アクションの冪等性に基づいて PUT と POST のどちらかを選択することをお勧めします。

PUTは、リソースを配置することを意味します。つまり、指定された URL で利用可能なものを別のものに完全に置き換えます。定義上、PUT はべき等です。何回やっても結果は同じです。x=5冪等です。リソースが以前に存在するかどうかに関係なく、リソースを PUT できます (たとえば、作成または更新)。

POSTは、リソースを更新したり、補助リソースを追加したり、変更を引き起こしたりします。POST はべき等でx++はありません。

この引数により、PUT は、作成するものの URL がわかっている場合に作成するためのものです。作成したいカテゴリの「工場」または管理者の URL がわかっている場合は、POST を使用して作成できます。

それで：

POST /expense-report

また：

PUT  /expense-report/10929
于 2010-04-22T14:55:54.930 に答える
784
  • URL へのPOSTは、サーバーで定義された URLに子リソースを作成します。
  • URL へのPUTは、クライアントが定義した URL でリソース全体を作成/置換します。
  • URL へのPATCHは、クライアントが定義した URLのリソースの一部を更新します。

PUT および POST に関連する仕様は、RFC 2616 §9.5ff です。

POST は子リソースを作成するため、POSTはリソース/itemsの下に存在するリソースを作成します/items。例えば。/items/1. 同じポスト パケットを 2 回送信すると、2 つのリソースが作成されます。

PUTは、クライアントが認識している URLでリソースを作成または置換するためのものです。

したがって、 PUTは、リソースが作成される前にクライアントがすでに URL を知っている CREATE の候補にすぎません。例えば。/blogs/nigel/entry/when_to_use_post_vs_putタイトルがリソースキーとして使用されるため

PUTは既知の URL のリソースが既に存在する場合はそれを置き換えるため、同じリクエストを 2 回送信しても効果はありません。つまり、PUT の呼び出しはべき等です。

RFC には次のように書かれています。

POST 要求と PUT 要求の根本的な違いは、Request-URI の異なる意味に反映されています。POST 要求の URI は、含まれるエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる別のエンティティである可能性があります。対照的に、PUT リクエストの URI は、リクエストに含まれるエンティティを識別します。ユーザー エージェントは、意図されている URI を認識しており、サーバーはリクエストを他のリソースに適用しようとしてはなりません。サーバーが要求を別の URI に適用することを望む場合、

注: PUT は主にリソースを更新するために (全体を置き換えることによって) 使用されてきましたが、PUT はリソース全体を置き換えることを指定しているため、最近、既存のリソースを更新するために PATCH を使用する動きがあります。RFC 5789。

Update 2018 : PUTを回避するためにできるケースがあります。「PUT なしの REST」を参照してください。

「PUT なしの REST」手法では、消費者が新しい「名前付けされた」リクエスト リソースを投稿することを強制されるという考えがあります。前述のように、顧客の郵送先住所の変更は、新しい「ChangeOfAddress」リソースへの POST であり、異なる郵送先住所フィールド値を持つ「Customer」リソースの PUT ではありません。

「REST API 設計 - リソース モデリング」 (Thoughtworks の Prakash Subramaniam 著) から引用

これにより、API は複数のクライアントが単一のリソースを更新する際の状態遷移の問題を回避し、イベント ソーシングおよび CQRS とよりうまく一致します。作業が非同期で行われる場合、変換を POST して適用されるのを待つのが適切なようです。

于 2010-04-07T05:52:52.900 に答える
291

POST「ユーザーを作成するための入力は次のとおりです。作成してください」のように、「新規作成」を意味します。

PUT「ここにユーザー 5 のデータがあります」のように、「挿入、既に存在する場合は置換」を意味します。

ユーザーの名前がまだPOSTわからないため、example.com/users に移動します。サーバーに作成してもらいます。URL

特定のPUTユーザーを置き換え/作成したいので、example.com/users/id に移動します。

同じデータで 2 回 POST を実行すると、ID が異なる 2 人の同一のユーザーが作成されます。同じデータで 2 回 PUT すると、最初にユーザーが作成され、2 回目に同じ状態に更新されます (変更なし)。PUT何度実行しても同じ状態になるため、毎回「同等に強力」、つまり冪等と言われます。これは、リクエストを自動的に再試行する場合に便利です。ブラウザの戻るボタンを押したときに「本当に再送信しますか」ということはもうありません。

一般的なアドバイスは、サーバーがリソースPOSTの生成を制御する必要がある場合に使用することです。URLそれ以外の場合は使用してくださいPUT。より優先PUT しPOSTます。

于 2011-10-23T14:27:31.723 に答える
260

概要：

作成：

次の方法で、PUT または POST の両方で実行できます。

置く

/resources URI またはcollectionの下に、 newResourceIdを識別子としてTHE新しいリソースを作成します。

PUT /resources/<newResourceId> HTTP/1.1

役職

/resources URI またはcollectionの下に新しいリソースを作成します。通常、識別子はサーバーから返されます。

POST /resources HTTP/1.1

アップデート：

次の方法で PUT を使用してのみ実行できます。

置く

/resources URI またはcollectionの下で、識別子としてexistingResourceIdを使用してリソースを更新します。

PUT /resources/<existingResourceId> HTTP/1.1

説明：

REST と URI を一般的に扱う場合、左側にジェネリック、右側に固有があります。ジェネリックは通常コレクションと呼ばれ、より具体的な項目はリソースと呼ばれます。リソースにはコレクションを含めることができることに注意してください。

例:

<-- ジェネリック -- 固有 -->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

POST を使用するときは、常にコレクションを参照しているため、次のように言うときはいつでも:

POST /users HTTP/1.1

ユーザー コレクションに新しいユーザーを投稿しています。

続けて、次のようなことを試してみると:

POST /users/john HTTP/1.1

それは機能しますが、意味的には、 usersコレクションの下のjohn コレクションにリソースを追加したいと言っています。

PUT を使用すると、おそらくコレクション内のリソースまたは単一のアイテムを参照します。だからあなたが言うとき：

PUT /users/john HTTP/1.1

サーバーの更新に通知するか、ユーザーコレクションの下にあるjohn リソースが存在しない場合は作成します。

仕様:

仕様のいくつかの重要な部分を強調しましょう。

役職

POSTメソッドは、オリジン サーバーがリクエストに含まれるエンティティを、Request-Line の Request-URI で識別されるリソースの新しい従属として受け入れるように要求するために使用されます。

したがって、コレクションに新しいリソースを作成します。

置く

PUTメソッドは、囲まれたエンティティが指定された Request-URI の下に格納されることを要求します。Request-URIが既存のリソースを参照している場合、同封されたエンティティは、オリジン サーバーに存在するエンティティの修正版と見なされる必要があります (SHOULD )。Request-URI が既存のリソースを指しておらず、その URI が要求しているユーザー エージェントによって新しいリソースとして定義できる場合、オリジン サーバーはその URI を使用してリソースを作成できます。」

したがって、リソースの存在に基づいて作成または更新します。

参照：

于 2013-08-14T22:47:18.633 に答える
182

「実用的な」アドバイスを追加したいと思います。保存しているオブジェクトを取得できる「id」がわかっている場合は、PUT を使用します。たとえば、将来のルックアップや更新を行うために、データベースで生成された ID を返す必要がある場合、PUT の使用はうまく機能しません。

したがって、既存のユーザー、またはクライアントが ID を生成し、ID が一意であることが確認されているユーザーを保存するには、次のようにします。

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

それ以外の場合は、POST を使用して最初にオブジェクトを作成し、PUT を使用してオブジェクトを更新します。

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com
于 2011-01-15T19:59:06.533 に答える
144

POST を使用して作成し、PUT を使用して更新します。いずれにせよ、それが Ruby on Rails のやり方です。

PUT    /items/1      #=> update
POST   /items        #=> create
于 2009-03-10T14:28:57.680 に答える
74

REST は非常に高度な概念です。実際、HTTP についてはまったく言及されていません。

HTTP で REST を実装する方法について疑問がある場合は、いつでもAtom Publication Protocol (AtomPub)仕様を参照できます。AtomPub は、多くの HTTP および REST 著名人によって開発された、HTTP を使用して RESTful Web サービスを作成するための標準であり、REST の発明者であり、HTTP の (共同) 発明者である Roy Fielding からの情報も取り入れています。

実際、AtomPub を直接使用することもできます。ブログ コミュニティから出てきたものですが、ブログに限定されているわけではありません。HTTP 経由で任意の (ネストされた) 任意のリソースのコレクションと RESTful に対話するための汎用プロトコルです。アプリケーションをネストされたリソースのコレクションとして表すことができれば、AtomPub を使用するだけでよく、PUT と POST のどちらを使用するか、どの HTTP ステータス コードを返すか、およびそれらすべての詳細を気にする必要はありません。

これは、AtomPub がリソースの作成について述べていることです (セクション 9.2):

コレクションにメンバーを追加するために、クライアントはコレクションの URI に POST 要求を送信します。

于 2009-03-10T15:27:52.047 に答える
69

HTTP + REST API を使用してサーバー上にリソースを作成するために PUT または POST を使用するかどうかの決定は、URL 構造の所有者に基づいています。クライアントに URL 構造体を認識させたり、定義に参加させたりすることは、SOA から生じた望ましくない結合と同様に不要な結合です。カップリングのタイプをエスケープすることが、REST が非常に人気がある理由です。したがって、使用する適切な方法は POST です。この規則には例外があり、クライアントが展開するリソースの場所構造を制御したい場合に発生します。これはまれであり、他の何かが間違っている可能性があります。

この時点で、RESTful-URLが使用されている場合、クライアントはリソースの URL を認識しているため、PUT が受け入れられると主張する人もいます。結局のところ、正規化された、正規化された、Ruby on Rails、Django の URL が重要である理由はここにあります。Twitter API を見てください。これらの人々は、Restful-URL のようなものは存在せず、Roy Fielding 自身が次のように述べていることを理解する必要があります。

REST API は、固定のリソース名または階層を定義してはなりません (クライアントとサーバーの明らかな結合)。サーバーは、独自の名前空間を自由に制御できる必要があります。代わりに、HTML フォームや URI テンプレートで行われているように、適切な URI を構築する方法をサーバーがクライアントに指示できるようにします。これらの指示をメディア タイプとリンク関係内で定義します。[ここでの失敗は、RPC の機能結合と同等のデータ指向であるドメイン固有の標準など、帯域外の情報のためにクライアントがリソース構造を想定していることを意味します]。

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

RESTful-URLの考え方は実際には REST に違反しています。サーバーが URL 構造を担当しており、結合を避けるためにそれを使用する方法を自由に決定できる必要があるからです。これが混乱する場合は、API 設計における自己発見の重要性について読んでください。

POST を使用してリソースを作成する場合、POST はべき等ではないため、設計上の考慮事項があります。これは、POST を数回繰り返しても、毎回同じ動作が保証されないことを意味します。これにより、リソースを作成してはいけないときに PUT を使用してリソースを作成するように人々を怖がらせます。彼らはそれが間違っていることを知っています (POST は CREATE を表します) が、この問題を解決する方法がわからないため、とにかく実行します。この懸念は、次の状況で示されます。

  1. クライアントは新しいリソースをサーバーに POST します。
  2. サーバーはリクエストを処理し、レスポンスを送信します。
  3. クライアントは応答を受け取りません。
  4. サーバーは、クライアントが応答を受信して​​いないことを認識していません。
  5. クライアントにはリソースの URL がなく (したがって、PUT はオプションではありません)、POST を繰り返します。
  6. POST は冪等ではなく、サーバーは …</li>

ステップ 6 は、人々が何をすべきかについて一般的に混乱する場所です。ただし、この問題を解決するためにクラッジを作成する理由はありません。代わりに、RFC 2616で指定されているように HTTP を使用でき、サーバーは次のように応答します。

10.4.10 409 コンフリクト

リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には十分な情報を含める必要があります

ユーザーが競合の原因を認識するための情報。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。

競合は、PUT 要求への応答で発生する可能性が最も高くなります。たとえば、バージョニングが使用されていて、PUT されているエンティティに、以前の (サードパーティの) 要求によって行われたものと競合するリソースへの変更が含まれていた場合、サーバーは 409 応答を使用して、要求を完了できないことを示す可能性があります。 . この場合、応答エンティティには、応答の Content-Type によって定義された形式で、2 つのバージョン間の相違点のリストが含まれている可能性があります。

次の理由から、ステータス コード 409 Conflict で応答するのが正しい手段です。

  • システムに既に存在するリソースと一致する ID を持つデータの POST を実行することは、「リソースの現在の状態との競合」です。</li>
  • 重要な部分は、クライアントがサーバーにリソースがあることを理解し、適切なアクションを実行することです。これは、「ユーザーが競合を解決してリクエストを再送信できる可能性があると予想される状況」です。</li>
  • 競合する ID を持つリソースの URL とリソースの適切な前提条件を含む応答は、「ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報」を提供します。これは RFC 2616 の理想的なケースです。

2616 を置き換える RFC 7231 のリリースに基づく更新

RFC 7231は 2616 を置き換えるように設計されており、セクション 4.3.3では、POST に対する次の可能な応答について説明しています。

POST を処理した結果が既存のリソースの表現と同等である場合、オリジン サーバーは、Location フィールドに既存のリソースの識別子を指定して 303 (See Other) 応答を送信することにより、ユーザー エージェントをそのリソースにリダイレクトすることができます (MAY)。これには、ユーザーエージェントにリソース識別子を提供し、共有キャッシングにより適した方法で表現を転送するという利点がありますが、ユーザーエージェントがまだ表現をキャッシュしていない場合は、追加のリクエストが必要になります。

POST が繰り返された場合に単純に 303 を返したくなるかもしれません。しかし、その逆です。303 を返すことは、(異なるリソースを作成する) 複数の作成要求が同じコンテンツを返す場合にのみ意味があります。例としては、クライアントが毎回再ダウンロードする必要のない「リクエスト メッセージを送信していただきありがとうございます」があります。RFC 7231 は、セクション 4.2.2 で、POST は冪等ではないことを維持し、作成には POST を使用する必要があることを維持し続けています。

詳細については、この記事をお読みください。

于 2013-10-29T23:00:55.573 に答える
55

RFC 2616 の PUT の定義から、このアドバイスが気に入っています。

POST 要求と PUT 要求の根本的な違いは、Request-URI の異なる意味に反映されています。POST 要求の URI は、含まれるエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる別のエンティティである可能性があります。対照的に、PUT リクエストの URI は、リクエストに含まれるエンティティを識別します。ユーザー エージェントは、意図されている URI を認識しており、サーバーはリクエストを他のリソースに適用しようとしてはなりません。

これは、PUT は既に名前を持っているリソースに適用するのが最適であり、POST は既存のリソースの下に新しいオブジェクトを作成する (そしてサーバーに名前を付ける) のに適しているという他のアドバイスとも一致します。

私はこれと、PUT の冪等性の要件を次のように解釈します。

  • POST は、コレクションの下に新しいオブジェクトを作成するのに適しています (create は冪等である必要はありません)。
  • PUT は既存のオブジェクトの更新に適しています (更新はべき等である必要があります)
  • POST は、既存のオブジェクトに対する冪等でない更新にも使用できます (特に、全体を指定せずにオブジェクトの一部を変更する場合、考えてみれば、コレクションの新しいメンバーを作成することは、実際にはこの種の特殊なケースです)。更新、コレクションの観点から)
  • クライアントがリソースに名前を付けることを許可する場合に限り、PUT を create に使用することもできます。しかし、REST クライアントは URL 構造について仮定を行うことは想定されていないため、これは意図された精神からはほど遠いものです。
于 2012-01-11T17:18:54.103 に答える
53

要するに：

PUTは冪等であり、同じ操作が 1 回または複数回実行された場合、リソースの状態は同じになります。

POSTは冪等ではなく、操作が 1 回実行される場合と比較して複数回実行される場合、リソースの状態が異なる可能性があります。

データベース クエリとの類推

PUT "UPDATE STUDENT SET address = "abc" where id="123"; と同様に考えることができます。

POST "INSERT INTO STUDENT(name, address) VALUES ("abc", "xyzzz"); のようなものを考えることができます。

学生証は自動生成されます。

PUT では、同じクエリが複数回または 1 回実行された場合、STUDENT テーブルの状態は同じままです。

POST の場合、同じクエリが複数回実行されると、データベースに複数の Student レコードが作成され、「INSERT」クエリを実行するたびにデータベースの状態が変化します。

注: PUT では、更新が必要なリソースの場所 (既にリソース) が必要ですが、POST では必要ありません。したがって、直感的に POST は新しいリソースの作成を目的としていますが、PUT は既存のリソースを更新するために必要です。

更新は POST で実行できると考える人もいるかもしれません。どちらを更新に使用するか、どちらを作成に使用するかという厳密な規則はありません。繰り返しますが、これらは慣習であり、直感的に私は上記の推論に傾倒し、それに従います。

于 2016-07-29T11:11:21.423 に答える
44

新しい答え（RESTをよりよく理解できるようになりました）：

PUT は、クライアントによって識別されたリソースの表現をレンダリングするために、今後サービスが使用する必要があるコンテンツのステートメントにすぎません。POST は、今後サービスに含める必要があるコンテンツのステートメントです (重複する可能性があります) が、そのコンテンツを識別する方法はサーバー次第です。

PUT x(リソース を識別する場合)x : 「によって識別されるリソースのコンテンツを私のコンテンツに置き換えます。」x

PUT x(xリソースを識別しない場合): 「コンテンツを含む新しいリソースを作成し、xそれを識別するために使用します。」

POST x: 「コンテンツを保存し、そのコンテンツを含むリソース (古いものまたは新しいもの) を識別するために使用できる識別子を教えてください (他のコンテンツと混在している可能性があります)。このリソースは、x識別したものと同一または従属している必要があります。」「yのリソースはxのリソースに従属する」は通常、 yをxのサブパス(たとえばx =/fooおよびy = /foo/bar)にし、存在を反映するようにxのリソースの表現を変更することによって実装されますが、必ずしもそうではありません。 yへのハイパーリンクなど、新しいリソースののリソースといくつかのメタデータ。URL は REST では不透明であるため、後者だけが優れた設計に本当に不可欠です。サービスをトラバースするには、クライアント側の URL 構築の代わりにハイパーメディアを使用する必要があります。

REST には、「コンテンツ」を含むリソースなどというものはありません。サービスが表現を一貫してレンダリングするために使用するデータを「コンテンツ」と呼びます。通常、データベースまたはファイル (画像ファイルなど) 内の関連する行で構成されます。JSON ペイロードを SQL ステートメントに変換するなど、ユーザーのコンテンツをサービスが使用できるものに変換するのはサービス次第です。

元の回答（読みやすいかもしれません）：

PUT /something（/somethingすでに存在する場合）：「あなたが持っているものは何でも取り/something、私があなたに与えるものに置き換えてください。」

PUT /something（/somethingまだ存在しない場合）：「私があなたに与えるものを取り、 に置きます/something。」

POST /something: "私があなたに与えたものを受け取っ/somethingて、終わったらその URL を教えてくれさえすれば、好きな場所に置いてください。"

于 2012-08-01T20:10:42.607 に答える
39

Ruby on Rails 4.0 では、PUT の代わりに 'PATCH' メソッドを使用して部分的な更新を行います。

RFC 5789 は、PATCH について次のように述べています (1995 年以降)。

相互運用性を向上させ、エラーを防止するには、新しい方法が必要です。PUT メソッドは、完全に新しい本体でリソースを上書きするように既に定義されており、部分的な変更を行うために再利用することはできません。そうしないと、プロキシとキャッシュ、さらにはクライアントとサーバーでさえ、操作の結果について混乱する可能性があります。POST は既に使用されていますが、幅広い相互運用性はありません (たとえば、パッチ形式のサポートを見つける標準的な方法がありません)。PATCH は以前の HTTP 仕様で言及されていましたが、完全には定義されていませんでした。

「Edge Rails: PATCH は更新のための新しい主要な HTTP メソッドです」で説明しています。

于 2012-02-26T09:21:30.570 に答える
30

すでに述べたことを言い換えるリスクがありますが、PUTは、リソースを作成するときに、クライアントが最終的にURLがどうなるかを制御することを意味することを覚えておくことが重要です。したがって、PUTとPOSTのどちらを選択するかは、URLスキームが何であれ、一貫性のある正しい正規化されたURLを提供するためにクライアントをどれだけ信頼できるかということです。

クライアントが正しいことを行うことを完全に信頼できない場合は、POSTを使用して新しいアイテムを作成し、応答でURLをクライアントに送り返す方が適切です。

于 2011-03-25T10:17:54.237 に答える
25

最も重要な考慮事項は信頼性です。POST メッセージが失われた場合、システムの状態は未定義です。自動回復は不可能です。PUT メッセージの場合、状態は最初の再試行が成功するまで未定義です。

たとえば、POST でクレジット カード トランザクションを作成するのは適切ではない場合があります。

リソースに自動生成された URI がある場合でも、生成された URI (空のリソースを指す) をクライアントに渡すことで PUT を使用できます。

その他の考慮事項:

  • POST は、含まれているリソース全体のキャッシュされたコピーを無効にします (一貫性の向上)
  • POST 応答はキャッシュ可能ですが、PUT 応答はキャッシュ可能ではありません (Content-Location と有効期限が必要です)。
  • PUT は、Java ME、古いブラウザ、ファイアウォールなどではあまりサポートされていません
于 2012-02-08T16:31:54.340 に答える
19

このトピックに慣れていない読者は、何をすべきかについて果てしない議論と、経験からの教訓が相対的に欠如していることに驚かれることでしょう。REST が SOAP よりも「好まれる」という事実は、経験からの高レベルの学習だと思いますが、そこから進歩したに違いありません。2016 年です。Roy の論文は 2000 年です。私たちは何を開発したのでしょうか。楽しかったですか？統合は簡単でしたか？サポートするには？スマートフォンの台頭や不安定なモバイル接続に対応できるでしょうか?

ME によると、現実のネットワークは信頼できません。タイムアウトを要求します。接続がリセットされます。ネットワークは、一度に数時間または数日間ダウンします。列車はモバイル ユーザーを乗せたままトンネルに入ります。任意の要求に対して (このすべての議論で時々認められるように)、要求が途中で水に落ちたり、応答が途中で水に落ちたりする可能性があります。このような状況で、実質的なリソースに対して PUT、POST、および DELETE リクエストを直接発行することは、常に少し残忍でナイーブに思えます。

HTTP は、要求と応答の確実な完了を保証するために何もしません。これは、ネットワーク対応アプリケーションの適切な仕事であるため、問題ありません。このようなアプリケーションを開発すると、フープをジャンプして POST の代わりに PUT を使用し、さらにフープをジャンプして、重複した要求を検出した場合にサーバーで特定の種類のエラーを発生させることができます。クライアントに戻ると、これらのエラーを解釈し、再取得、再検証、および再送信するために、さまざまな手順を踏む必要があります。

または、これを行うこともできます: 安全でないリクエストを一時的なシングルユーザー リソースと見なします (それらをアクションと呼びましょう)。クライアントは、リソースへの空の POST を使用して、実質的なリソースに対する新しい「アクション」を要求します。POST はこれにのみ使用されます。新たに作成されたアクションの URI を安全に取得すると、クライアントは安全でないリクエストをターゲット リソースではなくアクション URI に PUT します。アクションの解決と「実際の」リソースの更新は、適切に API の仕事であり、ここでは信頼できないネットワークから分離されています。

サーバーはビジネスを行い、応答を返し、合意されたアクション URI に対してそれを保存します。何か問題が発生した場合、クライアントはリクエストを繰り返し (自然な動作です!)、サーバーが既にそれを認識している場合は、保存されているレスポンスを繰り返し、他には何もしません。

promise との類似点はすぐにわかります。何かを実行する前に、結果のプレースホルダーを作成して返します。また、Promise と同様に、アクションは 1 回だけ成功または失敗する可能性がありますが、その結果は繰り返し取得できます。

何よりも、送信アプリケーションと受信アプリケーションに、一意に識別されたアクションをそれぞれの環境での一意性にリンクする機会を提供します。そして、クライアントに責任ある行動を要求し、強制することができます: 要求を好きなだけ繰り返しますが、既存のアクションから決定的な結果が得られるまで、新しいアクションを生成しないでください。

そのため、多くの厄介な問題が解消されます。挿入リクエストを繰り返しても重複は作成されず、データを取得するまで実際のリソースは作成されません。(データベース列は null 非許容のままにすることができます)。更新リクエストを繰り返しても、互換性のない状態になることはなく、その後の変更が上書きされることもありません。クライアントは、何らかの理由 (クライアントがクラッシュした、応答が失われたなど) で元の確認を (再) 取得してシームレスに処理できます。

連続する削除要求は、404 エラーを発生させることなく、元の確認を表示して処理できます。予想よりも時間がかかる場合は、暫定的に対応することができ、クライアントが最終的な結果を確認できる場所があります. このパターンの最も優れた部分は、そのカンフー (パンダ) プロパティです。クライアントが応答を理解できないときはいつでもリクエストを繰り返す傾向があるという弱点を取り上げ、それを強みに変えます:-)

これは RESTful ではないと言う前に、REST の原則が尊重されているさまざまな方法について考えてください。クライアントは URL を構築しません。セマンティクスが少し変更されていますが、API は引き続き検出可能です。HTTP動詞が適切に使用されています。これが実装するのに大きな変更であると思われる場合は、経験からそうではないことを伝えることができます。

保存するデータが膨大になると思われる場合は、ボリュームについて話しましょう。典型的な更新の確認は、キロバイトの何分の一かです。HTTP は現在、確実に応答するのに 1 ～ 2 分かかります。アクションを 1 週間しか保存しない場合でも、クライアントが追いつくチャンスは十分にあります。ボリュームが非常に大きい場合は、acid に準拠した専用のキー値ストアまたはインメモリ ソリューションが必要になる場合があります。

于 2016-02-18T11:45:38.923 に答える
15

オリジンサーバーはそのURIでリソースを作成できます

したがって、リソースの作成には POST を使用しますが、おそらく必要ではありませんが、PUT を使用します。両方をサポートする必要はありません。私にとっては、POST で十分です。したがって、それは設計上の決定です。

あなたの引用が述べたように、IRI に割り当てられたリソースがないの作成に PUT を使用し、とにかくリソースを作成したいとします。たとえば、PUT /users/123/password通常は古いパスワードを新しいパスワードに置き換えますが、パスワードがまだ存在しない場合は、それを使用してパスワードを作成できます (たとえば、新たに登録されたユーザーによって、または禁止されたユーザーを復元することによって)。

于 2014-01-16T07:58:14.947 に答える
14

私は次のように着陸するつもりです：

PUT は、URI で識別されるリソースを参照します。この場合、更新しています。リソースを参照する 3 つの動詞の一部です。delete と get は残りの 2 つです。

POST は基本的に自由形式のメッセージであり、その意味は「帯域外」で定義されています。メッセージがディレクトリへのリソースの追加と解釈できる場合は問題ありませんが、基本的には、送信 (投稿) しているメッセージを理解して、リソースがどうなるかを知る必要があります。

PUT と GET と DELETE はリソースを参照するため、定義上、冪等でもあります。

POST は他の 3 つの機能を実行できますが、キャッシュやプロキシなどの仲介者で要求のセマンティクスが失われます。投稿の URI は、適用先のリソースを必ずしも示すとは限らないため、これはリソースに対するセキュリティの提供にも適用されます (ただし、可能です)。

PUT は作成である必要はありません。リソースがまだ作成されていない場合、サービスはエラーになる可能性がありますが、それ以外の場合は更新します。またはその逆 -- リソースを作成することはできますが、更新は許可しません。PUT に必要な唯一のことは、特定のリソースを指していることと、そのペイロードがそのリソースの表現であることです。PUT が成功するということは、(干渉を除いて) GET が同じリソースを取得することを意味します。

編集：もう1つ-PUTは作成できますが、作成する場合、IDは自然なID-AKAメールアドレスでなければなりません。そうすれば、2 回 PUT すると、2 回目の put が最初の put の更新になります。これにより、べき等になります。

ID が生成された場合 (たとえば、新しい従業員 ID)、同じ URL を持つ 2 番目の PUT によって新しいレコードが作成され、べき等規則に違反します。この場合、動詞は POST になり、メッセージ (リソースではない) は、このメッセージで定義された値を使用してリソースを作成することになります。

于 2013-10-21T21:16:32.953 に答える
10

「PUT」は、「GET」がべき等であると想定されているように、セマンティクスが異なると想定されています。つまり、まったく同じ PUT リクエストを複数回実行でき、結果は 1 回だけ実行したかのようになります。

最も広く使用され、最も役立つと思われる規則について説明します。

特定の URL にリソースを PUT すると、その URL にリソースが保存されるか、またはそれらの線に沿った何かが発生します。

特定の URL のリソースに POST すると、多くの場合、関連する情報がその URL に投稿されます。これは、URL のリソースが既に存在することを意味します。

たとえば、新しいストリームを作成する場合は、それを URL に PUT できます。ただし、メッセージを既存のストリームに POST したい場合は、その URL に POST します。

ストリームのプロパティの変更に関しては、PUT または POST を使用して行うことができます。基本的に、操作がべき等である場合にのみ「PUT」を使用し、それ以外の場合は POST を使用します。

ただし、最新のブラウザーのすべてが GET または POST 以外の HTTP 動詞をサポートしているわけではないことに注意してください。

于 2011-10-23T20:07:55.460 に答える
8

データベース操作に精通している場合は、

  1. 選択する
  2. 入れる
  3. アップデート
  4. 消去
  5. マージ (既存の場合は更新、そうでない場合は挿入)

私PUTはマージと更新のような操作に使用POSTし、挿入に使用します。

于 2016-06-29T21:13:07.827 に答える
6

実際には、POST はリソースの作成に適しています。新しく作成されたリソースの URL は、Location 応答ヘッダーで返される必要があります。リソースを完全に更新するには、PUT を使用する必要があります。これらは RESTful API を設計する際のベスト プラクティスであることを理解しておいてください。HTTP 仕様自体は、PUT/POST の使用を制限していませんが、リソースの作成/更新にはいくつかの制限があります。ベスト プラクティスをまとめたhttp://techoctave.com/c7/posts/71-twitter-rest-api-dissectedをご覧ください。

于 2014-10-06T06:51:56.893 に答える
4

POST:新しいリソースの作成に使用します。これは、自動インクリメント ID を使用した INSERT (SQL ステートメント) のようなものです。応答部分には、新しく生成された Id が含まれています。

POST は、レコードの更新にも使用されます。

PUT:新しいリソースを作成するために使用しますが、ここで ID キーを知っています。IDキーを事前に知っているINSERT（SQLステートメント）のようなものです。応答部分では何も送信しません。

PUT はリソースの更新にも使用されます

于 2013-12-12T11:06:52.543 に答える