30

私のAPIサーバーでは、次のルートが定義されています：

POST /categories

1 つのカテゴリを作成するには、次のようにします。

POST /categories {"name": "Books"}

複数のカテゴリを作成したい場合は、次のようにできると思いました。

POST /categories [{"name": "Books"}, {"name": "Games"}]

これが Restful HTTP API の優れたプラクティスであることを確認したいだけです。

または、

POST /bulk

あらゆる操作 (作成、読み取り、更新、削除) を一度に実行できるようにしますか?

4

5 に答える 5

32

真の REST では、おそらくこれを複数の個別の呼び出しで POST する必要があります。その理由は、それぞれが新しい表現になるからです。そうでなければ、どうやってそれを取り戻すと思いますか。

各投稿は、結果のリソースの場所を返す必要があります。

POST -> New Resource Location
POST -> New Resource Location
...

ただし、バルクが必要な場合は、バルクを作成してください。可能な場合は独断的になるが、そうでない場合は実用主義が仕事を成し遂げる。教条主義に執着しすぎると、何も成し遂げられません。

ここに同様の質問があります

これは、これをより効率的にするためにHTTPパイプラインを提案するものです

于 2012-06-20T14:45:47.420 に答える
17

アクティブ化するために POST する一括操作を行うことに特に問題はありません (冪等ではないため、POST が適切な動詞です) が、いくつかの注意事項があります。

  • 複数のリソースを作成しているため、複数の URL で応答する必要があります。これは、リダイレクト パターンを使用できないことを意味します。何らかの形式で URL のリストを送り返す必要があります。

  • 一括操作はあまり見つけられないことが多いという問題があります。発見可能性は、RESTfulness の最も重要な点の 1 つです。これは、サーバー作成者の多くの助けなしに、誰かがクライアントを作成する方法を理解できることを意味するためです。

  • 一括操作を行っているときに部分的な障害に対処することは、依然として問題があります。これは他のパラダイムにも問題があるため (SOAP の拡張機能を使用しているときに人々がこれをめぐって自分自身を結びつけるのを見てきました)、驚くことではありませんが、すべての作成物が機能することを保証できなければ、 1 つのリソースを作成して 2 つ目のリソースを作成できなかった場合に何が起こるかを解明する必要があります。(また、一括リクエストで 3 つ目のリクエストが必要な場合は、それを試してみますか?)

最も単純なアプローチは、リクエストごとに 1 つの作成をサポートすることです。これは、正しく理解するのがはるかに簡単なパターンであり、全体的によく理解されています。

于 2012-06-20T14:57:36.987 に答える
4

POST で一度に複数のリソースを作成しても問題はありません (PUT で試してはいけません)。特に一括操作自体の表現を作成する場合は、「非 REST フル」ではありません。個々のリソースを作成するのと同時にインデックス リソースを作成し、それに「303 See Other」を返すことをお勧めします。そのインデックス表現には、作成されたすべてのリソースへのリンクが含まれます (いずれかが失敗した場合は、エラー情報も含まれる可能性があります)。

POST /categories/uploads/
[{"name": "Books"}, {"name": "Games"}]

    303 See Other
    Location: /categories/uploads/321/

（実は今考えると303より201の方がいいのかも）

GET /categories/uploads/321/

    200 OK
    Content-Type: application/json

    [{"name": "Books", "link": "/categories/Books/"},
     {"name": "Games", "error": "The 'Games' category already exists."}]
于 2012-06-20T17:03:43.130 に答える
3

あなたの場合、私は /bulk リソースの方法にも行きます。しかし、私が提案するパターンは次のとおりであり、私の理解では最も自然なパターンです: 202 Accepted ステータス コードで作業します。

一括リクエストの考え方は、サーバーがすぐに応答することを強制されるべきではないということです。これは、クライアントが一括リクエストが完了するまで待機する必要があることを意味するためです。

パターンは次のとおりです。

POST /bulk [{"name": "Books"}, {"name": "Games"}]
202 Accepted | Location: /bulk/processing/status/resourceId

GET /bulk/processing/status/resourceId
entry = "REST in peace" | completed | 0 errors | /categories/category/resourceId
entry = "Walking dead" | processing | 0 errors ->

そのため、クライアントは大量の情報をサーバーに POST します。サーバーは、応答時の処理状態について保証しない 202 でそれらを受け入れるだけです。ただし、サーバーはステータス リソースへのリンクも提供します。ここでクライアントは、作成された各リソースと処理状態を確認できます。完了すると、クライアントは指定されたリンクを介してリソースにアクセスできます。エラー ケースはクライアントによって識別でき、エラー データは完了したリソースの PUT によって再送信される可能性があります。

最後に、私が通常従う良いアドバイスは次のとおりです。HTTP 機能にマップできないリソースを設計でヒットするときはいつでも、おそらくリソースの欠落が原因です。

于 2013-09-29T07:37:32.793 に答える