Slate Errors

Success (2xx)

201

Created

— 作成しました

まずは確認: よくある原因 TOP3

  1. REST API で POST が成功して新規レコード作成
    作成された URL は Location ヘッダに入る
  2. PUT で新しいリソースが置かれた
    既存更新なら 200、新規なら 201 が慣例
  3. ファイルアップロードが成功
    保存先の URL を返すパターンも 201 が自然

うまくいった証

201 は「君のリクエストで新しいリソースが生まれた、その置き場所はここだよ」と教えてくれる成功サインです。 プールに例えると、新しい泳ぎのコースが追加され、「君のレーンはこちら、ここから始めてね」と先生が場所まで案内してくれる——そんな段取りの良さです。

Location ヘッダに新しいリソースの URL が入るのが大切な約束で、クライアントはこれを読んでブックマークするなり、続きの操作で使うなりできます。POST 後の挙動として、200 よりも丁寧で意味のある応答です。

プールからのひとこと

プールに新しいレーンを引いたとき、先生はただ「できた」と言うだけでなく、「3番目のレーン、向こうから3つ目だよ」と場所まで指してくれます。生徒は迷わずそのレーンに泳ぎに行ける。

201 もまさにそれと同じ役割で、「作ったよ」だけで終わらせず、「ここに置いたよ」まで伝える。クライアントがそのまま次の操作に移れる、思いやりのあるサインです。

次への一歩

ここから先:

  1. Location ヘッダのURLを読む:作成されたリソースに直接アクセスできる
  2. 作成されたデータを画面に反映:レスポンスボディや Location 先のデータを使う
  3. 冪等性を意識した設計:再送に備えて重複作成を防ぐ仕組みを持っておく
  4. API ガイドラインに 201 の使い分けを書く (管理者向け):チーム内で 200 と 201 をいつ返すかを揃える

実際にはこう見える

$ リクエスト

curl -i https://example.com/some/path

↓ レスポンス

HTTP/1.1 201 Created
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html><body><h1>201 Created</h1></body></html>

似ているケース

もっと知りたい