REST 規則を使用して更新を行う正しい方法を見つけようとしています。これまでのところ、次のことがわかっています。
単一のアイテムの更新:
PUT
https://mydomain.com/dogs/{id} accept: application/json, {dog}
複数のアイテムの更新:
PUT
https://mydomain.com/dogs accept: application/json, [{dog1}, {dog2}, ...]
私は、慣習が単一のアイテムに対してこれを（上記のものに加えて、または代わりに）指示するかどうかを理解しようとしています：
PUT
https://mydomain.com/dogs accept: application/json, {dog}
そして、フォローアップの質問: コレクションを更新するときに、1 つの要素に検証エラーがあるとします。規則では、422 を返し、要求全体を拒否するように規定されていますか? それとも、有効なものを更新して 4xx ステータス コードを返すのでしょうか?
PUT は一般的に更新に使用されますが、PUT は更新を意味するものではありません。PUT の背後にある基本的な考え方は、特定の場所にリソースを配置することです。最初のコード セグメントは、そのリソースの新しいバージョンをその場所に置くという点で正確です。
ただし、次の 2 つの要求は PUT のセマンティクスを支持しません。
PUT
https://mydomain.com/dogs accept: application/json, [{dog1}, {dog2}, ...]
PUT
https://mydomain.com/dogs accept: application/json, {dog}
通常、複数のリソースを更新するために、API を呼び出して複数の PUT リクエストを実行する必要があります。これは並行して実行できます。ただし、複数のリソースを同時に更新する必要がある場合は、次のような POST の使用を検討します。
POST
https://mydomain.com/dogs/update-many accept: application/json, [{dog1}, ...]
エラーのシナリオに関しては、ドキュメントを通じて処理するのが最善です。ユーザーが動作を認識している限り、リクエスト全体を拒否してロールバックするか、送信された各エンティティの識別子/成功ステータスを含む応答を返すことが有効だと思います。一般的に、私はレスポンスがリクエストの各項目ではなく、リクエストに直接関連していると考えています。したがって、リクエストの一部が失敗した場合は、エラー コードと説明を返します。リクエストのいずれかの部分が永続的な影響を与えると想定する場合、ユーザーは常に 2XX コードを期待する方が簡単だと思います。