GET
Read a list or one resource. A successful response commonly uses status 200 OK.
A practical introduction to resources, routes, HTTP methods and JSON responses.
An API is a contract that lets software communicate. A REST API models useful nouns as resources, gives them predictable URLs and uses standard HTTP methods to describe the action. A notes API might expose /api/notes for a collection of notes.
Start by listing the resource your product owns: users, notes, products or bookings. Give that resource a predictable URL and decide what the client needs to send and receive before writing the route handler.
Read a list or one resource. A successful response commonly uses status 200 OK.
Create a resource after validating the request body. Return the created record with 201 Created.
Update part of a resource with PATCH and remove it with DELETE. Return clear status codes and errors.
Status codes communicate intent: 400 means the input is invalid, 401 means the caller needs to sign in, 403 means access is denied and 404 means a resource cannot be found.
POST /api/notes
Content-Type: application/json
{"title":"Plan launch","body":"Review deployment checklist"}
A successful server response can return JSON with the new record, an identifier and a timestamp. Keep the shape stable so a frontend can render it without special cases.
Use consistent JSON shapes, validate every input and never trust values from the browser. Document required fields, authentication rules and error responses so the frontend can handle the API confidently.
Return useful status codes, log unexpected failures on the server and keep secrets out of responses. A small API with a clear contract is easier to secure, test and evolve than a large collection of inconsistent endpoints.
When a list becomes large, add pagination instead of returning every record. Use filtering and sorting only where the product needs them, and version a breaking change rather than silently changing an existing response. These small choices protect clients as the API grows.