A REST API is a web service that follows REST (Representational State Transfer) principles. Clients make HTTP requests to URLs, and the server returns data — usually JSON. It uses standard HTTP methods like GET, POST, PUT, and DELETE.

Backend Guide

What Is a REST API?

Q: What are the HTTP methods?

GET reads data, POST creates data, PUT updates data (full), PATCH updates data (partial), DELETE removes data. These map to Create, Read, Update, Delete (CRUD) operations.

Q: What is a REST endpoint?

An endpoint is a specific URL that accepts a specific HTTP method. For example, GET /users returns a list, POST /users creates a user, and DELETE /users/5 removes user 5.

Q: Is REST better than GraphQL?

Both are fine. REST is simpler and standard. GraphQL lets clients request exactly the data they need. Most public APIs use REST.

Q: What status codes should I know?

200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error. These are the ones you'll see 99% of the time.

A REST API is how applications talk to each other over the web. Almost every app you use — Instagram, Stripe, Uber — is built on REST APIs. Here's how they work.

Quick answer: A REST API is a web service that responds to HTTP requests. Clients send requests to URLs using methods (GET, POST, PUT, DELETE), and the server responds with data — usually JSON. It's the standard way web and mobile apps talk to backends.

💡 Why REST APIs Matter

Separate frontend from backend. A React app, an iOS app, and a CLI tool can all talk to the same API.
Standardised. Any developer who knows HTTP can consume any REST API.
Stateless. Each request carries all the info needed — easy to scale.
Universal. Works over the same HTTP that powers the web.
Cache-friendly. GET requests can be cached by browsers and CDNs.

🔌 The 5 HTTP Methods (CRUD)

GET — read data. GET /users returns a list.
POST — create data. POST /users creates a new user.
PUT — replace data. PUT /users/5 replaces user 5 completely.
PATCH — update partially. PATCH /users/5 updates only the fields you send.
DELETE — remove data. DELETE /users/5 removes user 5.

📋 A Real REST API Example

Imagine a blog API. Here's what the endpoints might look like:

GET    /posts           List all posts
GET    /posts/42        Get one post
POST   /posts           Create a new post
PUT    /posts/42        Replace post 42
PATCH  /posts/42        Update post 42
DELETE /posts/42        Delete post 42

GET    /posts/42/comments    List comments on post 42
POST   /posts/42/comments    Add a comment

Notice the pattern: nouns (posts, comments), not verbs (getPosts, createComment). The HTTP method is the verb.

📨 Request and Response

Every REST call has a request and a response.

Request — creating a post:

POST /posts HTTP/1.1
Content-Type: application/json

{
    "title": "Hello World",
    "body": "My first post"
}

Response — server acknowledges:

HTTP/1.1 201 Created
Content-Type: application/json

{
    "id": 43,
    "title": "Hello World",
    "body": "My first post",
    "created_at": "2026-10-04T12:00:00Z"
}

🚦 Status Codes You Should Know

200 OK — success (default for GET)
201 Created — success after POST
204 No Content — success with no body (often DELETE)
400 Bad Request — client sent invalid data
401 Unauthorized — not logged in
403 Forbidden — logged in but not allowed
404 Not Found — resource doesn't exist
500 Internal Server Error — server bug

🎯 REST Design Rules

Use nouns, not verbs. /users, not /getUsers.
Use plural names. /posts, not /post.
Nest related resources. /posts/42/comments.
Return JSON. Universal, parseable everywhere.
Use proper status codes. 200 for success, 404 for missing, 400 for bad input.
Version your API. /api/v1/posts so breaking changes don't break clients.