Building a REST API
APIs (Application Programming Interfaces) are the backbone of modern web development. They allow different applications to communicate with each other—whether it’s your frontend talking to your backend, or third-party services integrating with your app. Think of a REST API like a restaurant menu. The menu (API documentation) tells you what dishes (resources) are available and how to order them (HTTP methods). You do not need to know how the kitchen works internally—you just place an order (request) and receive your dish (response). The waiter (HTTP) carries messages back and forth using a standardized process (the REST constraints).What is REST?
REST (Representational State Transfer) is an architectural style for designing networked applications. It’s not a protocol or standard, but a set of constraints that, when followed, create scalable and maintainable APIs.Core Principles of REST
| Principle | Description |
|---|---|
| Stateless | Each request contains all the information needed to process it. The server doesn’t store client state between requests. |
| Client-Server | The client and server are separate, allowing them to evolve independently. |
| Uniform Interface | Resources are accessed using standard HTTP methods (GET, POST, PUT, DELETE). |
| Resource-Based | Everything is a resource (users, products, orders) identified by URLs. |
HTTP Methods and Their Meanings
| Method | Purpose | Example |
|---|---|---|
GET | Retrieve data | Get all users, get user by ID |
POST | Create new data | Create a new user |
PUT | Update existing data (replace) | Update a user’s information |
PATCH | Partial update | Update only user’s email |
DELETE | Remove data | Delete a user |
Why REST?
- Universal: Works with any programming language that can make HTTP requests
- Scalable: Statelessness allows easy horizontal scaling
- Cacheable: GET requests can be cached for better performance
- Simple: Uses familiar HTTP concepts developers already know
Setup
Create a new fileserver.js and install express if you haven’t.
GET: Read Data
POST: Create Data
PUT: Update Data
DELETE: Remove Data
Testing with Postman / Insomnia
Since we don’t have a frontend yet, use tools like Postman or Insomnia to test your API.- GET
http://localhost:5000/api/items-> Should return list. - POST
http://localhost:5000/api/itemswith JSON body{"name": "New Item"}-> Should add item. - PUT
http://localhost:5000/api/items/1with JSON body{"name": "Updated Item"}-> Should update item 1. - DELETE
http://localhost:5000/api/items/1-> Should delete item 1.
Summary
- REST APIs use standard HTTP methods for CRUD operations
- GET for retrieving data (should never modify server state)
- POST for creating data (return 201, not 200)
- PUT for full replacement, PATCH for partial update
- DELETE for removing data (return 204 No Content for success)
- Always validate input and handle errors—never trust data from the client
- Use proper HTTP status codes: they are part of the API contract, not decoration
Request Validation with Joi
Never trust client input! Validate all requests:API Response Standards
Maintain consistent response formats:Pagination
Filtering and Sorting
HTTP Status Codes Reference
| Code | Name | When to Use |
|---|---|---|
| 200 | OK | Successful GET, PUT, PATCH |
| 201 | Created | Successful POST (resource created) |
| 204 | No Content | Successful DELETE |
| 400 | Bad Request | Invalid input, validation error |
| 401 | Unauthorized | Missing or invalid authentication |
| 403 | Forbidden | Authenticated but not authorized |
| 404 | Not Found | Resource doesn’t exist |
| 409 | Conflict | Duplicate entry, version conflict |
| 422 | Unprocessable Entity | Valid JSON but semantic errors |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Server-side error |