What is a REST API?
REST (Representational State Transfer) is an architectural style for building web services. A REST API exposes resources (data entities like users, products, orders) via URLs and uses HTTP methods to define what operation to perform on them.
REST is not a protocol — it is a set of constraints. An API that follows these constraints is called "RESTful".
HTTP Methods and CRUD Operations
REST maps the four CRUD database operations to HTTP methods:
| HTTP Method | CRUD | Example | Response |
|---|---|---|---|
| GET | Read | GET /users/123 | 200 + user JSON |
| POST | Create | POST /users | 201 + created resource |
| PUT | Replace | PUT /users/123 | 200 + updated resource |
| PATCH | Partial update | PATCH /users/123 | 200 + updated resource |
| DELETE | Delete | DELETE /users/123 | 204 No Content |
REST URL Design
Good REST API URLs follow predictable patterns:
HTTP Status Codes for REST APIs
| Code | Meaning | When to Use |
|---|---|---|
| 200 | OK | Successful GET, PUT, PATCH |
| 201 | Created | Successful POST (return Location header) |
| 204 | No Content | Successful DELETE, or update with no body |
| 400 | Bad Request | Missing required fields, invalid format |
| 401 | Unauthorized | No token, expired token |
| 403 | Forbidden | Authenticated, but not allowed |
| 404 | Not Found | Resource does not exist |
| 409 | Conflict | Duplicate email, version conflict |
| 422 | Unprocessable Entity | Validation errors |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Unhandled server exception |
6 REST Constraints
- Client-Server: UI and data storage are separated — client handles presentation, server handles data.
- Stateless: Each request is self-contained — no server-side session state between requests.
- Cacheable: Responses must indicate whether they can be cached (Cache-Control headers).
- Uniform Interface: Consistent resource naming, standard HTTP methods, HATEOAS (links in responses).
- Layered System: Client does not need to know if it is talking to the actual server, a load balancer, or a cache.
- Code on Demand (optional): Server can send executable code (JavaScript) to client.
REST vs GraphQL vs gRPC
| Feature | REST | GraphQL | gRPC |
|---|---|---|---|
| Transport | HTTP/1.1+ | HTTP/1.1+ | HTTP/2 |
| Data format | JSON/XML | JSON | Protocol Buffers (binary) |
| Over-fetching | Common | None (client specifies fields) | None |
| Caching | Native HTTP caching | Complex | Manual |
| Learning curve | Low | Medium | High |
| Best for | Public APIs, CRUD apps | Complex data graphs, mobile | Internal microservices, high performance |
💡 REST Best Practices
Use plural nouns for resources (/users not /user). Version your API (/v1/users). Return consistent error formats ({error, message, code}). Use HTTPS always. Add pagination to list endpoints. Set appropriate Cache-Control headers on GET responses.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — REST API
A REST API (Representational State Transfer API) is a web service that follows REST architectural constraints. It uses HTTP as the transport protocol, treats everything as a "resource" identified by a URL, and uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations. REST APIs return data (usually JSON) that represents the current state of a resource. Most modern web and mobile apps use REST APIs to communicate between frontend and backend.
SOAP (Simple Object Access Protocol) is a strict protocol that uses XML and has built-in standards for security (WS-Security) and transactions. REST is an architectural style, not a protocol — it is lighter, uses JSON or XML, and relies on HTTP. REST is far more common today for web APIs because it is simpler, faster, and more developer-friendly. SOAP is still used in enterprise/banking systems where strict contracts and built-in reliability matter.
Stateless means each HTTP request must contain all the information needed to process it — the server holds no session state between requests. If you need authentication, you send the token with every request (e.g. Authorization: Bearer <token>). This makes REST APIs easier to scale: any server can handle any request because there is no shared session state to worry about.
PUT replaces the entire resource. If you PUT a user with only a name field, any other fields not included will be removed/nulled. PATCH applies a partial update — only the fields you send are changed, everything else stays the same. Use PUT when you want to replace a resource completely; use PATCH for partial updates (e.g. updating just a user's email without touching other fields).
200 OK (successful GET/PUT/PATCH), 201 Created (successful POST that creates a resource), 204 No Content (successful DELETE, or PUT/PATCH with no response body), 400 Bad Request (invalid input from client), 401 Unauthorized (missing/invalid authentication), 403 Forbidden (authenticated but not authorized), 404 Not Found (resource does not exist), 409 Conflict (e.g. duplicate email), 422 Unprocessable Entity (validation errors), 429 Too Many Requests (rate limited), 500 Internal Server Error (unexpected server error).
REST has fixed endpoints — each URL returns a fixed data structure (e.g. /users/123 always returns all user fields). GraphQL has a single endpoint where the client specifies exactly which fields it wants. REST is simpler to cache (HTTP caching works natively), easier to learn, and better for simple CRUD. GraphQL is better when clients have varying data needs, when you want to avoid over-fetching/under-fetching, or when you have a complex graph of related data.