202 Accepted

使い方

202 Accepted ステータスコードは受領確認として機能します。サーバーはリクエストを受け取り、送信された内容を処理する意思があることを示します。実際には、サーバーがリクエストの形式を検証し、その作業を内部のキューに入れたことを意味します。キューに入れられたタスクは多くの場合、長時間かかる処理やバッチ操作の一部です。

最終的な結果を示す後続のレスポンスをサーバーが送信する仕組みは存在しません。サーバーがステータスエンドポイントを公開している場合に限り、クライアントが定期的にポーリングする責任を負います。

SEO への影響

Googlebot は 202 レスポンスに遭遇すると、コンテンツを短時間待ちます。待機期間内に受け取ったコンテンツはインデックス登録パイプラインへ渡されますが、インデックス登録は保証されません。

200 の成功レスポンスが届いた時点でポーリングは停止します。その他の有効な結果としては、新しいリソースが作成されて Location ヘッダーの URI で利用可能な場合の 201 や、返す内容なしでジョブが完了した場合の 204 があります。

例

クライアントがジョブを定義する XML データを POST します。サーバーは送信を受領確認します。クライアントによる以降のリクエストで作業が完了したかを確認します。最終的に、サーバーが完了を伝えます。

リクエスト

POST /job HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 68

<?xml version="1.0"?>
<job>
  <id>125</id>
  <task>G01</task>
</job>

レスポンス

HTTP/1.1 202 Accepted
Link: </job/status/125>; rel="http://example.re/job-status"
Content-Length: 0

ステータスリクエスト 1

GET /job-status/125 HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 202 Accepted
Content-Length: 0

ステータスリクエスト 2

GET /job-status/125 HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 18

{"success":"true"}

200 ステータスコードが届いたあと、クライアントはポーリングを停止し、その結果に基づいて動作します。

202 におけるレスポンスボディ

202 Accepted レスポンスにはメッセージボディを含めることが認められています。ボディには通常、リクエストの現在のステータス、ステータスモニターのエンドポイントへのリンク、または操作完了見込み時刻の見積もりが含まれます。作成されたリソースを指す 201 とは異なり、202 のボディは保留中の操作そのものを説明します。

202 と 201 の比較

201 レスポンスは、リソースが作成され直ちに利用可能であることを確認します。202 レスポンスは、リクエストを受け取ったものの処理が完了していないことを確認します。レスポンスの時点でリソースが存在する場合は 201 を使います。作業がキュー化されているか非同期であり、最終的な結果がまだ分からない場合は 202 を使います。

コードリファレンス

.NET

HttpStatusCode.Accepted

Rust

http::StatusCode::ACCEPTED

Rails

:accepted

http.StatusAccepted

Symfony

Response::HTTP_ACCEPTED

Python3.5+

http.HTTPStatus.ACCEPTED

Java

java.net.HttpURLConnection.HTTP_ACCEPTED

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_ACCEPTED

Angular

@angular/common/http/HttpStatusCode.Accepted