3

したがって、メソッドは次のようになります。

POST person/personId/edit
https://api.example.com/*key*/person/*personId*/edit?FName=Blah

これにより、personId の人の名を Blah に変更したいと考えています。

人を追加する必要がある場合は、次のように言います。

PUT person/create
https://api.example.com/*key*/person/create

そして、新しい personId を持つ人を追加します。

4

2 に答える 2

4

通常、一般的な規則は次のとおりです。

GET    => READ
POST   => CREATE
DELETE => DELETE
PUT    => UPDATE

私が見ることができる違いは、異なる URI も使用していることです。最も一般的に使用されるのは、単一のリソース URI です。でも、それは賛否両論ありますので、好みの問題です。

于 2012-06-18T18:05:32.837 に答える
3

POST と PUT の私の解釈は常に次のとおりです。

POST - サーバーは、操作の実行またはリソースの作成に使用できるエンティティを受け取ります。エンドポイントの目的がリソースの作成である場合、POST は常に NEW リソースを作成します。いずれにせよ、各 POST はリソースの状態に関係なく処理されます。サーバーが操作できるように、サーバーに情報を投稿するだけです。

例：

  • ユーザーの携帯電話にメッセージを送信する Web サービスを想像してみてください。POST は、必要な情報をサーバーに提供するために使用できますが、これは GET には適していない可能性があります。リクエスト ペイロードには、この情報が含まれます。サーバー上にリソースが作成されていないため、操作は 200 OK を返し、操作が正常に完了したことを示します。応答には、サーバー操作からの情報を含む本文が含まれる場合もあります。
  • 掲示板に投稿されるチケットを作成する Web サービスを想像してみてください。POST には、その投稿を行うために必要な情報を含めることができます。情報はサーバー上に保持され、201 Created を返します (さらに、ユーザー ID を含む応答本文、または作成の結果としてより完成されたオブジェクトが返されます)。いずれの場合も、何かがこのエンドポイントに POST されると、NEW チケットが作成されます。

PUT - サーバーは、リソースを作成または置換する目的でエンティティ (ID などを含む) を受け取ります。リソースがすでに存在する場合は、リクエスト内のリソースに置き換えられます。そうでない場合は、新しいリソースが作成されます。いずれの場合も、何かがサーバー上に永続化されます。エンティティを一意に識別する何らかの方法を提供する必要があります。つまり、エンティティを作成する必要がある場合に ID が使用されるため、ID を作成するのはクライアントです。私が知っているほとんどの人は、この現実に苦しんでいます。

例：

  • Web サービスは、ユーザー情報を含むペイロードをクライアントから受け取ります。ユーザーが救われることが期待されます。サーバーは、そのユーザーが存在するかどうかを確認します。その場合、そのユーザーを (全体として)要求で提供された新しいリソースに置き換えることでそのユーザーを更新し、 200 OK または 204 No Content を返します。存在しない場合は作成し、201 Created を返します。
于 2013-05-31T20:06:17.103 に答える