Building a RESTful API with Express, implementing CRUD operations and learning REST conventions
What is REST?
REST (Representational State Transfer) is an architectural style for building web APIs. Key principles:
Resources: Everything is a resource (users, products, orders) identified by URLs
HTTP Methods: Use standard HTTP verbs for operations
Stateless: Each request contains all information needed; server doesn't store session state
JSON: Responses are typically JSON (though not required)
Why "RESTful" Instead of "REST"?
You'll often hear APIs described as "RESTful" rather than "REST APIs." This distinction matters. REST was defined by Roy Fielding in his 2000 doctoral dissertation with six architectural constraints:
Client-Server: Separation of concerns between UI and data storage
Stateless: No client context stored on server between requests
Cacheable: Responses must define themselves as cacheable or not
Uniform Interface: Standardized way to interact with resources
Layered System: Client can't tell if connected directly to server
Code on Demand (optional): Server can extend client functionality
The "Uniform Interface" constraint includes a requirement called HATEOAS (Hypermedia as the Engine of Application State): responses should include links to related actions and resources, so clients discover the API by following links rather than hardcoding URLs.
Common Deviations from Strict REST
Constraint
Strict REST
Common Practice
HATEOAS
Responses include links to actions
Clients hardcode API endpoints
Statelessness
No server-side sessions
Often use JWTs or session cookies
PUT vs PATCH
PUT replaces entire resource
PUT often does partial updates
Resource URLs
Nouns only (/users/1)
Sometimes verbs (/users/1/activate)
HTTP Methods and CRUD
Operation
HTTP Method
URL Pattern
Description
Create
POST
/api/items
Create a new item
Read (all)
GET
/api/items
Get all items
Read (one)
GET
/api/items/:id
Get one item by ID
Update
PUT
/api/items/:id
Update an item
Delete
DELETE
/api/items/:id
Delete an item
Status Codes
REST APIs use HTTP status codes to indicate success or failure:
Code
Meaning
When to Use
200
OK
Successful GET, PUT, DELETE
201
Created
Successful POST (new resource created)
400
Bad Request
Invalid input data
404
Not Found
Resource doesn't exist
500
Server Error
Something went wrong on the server
Building a REST API
Let's build a simple "items" API with in-memory storage: