2

ユーザーが主に整数 ID で表されるシステムがあります。リソースがあります。これを X と呼びましょう。X は 2 人のユーザーに関連付けられています。1 人は X を作成し、もう 1 人は作成者が完了したときに X を承認します。X の承認者は、POST 経由で送信される (または後で編集できる) ときに作成者によって選択され、要求はユーザー ID によって承認者を識別します。追加の制限が 1 つあります。承認者と作成者はペアになります。承認者は、作成者が割り当てられている場合にのみ X を承認できます。

したがって、リクエストの承認者のユーザー ID に関して、いくつかの失敗例が考えられます。

  1. 不正な ID (非整数)
  2. 承認者 ID は整数ですが、その ID を持つユーザーは存在しません。
  3. 承認者 ID は既存のユーザーですが、そのユーザーには承認者の役割がありません。
  4. 承認者 ID は既存の承認者ですが、承認者は作成者に割り当てられていません。

400 はケース 1 の正しいステータス コードであることは明らかですが、2 ～ 4 の正しいステータス コードとは思えません。400 は不正な形式のリクエストを示しますが、2 ～ 4 はリクエストの解析ではなく、特に既存のデータに問題があります。409も考えましたが、リソース自体の問題のようです。これはリソース X に関連する追加リソースの問題です。406 も考えましたが、それは不明な形式 (JSON のみが受け入れられる場合の XML など) でコンテンツを提供することを目的としているようです。

では、クライアントが適切な形式で不適切なデータを提供したことを示すには、どのステータス コードが適切でしょうか?

4

2 に答える 2

2

@Will の 1 & 2 - 404 に同意します。

3 と 4 については、409 を使用します。一般的なケースでは (承認者は後で変更できるとおっしゃいました)、以下の間に (私が見ることができる) 実際の違いはありません。

  • 承認者 ID は既存のユーザーですが、そのユーザーには承認者の役割がありません。

と

  • 承認者ID は既存のユーザーで、5 秒前は承認者でしたが、現在はそうではありません

したがって、編集の競合と同じように感じます。

于 2013-10-28T07:45:15.140 に答える