CRUD アクションに対応する HTTP メソッドとステータスコードを提案
createと入力すると、標準的な方式と201 Created、経路の例、慣習の説明が分かります。updateでは全体を置き換えるPUTを示し、部分的な変更ならPATCHも紹介します。同じ操作には常に同じ答えです。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 操作
- create
- ステータス
- 201
- ステータステキスト
- Created
- パスのヒント
- POST /resources
認識できないアクションは、受け付ける値の一覧を示した明確なエラーで拒否されるため、自動化の中のタイプミスが誤ったルートを黙って生み出すことはありません。
更新に PUT を使う理由と PATCH の位置づけ
この表で最も議論の絶えない項目は update です。PUT はクライアントが送信した表現でリソース全体を置き換えるため冪等であり、同じ PUT を2回送ってもサーバーの状態はまったく同じになります。返される注記にはその旨が明記されているため、レビュアーは対応付けを教条として扱うのではなく、代替案を確認できます。
設計上重要なのは、1つの規約を選び、すべてのリソースに一貫して適用することです。スキャフォールディングツールやコードレビューのチェックリストに組み込まれた決定的な参照は、まさにこの種の判断を徹底するのに役立ちます。
ステータスコードは答えの半分
もう半分は成功時のステータスコードであり、これを間違えるとクライアントを混乱させます。201 Created ではなく 200 OK を返す create は壊れてはいませんが、仕様が無料で提供するシグナルを無駄にしており、ステータスで分岐する自動化クライアントは誤読します。
空のボディとともに 200 を返す delete は、204 No Content ならステータス行だけですべてを伝えられた場面で、クライアントに無意味な解析を強いることになります。
ここで返される対応付けは、すべてのアクションに成功時に返すべきステータス、すなわち create に 201、read・update・list に 200、delete に 204 を、標準の理由フレーズとともに組み合わせています。これにより、生成されるドキュメントや OpenAPI の responses セクションは構造的に正しいものになります。
エラーは意図的に対象外です。本機能は正常系の規約のみに答え、認識できないアクション名に対しては近い値を推測するのではなく、受け付ける5つの値を列挙した明確なメッセージで拒否します。
よくある質問
料金はいくらですか?
同じ対応付けは、このページ上でブラウザから無料でも実行できます。
どのアクションが受け付けられますか?
create、read、update、delete、list です。大文字小文字は区別されず、前後の空白も無視されます。それ以外は、受け付けられる値の一覧を示すエラーで拒否されます。
更新に PATCH ではなく PUT なのはなぜですか?
PUT は慣例的な冪等の完全置換であり、対応付けはこれを返します。
答えがランダムになったり、モデルで生成されたりすることはありますか?
いいえ。 対応付けは固定された決定的な表であり、同じアクションには常に同じメソッド・ステータス・注記が返ります。
作成の操作は200と201のどちらを返すべきですか?
201 Createdです。通常は新しい資源を指すLocationヘッダーを付けます。200 OKでも誤りではありませんが、仕様がすでに用意している合図を生かせず、状態で処理を分ける相手が誤解します。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/dev/http-method-from-action-suggest \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"create"}'const res = await fetch("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"action": "create"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/http-method-from-action-suggest",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"action": "create"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"action":"create"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"action":"create"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/http-method-from-action-suggest", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"action": "create"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
CRUD アクション用 HTTP メソッド対応エンドポイントは、API 設計者が日々何度も抱く疑問に答えます。create・read・update・delete・list といったアクションに対して、エンドポイントはどの HTTP メソッドを使うべきか、成功時にはどのステータスコードを返すべきか、という問いです。アクション名を1つ送信するだけで、慣例的な REST の動詞、理由フレーズ付きの典型的な成功ステータス、ルートの一般的な書き方を示すパスヒント、そして規約を説明する短い注記が返されます。これは推測ではなく決定的な対応付けであり、モデルを介さず、同じアクションには常に同じ答えが返ります。ルートのスキャフォールディング、API 設計のレビュー、OpenAPI の骨格生成、あるいは PUT と PATCH を混同しがちなチームへの REST 規約の指導にご活用ください。
慣例的な対応付けを1つの表で
安全かつ冪等であるため、キャッシュやリトライを積極的に行うことが許されます。update はクライアントがリソースを完全に置き換える場合に PUT に対応し、更新後の表現とともに 200 OK を返します。REST は4つの永続化操作を HTTP 動詞に対応付け、さらに実際の API が必要とするコレクション読み取りを加えます。create はコレクションへの POST に対応し、慣例的に 201 Created を返します。多くの場合、新しいリソースを指す Location ヘッダーが伴います。read は単一リソースへの GET に対応し、200 OK を返します。このエンドポイントも冪等であり、リクエストを再送しても余計な害は生じません。delete は DELETE に対応し、説明すべきものが残らないため、通常は 204 No Content を返します。list はコレクションへの GET に対応して 200 OK を返し、ページネーション・フィルタリング・ソートのクエリパラメータがここに置かれます。このエンドポイントは、その表の1行を理由付きでそのまま返すため、スタイルガイドを読み直さずに、答えを設計書に貼り付けたりテストで検証したりできます。
更新に PUT を使う理由と PATCH の位置づけ
本機能は HTTP 仕様の厳密な解釈に従います。この性質こそが、PUT を更新エンドポイントの慣例的な既定とし、本 API が update アクションに対して返す答えたらしめるものです。一方 PATCH は、クライアントが変更されたフィールドのみを送信し、サーバーがそれをマージするというもう1つの一般的なケースのために存在します。実際には多くの本番 API が部分更新に PATCH を使い、完全置換に PUT を予約しており、PUT をまったく使わない例もあります。
ステータスコードは答えの半分
動詞を選ぶことはエンドポイント設計の半分にすぎません。
連携の活用例
REST ルートのスキャフォールディング
新しいリソースのルート雛形を生成し、各 CRUD アクションに慣例的な動詞とステータスをあらかじめ設定します。
API 設計のレビュー
提案されたエンドポイント一覧を慣例的な対応付けと照合し、逸脱しているルートをリリース前に洗い出します。
REST 規約の教育
レビューのたびに再議論する代わりに、動詞とステータスの問いに対する単一の決定的な参照をチームに提供します。
技術的な質問
エラーのステータスコードも扱いますか?
いいえ。慣例的な成功系のみに答えます。HTTP メソッド、典型的な成功ステータスコード、規約の簡単な説明が対象です。
認識できないアクションを送るとどうなりますか?
受け取った値を示し、受け付けられる5つのアクションを列挙したメッセージを含む invalid_input エラーでリクエストが失敗します。