KRYZO.

Backend guide · 8 min read

Building Your First REST API

A practical introduction to resources, routes, HTTP methods and JSON responses.

Modern web application interface powered by an API

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.

HTTP methods and status codes

GET

Read a list or one resource. A successful response commonly uses status 200 OK.

POST

Create a resource after validating the request body. Return the created record with 201 Created.

PATCH and DELETE

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.

A small request and response

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.

Keep the contract predictable

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.

Plan for growth

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.

Back to all blogs