[1] 201
(Created) は、
新たに資源が作成されたことを表す状態符号です。
[511] 例えば POST
要求によって新しい資源を作成することを求め、
鯖がその処理を成功させた場合には、鯖は 201
応答を返すことができます。この時 payload body には作成処理の結果や作成した資源の
URL などを含めることができます。また Location:
ヘッダーに作成した資源の URL を明記できます。
[2] 201
応答は Location:
頭欄を使用できます。 Location:
欄本体には作成された資源を識別する
URI を指定します。
[3] 201
応答は ETag:
頭欄を使用できます。 ETag:
欄本体には作成された資源異体の実体札を指定します。
[16] LDP は Link: ...; rel=describedby
によって作成された資源について記述することを認めています。
[4] 201
応答には実体本体を指定できます。
201
応答実体は、作成された資源についての情報を記述します。
具体的な書式は特に規定されていません。
[417] 起源鯖は、 POST
要求の処理に成功して1つ以上の資源が作られた時には、
201
応答を送信するべきです。
Location:
ヘッダーに作成された主たる資源の URL
を含めるべきです。表現は要求の状態と新しい資源への参照を説明したものとするべきです。
>>412
[9] 207
応答の内部で 201
を使う時は、 Location:
ヘッダーのかわりに
location
要素を使います。
[510] 起源鯖は、対象資源が現在表現を持っておらず、 PUT
によってその作成に成功した場合には、 201
を送信しなければなりません >>507。
[8] LOCK
要求により新たな資源が作られた際は、
201
応答を返さなければなりません >>7。
[12] MKCOL
要求 >>11 や
COPY
要求 >>13 や
MOVE
要求 >>15
により新たな資源が作られた時は、201
応答を返します。
[14] COPY
要求 >>13 や
MOVE
要求 >>15 に対する 207
応答内の status
要素では、
201
は使うべきではありません。
[512] 3xx
応答と同じ Location:
ヘッダーを使ってはいますが、 (少なくても 3xx
と同じ意味の)
HTTPリダイレクトとは異なります。利用者エージェントは普通は
Location:
で指定された URL に自動的にアクセスすることはありません。
[6] RFC 2068 以前からある部分は資源を作成
すると書いていますが、
RFC 2616 で追加された ETag:
欄の説明の部分では異体を作成
と言っています。
201
はまったく新しい資源を作成した時に限らず、
既存の資源の新しい異体を作成した場合 (例えば HTML 版に加えて XHTML
版を作成した場合) にも使って良いのかもしれません。
[203] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) <http://tools.ietf.org/html/rfc7252#section-5.9.1.1>
[5] 201
応答を返し得る method
には、 POST
, PUT
などがあります。
[10] 新しい資源が作成された時に 201
応答を使うことができますが、
201
を使う義務はありません。例えば自動的に作成した資源に利用者を移動させたいなら、
302
がより適切です。また作成が主たる処理ではなく副次的なものなら、
200
や 302
など他の状態符号がより適切かもしれません。
Location:
があればその URL により、 なければ実効要求URLにより識別されます >>513。