REST：DELETEおよびビジネスロジック条件

Question

REST APIでビジネスロジックを実施する際のデファクト/従来の慣行と、使用されるHTTPステータスコードは何ですか？

たとえば、Playerエンティティとチームエンティティがあるとします。チームは任意の数のプレイヤーを持つことができます。

私のビジネスロジック（現時点では）が、すべてのプレーヤーが最初にチームから明示的に削除されるまで、チームが削除されないようにしているとします。

あなたは

DELETE http://api.foo.com/teams/15

を実行し、それはまだそれに関連付けられているプレーヤーを持っている場合は、HTTP 409（競合）、またはHTTP 412（前提条件が失敗）を返すでしょうか？オプティミスティックなロック条件を示すために409を使用する方が好きなので、より論理的です。

おそらく、ビジネスロジックの条件をREST APIにも適用する必要がありますか？誰かが

DELETE http://api.foo.com/teams/15

を実行した場合つまり、そのちょうどすべてのプレーヤーを削除して、自動的にチームを削除するべきではないのですか？ UIインターフェイスよりもREST APIが少し「低レベル」または「未処理」として認識されるため、DELETEを実行できるようにするのがより一般的ですか？

最後に、リソースURI内のクエリのparamについてどのような：

DELETE http://api.foo.com/teams/15?force=true

を示し、「はい、私はこれはまだチームの選手で許可されないことを知っているが、やりますそれはとにかく "。

ここでの考え方は、チームを削除することは重大な影響を与える重大な操作であり、エンドユーザーが本当に望んでいると確信している場合にのみ行うことです。

言い換えれば、あなたは手持ちしていますか（「確かですか？」というエラーコードを使用していますか？これがUIでのみ実行されるべきか、REST APIで実行されるべきか、あるいはその両方でなければならないかは、私はあまりよく分かりません。今日、ほとんどの人がこれをどのように解決していますか？

Answer 1

クライアントは、ビジネス上の理由のために有効な要求ではなかった何かをしようとしました。したがって、私は400を使用します。追加の詳細を伝えたい場合は、ReasonPhrase/entity本体を使用してください。

Answer 2

412は、リクエストヘッダーフィールドの評価に基づいているため、この場合は正しくありません（HTTP 412の使用の場合はthis questionを参照）。ここでの正しいステータスコードは403禁止されています。つまり、要求は理解されていますが、要求は拒否されており、承認は役に立ちません。レスポンス本文でクライアントに詳細を提供することができます。

ビジネスロジックを実装する必要があるかどうかは、完全にあなた次第です。 ACLに基づいてこの種のチェックを実装することもできます。たとえば、特定のユーザーはすべてのプレーヤーが削除された後にのみチームを削除でき、管理者はチームを削除することができます。プレイヤーがいるチームのDELETEリクエストを作成している管理者以外のユーザーが、401 Unauthorizedを返すようになりました（つまり、そのクレデンシャルに対してアクションが拒否されました）。管理者ユーザーには200が返されます。

EDIT：詳細は、常にRFC 2616にあります。

Answer 3

ロータスノートでRESTサービスがホストされている場所で働いていた場合、ロータスノートからエントリを削除する必要がある場合は、trueパラメータを 'confirm/force'に設定する必要がありました。 ）は削除を認識しています。あなたのサービスがRESTサービスの場合、私はUIレベルでは十分ではないと思いますが、REST URLでも同じ制約が必要です。

あなたが言及したように私は（チームが選手を削除する必要があります削除）任意のシナリオが発生していないが、私は、この特定の場合にはより多くの方の412のコードをもたれるでしょう。