Every backend API interaction is defined by a pair: an action intent (the HTTP method) and a standardized result (the HTTP status code). Master the safety and idempotency rules governing GET, POST, PUT, PATCH, and DELETE, navigate all 5 status code classes, resolve commonly confused codes, and test live contracts in an interactive API playground.
How HTTP methods and status codes establish a predictable language between client and server.
When a frontend, mobile app, or terminal communicates with a backend API, it does not send random commands. Instead, it structures communication using standard HTTP requests and receives standard HTTP responses.
Every API interaction is composed of four fundamental elements:
/api/courses or /api/courses/42).A backend engineer does not just “write functions”. You design an API contract. If your backend returns 200 OK with an error message inside the body (e.g. { "error": "password too short" }), the browser's response.ok will evaluate to true! Proper status codes ensure that HTTP caching proxies, browsers, SDKs, and frontend error handlers work seamlessly without manual guessing.
Mastering the 5 primary REST methods under IETF RFC 9110 specifications.
Under IETF RFC 9110 (HTTP Semantics), methods are defined by two critical formal properties:
| Method | Intended Action | Safe? | Idempotent? | Carries Body? | Typical Backend Use |
|---|---|---|---|---|---|
| GET | Retrieve resource representation | YES | YES | No (ignored) | Read records from database, cacheable |
| POST | Create subordinate resource / process payload | NO | NO | YES | Insert new records, execute payment transactions |
| PUT | Completely replace target resource or create at URI | NO | YES | YES | Overwrite entire document/record; repeated calls produce same state |
| PATCH | Apply partial delta modification to resource | NO | NO (by RFC spec) | YES | Update 1 or 2 fields (e.g. change status to “published”) |
| DELETE | Remove target resource | NO | YES | No (uncommon) | Delete row from database; deleting an already deleted item leaves state empty |
{ "title": "New" }, the price and category are reset or wiped!{ "price": 1999 }, title and category remain completely untouched./api/courses). The server creates a brand new ID. Calling it 5 times creates 5 separate database rows./api/courses/42). Calling it 5 times leaves the exact same single record with the exact same values.Navigating status code families and resolving commonly confused codes in full-stack engineering.
HTTP status codes are 3-digit integers categorized into 5 distinct classes based on their first digit:
Informational: Request received, process continuing (e.g. 100 Continue, 101 Switching Protocols).
Successful: The action was received, understood, and accepted (200 OK, 201 Created, 204 No Content).
Redirection: Further action must be taken to complete request (301 Permanent, 302 Found, 304 Not Modified).
Client Error: Bad syntax, invalid data, or unauthorized (400, 401, 403, 404, 405, 409, 422, 429).
Server Error: The server failed to fulfill an apparently valid request (500, 502, 503).
price: -50 or missing required email field). Standardized in RFC 9110; default in frameworks like FastAPI.WWW-Authenticate header.DELETE /api/courses). Must include an Allow header.While RFC 9110 specifies semantic standards, framework conventions can differ: Express APIs frequently return400 Bad Requestfor schema validation errors, whereas Python's FastAPI and Ruby on Rails default to 422 Unprocessable Content for Pydantic/ActiveRecord validation errors. Both are accepted production practices.
Dispatch requests across simulated RESTful resources and inspect status codes, headers, and bodies.
Use the interactive API workbench below to experiment with HTTP methods and endpoints. Click any of the quick presets or customize the method, URL, and JSON request body to observe how the backend responds.
Identify and fix realistic method and status-code anti-patterns seen in broken backends.
A backend API that returns incorrect HTTP methods or misleading status codes breaks frontend error handlers, caches corrupted data, and creates security vulnerabilities. Analyze each of the 6 realistic failure scenarios below and select the proper architectural fix.
A developer creates an endpoint `GET /api/courses/create?title=Microservices` that inserts a row into the database whenever a user navigates to it.
// Broken Express Handler
app.get("/api/courses/create", async (req, res) => {
const course = await db.courses.create({ title: req.query.title });
res.json(course);
});How HTTP methods map to database operations, and how frontend code reliably handles status codes.
In a complete Full Stack application, HTTP methods and status codes serve as the universal bridge connecting frontend UI events to backend database queries:
| HTTP Method | CRUD Operation | SQL Operation | Typical Success Status | Typical Error Statuses |
|---|---|---|---|---|
| GET | Read | SELECT | 200 OK | 404 Not Found, 401 |
| POST | Create | INSERT | 201 Created | 400, 422, 409 Conflict |
| PUT | Replace | UPDATE (all columns) | 200 OK | 400, 404, 422 |
| PATCH | Partially Update | UPDATE (target columns) | 200 OK | 400, 404, 422 |
| DELETE | Delete | DELETE | 204 No Content | 404, 403 Forbidden |
async function updateCoursePrice(courseId, newPrice) {
const response = await fetch(`/api/courses/${courseId}`, {
method: 'PATCH',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${getToken()}`
},
body: JSON.stringify({ price: newPrice })
});
// 1. response.ok evaluates to true ONLY for 200-299 status codes
if (!response.ok) {
if (response.status === 401) {
redirectToLogin();
return;
}
if (response.status === 403) {
showToast("Access Denied: You do not have permission to edit prices.");
return;
}
if (response.status === 422) {
const errorData = await response.json();
displayFormErrors(errorData.field, errorData.message);
return;
}
throw new Error(`Server error: ${response.status}`);
}
// 2. Parse successful representation
const updatedCourse = await response.json();
return updatedCourse;
}Design the correct HTTP method and status code for 8 real-world backend API operations.
GET is safe and idempotent. PUT and DELETE are idempotent. POST and PATCH are non-idempotent.
2xx for Success, 3xx for Redirection/Caching, 4xx for Client Errors, and 5xx for Server Crashes.
Never return 200 for failures, never return 500 for invalid user input, and use 403 when identity is known but forbidden.