重大なエラーではないREST APIの警告

DELETE、POST、またはPUTなどの一部のentpoindに対して、エラーを返す可能性のある検証ルールがあるREST APIを持っています。

クリティカルではないエラーのような新しいタイプのエラーが必要になりました。通常の方法でエラーが発生するはずですが、「警告の抑制」フラグが送信された場合はアクションに進む必要があります。このようなユーザーは、「このステータスを変更してもよろしいですか、まだ完了していません」と尋ねることができます。

質問：これらのタイプのエラーのベストプラクティスはありますか？

二次質問：

• 私が使用できるような動作のHTTPセマンティクスはありますか？
• 私はまだRESTのアイデアに従っていますか（私にとってはそうです）-私はそれをステートレスに保ちます

httpには警告結果コードはなく、成功（200）またはエラー（400、500）を返します。私が知っている唯一のことは、あなたが望むものに類似している可能性があります-コード401 'unauthorized'のようなものです-これは完全な失敗ですが、ほとんどのクライアントが自動的に資格情報との接続を再試行します。

REST APIの場合、リクエストのステータスと結果の処理方法をサーバーに通知する必要があります-クライアントが完了していない場合はPUTを送信できず、エラーが発生する可能性があります-完了している場合は成功-サーバーはこれを知る必要があります正しい結果コードを送り返すための情報。

そのため、リクエストに「警告を抑制する」フラグを送信できます。フラグが設定されていない場合、サーバーは409エラーコード（または類似のコード）を返し、設定されている場合は200コードを返します。ステータスの変更が送信された後、ユーザーに「このステータスを変更しますか」と尋ねることはできません。

サーバーにリクエストを出して、ユーザーがコースのステータスを変更できるかどうかを尋ね、その後適切なリクエストを続けることができます。

ユーザーが通常のエラー処理をオーバーライドできるようにする場合は、拡張HTTPヘッダーの追加情報を含む200 SUCCESSステータスを返すことを検討できます。たとえば、次を返すことができます

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

これにより、クライアント側のコードに、ユーザーに警告するか、自分で修正アクションを実行するために必要な情報が提供されます。