RESTful APIs
Web APIs designed around resources addressed by URLs and manipulated with standard HTTP methods.
REST — Representational State Transfer — is an architectural style for networked applications, defined by Roy Fielding in his 2000 doctoral dissertation. A RESTful API exposes resources (nouns such as users, orders, or articles) at URLs, manipulated with the standard HTTP methods: GET retrieves, POST creates, PUT or PATCH updates, DELETE removes. The defining constraints are statelessness (each request carries all the context the server needs), a uniform interface, cacheable responses, and a client–server separation of concerns.
A typical design is simple: GET /api/articles returns a list, GET /api/articles/42 returns one article, POST /api/articles creates one, and so on. Responses are usually JSON, and HTTP status codes carry the meaning — 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 429 Too Many Requests — so clients and intermediaries can reason about outcomes without a private protocol. Because REST builds on HTTP rather than replacing it, caching, authentication, and error handling come from the existing web infrastructure.
REST contrasts with RPC-style interfaces, which expose functions rather than resources, and with GraphQL, which lets clients query for exactly the fields they want. REST's popularity comes from its simplicity and predictability, and its constraints are what make large systems composable and cache-friendly.
Practical concerns in real APIs include versioning (commonly /v1/ in the URL), pagination, idempotency of PUT and DELETE, authentication via API keys, OAuth 2.0, or JWTs, rate limiting, and machine-readable documentation such as OpenAPI. Well-designed RESTful APIs are the default backbone of web and mobile applications — the same discipline of caching, throttling, and bounded responses that this wiki applies to its own search endpoint.
Tags
apis http rest software engineering web development