38 
 new_story GET     /story/new(.:format)  {:action=>"new", :controller=>"stories"}
edit_story GET     /story/edit(.:format) {:action=>"edit", :controller=>"stories"}
     story GET     /story(.:format)      {:action=>"show", :controller=>"stories"}
           PUT     /story(.:format)      {:action=>"update", :controller=>"stories"}
           DELETE  /story(.:format)      {:action=>"destroy", :controller=>"stories"}
           POST    /story(.:format)      {:action=>"create", :controller=>"stories"}

私が他のテクノロジーで行ったWeb開発では、これまでGETとPOSTメソッドのみを使用していましたがRESTful、Railsのルートでは、デフォルトでPUTandDELETEメソッドがupdateanddestroyアクションに使用されます。PUTとを使用することの利点または必要性は何DELETEですか？私はこれらの方法が単なる別の方法だと思いますPOSTが、なぜそれだけに固執しないのPOSTですか？

4

4 に答える 4

70

利点は主にセマンティックであり、URLをある程度単純化することもできます。さまざまなHTTPメソッドがさまざまなアクションにマップされます。

POST   => create a new object
DELETE => delete an object
PUT    => modify an object
GET    => view an object

次に、理論的には、同じURLを使用できますが、異なる方法を使用してURLと対話します。リソースへのアクセスに使用されるメソッドは、実際の操作のタイプを定義します。

ただし、実際には、ほとんどのブラウザはHTTPGETとPOSTのみをサポートしています。RailsはHTMLフォームの「トリック」を使用して、PUTまたはDELETEリクエストが送信されたかのように動作しますが、Railsはこれらのメソッドに引き続きGETまたはPOSTを使用しています。（これは、他のプラットフォームでDELETEまたはPUTを使用しなかった理由を説明しています。）

于 2009-05-24T15:38:57.660 に答える
11

これがHTTP1.1仕様の「メソッド」セクションです。それは多くの方法を定義し、それらはすべて異なる利点とトレードオフを持っています。POSTは最も柔軟性がありますが、トレードオフは多数あります。キャッシュ可能ではなく（したがって、インターネットの他の部分はスケーリングに役立ちません）、安全またはべき等ではないため、クライアントはエラーが発生して再送信することはできません。何を達成しようとしているのかが明確ではなくなりました（非常に柔軟であるため）。他にもあると思いますが、それで十分でしょう。これらすべてを考慮すると、HTTP仕様で、リクエストで実行したいことを正確に実行するメソッドが定義されている場合、POST代わりに送信する理由はありません。

その理由POSTは非常に一般的であり、少なくとも歴史的には、WebブラウザはとのみをサポートGETしているためPOSTです。GETは安全でべき等であると定義されているため（多くのアプリケーションはこれに準拠していませんが）、データを変更する唯一の安全な方法はを送信することでしPOSTた。AJAXおよび非ブラウザクライアントの台頭により、それはもはや真実ではありません。

ところで、@ mipadiが提供したマッピングは標準のマッピングですが、それだけが有効なマッピングではありません。たとえば、AmazonS3はPUTリソースの作成に使用します。使用する唯一の理由POSTは、クライアントがリソースを作成するための十分な知識を持っていない場合です。たとえば、リレーショナルデータベースを使用してリソースをバックアップし、人工的な代理キーを使用します。

于 2009-05-25T21:38:00.073 に答える
10

http verbs彼の定義が間違っているので、受け入れられた答えに何かを追加したかっただけです。それらはすべて従うべき「すべき」仕様を持っており、仕様にhttp verbs基づいて複数で作成/更新/削除することができます。

W3によるRFC2616の重要な部分のいくつかを強調します。

PUT私の意見では、それを取り巻く混乱が最も大きいので、最初に説明します。

  • PUT is used for both create/update PUT updates by completely replacing the resource on the server with the resource sent in the request

例えば

あなたは私のAPIにこの呼び出しをします

PUT        /api/person
{
     Name: John,
     email: jdoe@hra.com
}

私のサーバーはこのリソースをサーバー上に置いています

{
     Name: Jane,
     email: jdoe@hra.com
}

これで、既存のリソースはあなたが送信したものに完全に置き換えられ、これが私のサーバーにあるものです。

{
     Name: John,
     email: jdoe@hra.com
}

PUTしたがって、本文でのみメールを送信する場合

PUT        /api/person
{
     email: jdoe@hra.com
}

マイサーバーがエンティティを完全に置き換えます

{
     Name: Jane,
     email: jdoe@hra.com
}

と

{
     email: jdoe@hra.com
}

そして、名前はなくなります。部分的な更新はのためですが、とにかくPATCH私はそれのために使用します。POST

  • One of the main reasons why we create/update with put is because it is idempotent.

これは単なる空想用語であり、その基本的な定義は、複数の同一のリクエストが1つのリクエストに対して同じであるということです。

例

オリジンサーバーがそのファイルを見つけられない場合、PUTファイルを作成するとします。api/fileファイルが見つかった場合は、古いファイルを私が送信したファイルに完全に置き換えます。これにより、1つのファイルが作成および更新されることが保証されます。ファイルが存在せずPUT、5回呼び出すと、最初にファイルが作成され、残りの4回は、送信したファイルに置き換えられます。5回呼び出しPOSTて作成すると、5つのファイルが作成されます。

  • You PUT to that exact URI. If you don't you have to send a 301 (Moved Permanently) to the user and allow then make a choice whether or not to redirect the request. Most times the server you PUT to usually hosts the resource and takes care of updating it

これらがPUTを使用する際の重要なポイントです

POSTに関する限り

  • You can also create/update and then some...

上で述べたように、いくつかの重要な違いがあります。

  • 投稿はより一般的です。どんな風に？他のいくつかの例には、他のプロトコルへのゲートウェイが含まれます。応答を取得して、途中でデータハンドラーに送信したり、ある種の機能を拡張したりできます。
  • Postには、「正確なURIまたは通知」の制限はありません。たとえばPOST、既存のコレクションにリソースを追加して、それを保存する場所を決定できます。

では、Deleteどうして私だけじゃないのPOST？

の場合、応答の送信時にリソースを削除するか、アクセスできない場所にリソースを移動しない限りDELETE、サーバーは正常に応答しないはずです。

なぜそれが重要なのですか？電話をかけDELETEたが、リソースが削除される前に「承認」を通過する必要がある場合はどうなりますか？削除を拒否できる場合、正常なエラーコードを送信することはできません。また、これに関する基本的な仕様に従えば、呼び出し元を混乱させることになります。ほんの一例ですが、他にもたくさん考えられると思います。

コモンをいつ使用するかについての主要なポイントのいくつかを強調しましたHttp verbs

于 2017-11-10T17:52:36.760 に答える
8

これは、ファイルの内容をゼロバイトに設定でき、ファイルシステムがそれを削除として処理するのに、なぜファイルを「削除」するのかを尋ねるようなものです。HTTPはGET/POST以外の動詞を永久にサポートしてきましたが、SOAPの進化の仕方は、それらの動詞の本来の意味を少しひねりました。RESTは、ペイロード内で新しい動詞の概念を発明する代わりに、意図したとおりに動詞を使用する、より単純な基本的なアプローチに戻ります。

于 2009-05-24T15:40:20.187 に答える