REST APIでビジネスルールを処理する方法は？
私はREST予約システムを管理するためのAPIを持っています。この状況を管理する方法を検索しています：
顧客は時間枠を予約できます：TimeSlotリソースが作成され、Personリソースにリンクされます。タイムロットと人との間にリンクを作成するために、RESTクライアントはTimeSlotリソースでPOSTリクエストを送信します
ただし、同じスロットを予約する人が多すぎる場合（制限が5リンクであるとしましょう）、これ以上の関連付けを作成することは不可能です。
このビジネス制限をどのように処理できますか？ステータスコードでエラーの詳細を示すJSON応答で404ステータスコードを返すことはできますか？
RESTFulアプローチですか？
編集：
以下に示すように、エラーの詳細を示すJSON応答に加えてステータス409の競合を使用しました
編集2：
@Cormac Mulhallで詳述されているように、403 Forbiddenはこのケースの最も正確なステータスコードです
403 Forbiddenにしたい。 HTTP仕様から
403 Forbidden：サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。
409は使用しないでください。これは、クライアントが競合を解決できる可能性があることを意味します。これは、クライアントをオーバーブッキングした場合、競合ルールがサーバー側であるため実行できません。
HTTPステータスコードのコンテキストでは、「競合」はリソースの状態（この場合は本のタイムスロット）の競合を意味します。 たとえば、1つの形式で時間を期待し、間違った形式で送信した [悪い例、バージョン管理されたシステムのように、2つのクライアントが同時にリソースを更新し、サーバーがどの更新を保存するかを判断できない場合。リソースはタイムスロットです。別のタイムスロットに変更した場合、別のリソースを作成していても、このリソースとの競合は解決されていません。
409 Conflict：リソースの現在の状態との競合のため、リクエストを完了できませんでした。このコードはユーザーが競合を解決してリクエストを再送信できることが期待される状況でのみ許可されます。
サーバーは403 Forbiddenを返し、そのタイムスロットがすでにいっぱいであるため、状態の保存を拒否していることを説明します。リソースの状態を変更する際にクライアントが実行できることは、それを変更することはできません。クライアントは再送信しないでください。代わりに新しいタイムスロットを作成する必要があります（提案として、最も近い空きスロットを返すことができます）。
404は、リソースが見つからないことを示します。より適切な応答コードは 409 で、競合の性質がある場合は本文に詳細が含まれます。
注意：Cormac Mullhallの回答を参照してください
404はリソースが見つからないことを意味します。ここでの使用は適切ではありません。リソースは明らかに存在しますが、操作することはできません。クイックヒントによると（ http://www.restapitutorial.com/lessons/restquicktips.html ） 409紛争は良い方法です。もちろん、本文にエラーメッセージが含まれる200を返すこともできます。クライアントは、応答を読んで対処する責任があります。