22

私は Web API アプリケーションを持っており、OK または Failed を返す一括 (数十または数百) 挿入と更新の両方に以下の URL を使用しています。

POST api/v1/products

これは私のアクションにマッピングされています:

public HttpResponseMessage PostProducts(PostProductsRequest request)
{

...
}

PostProductsRequest オブジェクトには、List タイプの Products プロパティが含まれています。

プロパティの Id プロパティが存在する場合は、それを更新します。そうでない場合は、挿入を示します。

しかし、一括挿入のみに Post を使用し、一括更新に Put を使用する必要があるかどうかはわかりません。各アプローチのベスト プラクティスと利点は何ですか?

一括挿入および一括更新用の RESTful API を設計するには?

4

4 に答える 4

9

必要条件に応じて、どちらの方法も使用できますが、これは、これらに大きな違いがないという意味ではありません。HTTP メソッドは CRUD ではありません。PUT または POST は、Create および Update ではなく、その逆でもありません。

PUTは、指定された URI のリソースを指定されたエンティティに完全に置き換えるため、作成と更新に使用できますが、完全な表現が含まれている場合に限ります。PUT の直後に行われる GET リクエストは、同じリソースを返す必要があります。表現はまったく同じかもしれませんが、PUT された表現に欠けていたデフォルト値をサービスが追加する可能性があります。

POST は、提供されているエンティティが指定された URI のリソースに従属していることをサーバーに通知し、それに対して何を行うべきかについて合意を得ています。作成、更新、HTTP 自体によって標準化されていない操作など、何でもかまいません。

これを念頭に置いて、PUT を使用した一括挿入または一括更新は、URI で識別されるコレクション全体を置き換える場合にのみ RESTful になります。これは必ずしもそのメディア タイプに関連付けられたコレクション全体である必要はありません。URI には、データセットをスライスするクエリ文字列を含めることができ、そのスライスに対してのみ一括操作を実行します。

たとえば、次のコレクション リソースがあるとします。

GET /api/products

に代表される：

{'products': [product1, product2, product3]}

さらに 3 つの製品を追加する場合、PUT を使用した一括操作では、新しい製品を既存の製品に追加し、コレクション全体を送り返す必要があります。

PUT /api/products

{'products': [product1, product2, product3, product4, product5, product6]}

ただし、適用できるフィルター制約があり、/api/products上記の GET で空のコレクションが返される場合は、そのフィルターされたリソースへの新しい製品のみで PUT を実行しても問題ありません。たとえば、上記の製品をパートナー属性でフィルタリングでき、パートナー x があり、パートナー y を追加するとします。

その場合は、次のようにすると問題ありません。

PUT /api/products?partner=y

{'products': [product4, product5, product6]}

GET /api/productsその後、次のように返されます。

{'products': [product1, product2, product3, product4, product5, product6]}

GET /api/products?partner=x返品する限り:

{'products': [product1, product2, product3]}

そしてGET /api/products?partner=y戻ります：

{'products': [product4, product5, product6]}

これは複雑に思えるかもしれませんし、PUT の代わりに POST を使用する方が良いように見えることもありますが、上記の操作全体が標準化されていることに注意してください。意図したとおりに PUT を使用しています。操作は POST の方が簡単ですが、標準化されていないため、独自の構文を設計して文書化する必要があります。

于 2013-11-05T10:47:34.413 に答える
3

たまたまHTTP 1.1 のメソッド定義を見ていて、この質問を思い出しました。

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

これは、PUT を使用し、ペイロードに存在しないリソースが含まれていて、それを作成するのに十分な情報が含まれている場合は、それを作成する必要があることを示しています。したがって、PUT は、リソースを作成および更新できる一括操作で正しいメソッド動詞になります。 .

于 2013-06-26T13:45:07.783 に答える
2

RESTful Web サービスでのバッチ操作の最も「標準に準拠した」方法は、さまざまな「コレクション」アプローチ (つまりDELETE /mail?&id=0&id=1&id=2) のいずれかを使用するか、プロセスを単純化するためにバッチ処理ハンドラーを使用することです。

POST正直なところ、オブジェクトの作成と更新のみに使用するという事実を除いて、私はあなたとまったく同じパターンを使用しますPUT(これは標準的な方法です)。また、操作が成功した場合は、作成されたオブジェクトとともに201 - CreatedPOSTを返し、 204 - No Contentをデータなしで返す必要があります。もちろん、一括作成を行っているため、新しく作成されたオブジェクトの配列を.PUTPOST

要約すると：

POST api/products
  |
  |---> Success: 201 [NewObject1, NewObject2, ...]
  |---> Failure: Relevant error code as to why the operation failed

PUT api/products
  |
  |---> Success: 204
  |---> Failure: Relevant error code as to why the operation failed

更新: ASP.NET Web API の vNext にはバッチ処理が組み込まれます。

于 2013-06-25T12:24:25.413 に答える