HTTP method for a CRUD action
Type create and get the conventional method with 201 Created, a route hint and a note on the convention; update returns PUT for a full replacement and points to PATCH for partial changes. Same action, same answer, every time. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Action
- create
- Status
- 201
- Status text
- Created
- Path hint
- POST /resources
Unrecognized actions are rejected with a clear error listing the accepted values, so a typo in automation fails loudly instead of silently producing a wrong route.
Five actions, one convention
Most web services map their actions onto a small set of methods: create, read, update and delete, plus listing a collection, which almost every real service also needs. For each action you get the conventional method, the usual success status with its reason phrase, a hint of how the route is written and a short note explaining why. Reading a single resource answers 200 OK and is safe to repeat, which is why caches and retries can be aggressive with it. The mapping is a fixed table, not a guess, so the same action always gives the same answer.
PUT or PATCH, and why the status matters
The most debated cell is update. PUT fits when the client replaces the resource in full; PATCH fits when it only sends the changed parts and the server merges them, and the note says so, so a reviewer sees the alternative. What matters most is picking one convention and applying it to every resource. The status carries meaning too: a create that answers 200 instead of 201 wastes a signal, and a delete that sends 200 with an empty body makes clients parse nothing where 204 No Content says it all. Unknown action names are refused, with the five accepted values listed.
Why PUT for update, and where PATCH fits
The most argued-over cell in the table is update. PATCH exists for the other common case, where the client only sends the fields that changed and the server merges them; the returned note says so explicitly, so a reviewer sees the alternative instead of treating the mapping as dogma. In practice many production APIs use PATCH for partial updates and reserve PUT for full replacement, and some skip PUT entirely.
The important thing for a design is to pick one convention and apply it uniformly across every resource, which is precisely the kind of decision a deterministic lookup helps enforce when it is wired into scaffolding tools and code review checklists.
Status codes are half of the answer
A create that answers 200 OK instead of 201 Created is not broken, but it wastes a signal the specification gives for free, and automated clients that branch on the status will misread it. A delete that answers 200 with an empty body forces the client to parse nothing where 204 No Content would have said everything in the status line.
Errors are deliberately out of scope: the capability answers the happy-path convention only, and rejects unrecognized action names with a clear message listing the five accepted values rather than guessing a near match.
FAQ
What does it cost?
The same mapping also runs free in your browser on this page.
Which actions are accepted?
create, read, update, delete and list. Matching is case-insensitive and surrounding whitespace is ignored; anything else is rejected with an error that lists the accepted values.
Why PUT and not PATCH for update?
PUT is the conventional idempotent full replacement, which is what the mapping returns. The note in the response points out PATCH as the standard choice for partial updates so you can choose deliberately.
Is the answer ever random or model-generated?
No. The mapping is a fixed deterministic table; the same action always returns the same method, status and note.
Should a create action answer 200 or 201?
201 Created, usually with a Location header pointing at the new resource. A 200 OK is not broken, but it wastes a signal the specification already provides, and clients that branch on the status will misread it.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
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)Example request
{
"action": "create"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
The HTTP method for CRUD action endpoint answers the question every API designer asks a dozen times a day: given an action like create, read, update, delete or list, which HTTP method should the endpoint use, and which status code should a successful call return? You send a single action name and get back the conventional REST verb, the typical success status with its reason phrase, a path hint showing how the route is usually written, and a short note explaining the convention. It is a deterministic mapping, not a guess: the same action always produces the same answer, with no model involved. Use it when scaffolding routes, reviewing an API design, generating OpenAPI skeletons, or teaching REST conventions to a team that keeps mixing up PUT and PATCH.
The conventional mapping, in one table
REST maps the four persistence operations onto HTTP verbs, plus the collection read that every real API also needs. Create maps to POST on the collection and conventionally answers 201 Created, often with a Location header pointing at the new resource. Read maps to GET on a single resource and answers 200 OK; it is safe and idempotent, which is why caches and retries are allowed to be aggressive with it. Update maps to PUT when the client replaces the resource in full, answering 200 OK with the updated representation; the same endpoint is idempotent, so a retried request does no extra harm. Delete maps to DELETE and typically answers 204 No Content, since there is nothing left to describe. List maps to GET on the collection, answering 200 OK, and is where pagination, filtering and sorting query parameters live. This endpoint returns exactly that row of the table, with the reasoning attached, so the answer can be pasted into a design document or asserted in a test without re-reading a style guide.
Why PUT for update, and where PATCH fits
This capability follows the stricter reading of the HTTP specification: PUT replaces the entire resource with the representation the client sends, which makes it idempotent — sending the same PUT twice leaves the server in exactly the same state. That property is what makes PUT the conventional default for an update endpoint and the answer this API gives for the update action.
Status codes are half of the answer
Choosing the verb is only half of designing an endpoint; the success status code is the other half, and getting it wrong confuses clients. The mapping returned here pairs every action with the status a successful call should produce — 201 for create, 200 for read, update and list, 204 for delete — together with the standard reason phrase, so generated documentation and OpenAPI responses sections come out correct by construction.
Integration use cases
Scaffold REST routes
Generate route stubs for a new resource with the conventional verb and status already filled in for each CRUD action.
Review an API design
Check a proposed endpoint list against the conventional mapping and flag the routes that diverge before they ship.
Teach REST conventions
Give a team a single deterministic reference for the verb-and-status question instead of re-litigating it in every review.
Technical questions
Does it cover error status codes?
No. It answers the conventional success path only: the HTTP method, the typical success status code and a short explanation of the convention.
What happens on an unrecognized action?
The request fails with an invalid_input error whose message names the received value and lists the five accepted actions.