RestfulHTTPを使用して単一および複数のリソースを作成する
私のAPIサーバーでは、次のルートを定義しています。
POST /categories
1つのカテゴリを作成するには、次のようにします。
POST /categories {"name": "Books"}
複数のカテゴリを作成したい場合は、次のことができると思いました。
POST /categories [{"name": "Books"}, {"name": "Games"}]
これがRestfulHTTPAPIのグッドプラクティスであることを確認したいだけです。
または、
POST /bulk
一度にあらゆる操作（作成、読み取り、更新、削除）を実行できるようにするためですか？
真のRESTでは、おそらくPOSTこれを複数の別々の呼び出しで行う必要があります。その理由は、それぞれが新しい表現になるためです。そうでない場合、どのようにそれを取り戻すと思いますか。
各投稿は、結果のリソースの場所を返す必要があります。
POST -> New Resource Location
POST -> New Resource Location
...
ただし、バルクが必要な場合は、バルクを作成します。可能な場合は独断的であるが、そうでない場合は、実用主義が仕事を成し遂げる。あなたが独断主義に夢中になりすぎると、あなたは何も成し遂げられません。
POST to、アクティブ化するバルク操作があることには特に問題はありません（それはべき等ではないのでPOSTは正しい動詞です））がいくつかの注意点があります：
複数のリソースを作成しているため、複数のURLで応答する必要があります。これは、リダイレクトパターンを使用できないことを意味します。URLのリストを何らかの形式で返送する必要があります。
一括操作はあまり発見できないことが多いという問題があります。発見可能性は、RESTfulnessの最も重要なことの1つです。これは、サーバーの作成者の助けがなくても、誰かがやって来てクライアントを作成する方法を理解できることを意味します。
一括操作がある場合の部分的な障害への対処には、依然として問題があります。これは他のパラダイムでも問題です（SOAPの拡張機能を使用するときに、人々がこれを結びつけるのを見てきました）ので、驚くことではありませんが、可能でない限り保証作成は機能します。1つのリソースを作成し、2番目のリソースを作成できなかった場合に何が起こるかを理解する必要があります。 （また、一括リクエストで3番目のリクエストを実行したい場合は、続行して試してみますか？）
最も簡単なアプローチは、リクエストごとに1つの作成をサポートすることです。これは正しく理解するのがはるかに簡単なパターンであり、全体的によく理解されています。
POST（PUTで試さないでください）を使用して一度に複数のリソースを作成しても問題はありません。特にバルクの表現を作成する場合は、「非RESTフル」ではありません。操作自体。個々のリソースを作成すると同時にインデックスリソースを作成し、それに「303 See Other」を返すことをお勧めします。そのインデックス表現には、作成されたすべてのリソースへのリンクが含まれます（場合によってはエラー情報も含まれます）。それらのいずれかが失敗しました）。
POST /categories/uploads/
[{"name": "Books"}, {"name": "Games"}]
303 See Other
Location: /categories/uploads/321/
（実際、今考えてみると、201は303よりも良いかもしれません）
GET /categories/uploads/321/
200 OK
Content-Type: application/json
[{"name": "Books", "link": "/categories/Books/"},
{"name": "Games", "error": "The 'Games' category already exists."}]
あなたの場合、私も/ bulkリソースの方法で行きます。しかし、私が提案するパターンは次のとおりであり、私の理解から最も自然なものです。202Acceptedステータスコードを使用します。
一括リクエストの考え方は、サーバーがすぐに応答するように強制されるべきではないということです。これは、一括リクエストが完了するまでクライアントが待機する必要があることを意味します。
パターンは次のとおりです。
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機能にマップできないデザインのリソースにヒットした場合は、おそらくリソースが不足していることが原因です。
実際、これは今日までまだホットなトピックですが、私がほとんどの場合、練習ごとにバッターに適したシナリオが常にあると言っています。例：1。投稿からいいねを受け取っている場合、コメントごとにいいねが1つしかない場合のように、一括処理は必要ありません。 2.お気に入りのコメントを受け取っている場合は、誰かが読んだコメントを確認し、すべてのお気に入りのチェックボックスをオンにして一度送信することを検討することで、バルクをうまく収めることができます。
繰り返しになりますが、これはRestful APIでの作業経験に基づいていますが、現在、マルチタスクなどのために、私と同僚は、ほとんどのMIS（管理情報システム）で常に大部分を実行していることに気付きました。これは、多くの作業を実行して最終結果をバックエンドに送信できる現代のWebアプリとモバイルアプリが原因です。このように、受信したデータが違反しない限り、バックエンドはほとんど仕事をしません。ビジネスの論理。