[225] 202 (Accepted) は、処理を受け付けたことを示す状態符号です。
[221] 202 は、応答の処理は受け付けられたものの、
処理はまだ完了していないことを示します。要求が実際に処理される時にはもう認められなくなっている可能性がありますから、
要求が実際に処理されるかされないかはわかりません。 >>220
[223] 202 は、1日に1回だけ実行されるバッチ処理のようなもので処理完了まで利用者エージェントと鯖とを接続したままにせずに済ませるためのものです。
>>220
[9] Webサーバーの要求の処理で同期的に実行されるのでなく、 裏側のワーカーで非同期的に実行される処理を実行するよう指示した (ジョブキューに追加した) 時に使うことができます。
[8] 202 が返されたとしても、実際に処理を開始したら失敗する可能性はあります。
クライアントは 202 応答のみから処理結果を確実に得ることはできません。
[224] 202 応答の表現は、要求の現在の状態を説明すると共に、
利用者に要求が満足される時期の見通しを示す状態監視器を指す (埋め込む)
ものとするべきです >>202。
[10] ジョブキューに処理を追加する (>>9) ような場合で、 処理の進行状況を観測する方法があるなら、 その URL などを応答に含めるのが適切と考えられます。
[218] 起源鯖は、処理が成功した場合には、
処理が成功するであろうものの実施されていない場合には 202 を、
実施され追加情報は特に無い場合には 204 を、
実施され応答メッセージに状態を説明する表現を含める場合には 200
を返すべきです >>215。
[2] 串は要求に Prefer: respond-async
が指定されていた場合に起源鯖から応答が返される前に
202 を返すことができます >>1。
[12] HTTP 利用者エージェント全般で特にこの状態符号であることから行うべき処理はありません。 Webブラウザーも特別な処理は行いません。
[13] 特定目的のクライアントは、状態符号により処理を分岐するかもしれません。 例えば時間がかからなそうな処理は同期的に実行して結果を返し、 時間がかかりそうな処理は非同期的に実行することとしてジョブIDを返し、 どちらにするかはサーバーが判断するようなアプリケーションでは、 サーバーが本状態状態を適切に使うことで、 クライアントは結果の受信時の処理を分岐させることができます。
The request has been accepted for processing, but the processing has not been completed. The request
{2616} might or{1945} may{2068} MAY{2616} might not eventually be acted upon, as it{1945} may not{2068} MAY NOT{2616} might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.{1945} may{2068} MAY
要求の処理は受け入れられましたが、処理は完了していません。 要求は最終的に動作するかもしれないししないかもしれません。 実際に処理される際に禁止されるかもしれませんのです。 このような非同期処理の状態符号を再送する機能はありません。
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response
{1945} should{2068} SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
202 応答は、意図的に非引渡し的です。
その狙いは、サーバーに対する利用者エージェント接続を処理完了まで永続的に必要とすることなく、
サーバーが他の何らかの処理 (多分自動処理志向処理で1日に何度かだけ走るとか)
の要求を受け入れることを可能にするところにあります。
この応答で返される実体は要求の現在状態並びに状態観察器又は利用者が要求が満たされると期待できる時間の見積もりの案内を含めるべきです。
The hub MUST respond to a subscription request with an HTTP [RFC2616] 202 "Accepted" response to indicate that the request was received and will now be verified (Section 5.3) and validated (Section 5.2) by the hub.
Store an artifact in the cache.
PUT /artifacts/key
status 202
Returning HTTP 202 Created and a Location header when creating a post
When the post is created, the Micropub endpoint must return either an HTTP 201 Created status code or HTTP 202 Accepted code, and must return a Location header indicating the URL of the created post. [RFC2616]
1xxとは違って、202は最後の応答で、要求に対する一連の応答はここで終わります。