REST

When two programs (not people) need to talk over the web — a phone app fetching your bank balance, a website pulling in weather data — they use a web API, and the most common style for designing one is REST. REST is not a protocol or a piece of software; it is a set of design conventions for using plain HTTP to expose your data as addressable resources. The idea is to make a machine-to-machine API feel as simple and uniform as browsing the web.

The core principle is: model everything as a resource with its own URL, and use the standard HTTP methods to act on it. A resource like "user number 7" lives at a URL such as /users/7. To read it you GET /users/7; to replace it you PUT /users/7; to delete it you DELETE /users/7; to create a new user you POST /users. The server responds with a representation of the resource — today almost always JSON — and an HTTP status code (200, 404, 500) saying how it went. Two more conventions matter: it should be stateless (every request carries everything the server needs, so no per-client session is kept on the server), and the URLs should be nouns (things), with the methods supplying the verbs (actions).

REST became dominant because it reuses what the web already does well: existing HTTP methods, status codes, caching, and URLs, with no new machinery to learn. That said, REST is a style, not a strict standard, so real-world "REST APIs" vary widely and many bend the rules. It is also not always the best fit — APIs needing live two-way streaming or very tight, typed contracts often reach for WebSockets, gRPC, or GraphQL instead. REST shines for the common case: straightforward request-reply access to resources over HTTP.