ユーザーにメッセージを送信するアプリケーションがあります。ポストリクエストでは、その特定のメッセージを受信する必要があるすべてのユーザーで構成されるXML文字列が転送されます。リスト内のいずれかのユーザーが存在しない場合は、欠落しているユーザーのリストをクライアントに返して、さらに評価します。
ここで、リクエストが受け入れられたが、実行できないことがあったことを示す、アプリケーションの適切なステータスコードを教えてください。
リストに行方不明のユーザーを含めることが許可されていない場合、問題は回避されます。その後、送信しようとすると、4xxエラーが発生します。しかし、このようにAPIを作成しても意味がありません。一方、エラー条件は純粋にアプリケーション固有であると考えることができます。しかし、200を送信するだけでは正しくありません。また、エラーレスポンスを詳しく調べるときに、クライアントにヒントを与えるとよいでしょう。たとえば、そのユーザーに何度もメッセージを送信しないようにする
回答:
私は非常によく似た問題に対処しました。この場合、私は
207マルチステータス
これは厳密なHTTPではなく、WebDAV拡張機能の一部であるため、クライアントも制御できない場合、これは適切ではありません。もしそうなら、あなたはそのようなことをすることができます：
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:user>user-123</D:user>
<D:status>success</D:status>
</D:response>
<D:response>
<D:user>user-789</D:user>
<D:status>failure</D:status>
</D:response>
</D:multistatus>
ただし、これもHTTP拡張であり、クライアントも制御する必要があります。
私は同じ問題を抱えており、2つの異なるソリューションを使用することになりました。
202: Accepted。要求は問題なかったことを示しますが、実際にすべてが正常に機能したことを保証するものではありません。200応答で通常を返しますが、応答の本文には正常に処理されなかったもののリストを含めます。通常、2番目の方法が最もよく機能しますが、1番目の方法は、処理が遅い場合やキューを使用して処理する場合に最適です。
ハイパーテキスト転送プロトコルは、物事の送信側を扱います。アプリケーションレベルのエラーを処理するためのエラーコードはありません。
ここで200を返すのは正しいことです。HTTPに関する限り、要求は適切に受信され、適切に処理され、応答を送り返します。したがって、HTTPレベルではすべてがOKです。httpの上で実行されているアプリケーションに関連するエラーまたは警告は、応答内にある必要があります。そうすることで、期待した方法で特定の応答を処理できないプロキシサーバーで発生する可能性のある厄介な問題も回避できます。