# REST APIs
REST (Representational State Transfer) is an architectural style for networked applications. It is not a protocol, framework, or synonym for “JSON over HTTP”. REST APIs commonly use HTTP resources, methods, representations, and status codes together.
# Resources and representations
A resource is a thing the API exposes, such as an article. A URL identifies a resource, while a representation is one way to transfer it, often JSON:
GET /articles/42 HTTP/1.1
Accept: application/json
{"id":42,"title":"HTTP basics"}
A REST request is stateless: the server should be able to process it without relying on hidden conversational state from a previous request. Authentication, filters, and the requested representation therefore travel in the request through headers, URL parameters, or the body.
# Resource lifecycle
| Operation | Request | Typical response |
|---|---|---|
| List articles | GET /articles | 200 OK with a collection |
| Create an article | POST /articles | 201 Created, often with a Location header |
| Read one article | GET /articles/42 | 200 OK or 404 Not Found |
| Replace one article | PUT /articles/42 | 200 OK or 204 No Content |
| Update part of one | PATCH /articles/42 | 200 OK or 204 No Content |
| Delete one article | DELETE /articles/42 | 204 No Content or 404 Not Found |
Invalid input can produce 400 Bad Request; a conflicting update can produce 409 Conflict. The exact URL and method design depends on the API, so this table is a convention rather than a rigid law.
# REST and RPC
A REST-style API models nouns and standard operations, for example PATCH /articles/42. An RPC-style API models actions, for example POST /publishArticle, where the action is the central concept. Both can be valid; the important skill is understanding the contract documented by the API.