REST APIs Explained: The Web's Most Common Interface
What REST Actually Is
REST — Representational State Transfer — is a style of designing networked APIs that Roy Fielding laid out in his 2000 doctoral dissertation. The core idea is elegantly simple: treat the things your application deals with as addressable resources, and use the standard verbs of the web to act on them. A resource is anything you can name — a user, an order, an article — and you give each one a URL. To read a user, you GET /users/42. To create a new one, you POST to /users. To update, PUT or PATCH. To delete, DELETE.
The appeal is that all of this rides on top of HTTP, which every web framework, library, and curl command already understands. There is no additional protocol to invent. You do not need a custom RPC layer or a bespoke serialization format — JSON over HTTP is enough for the vast majority of cases.
Verbs and Status Codes
REST's discipline lives in two small vocabularies. The verbs carry intent: GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes. The status codes carry outcome: 200-range means success, 300-range means a redirect, 400-range means the client sent something wrong, 500-range means the server broke. A well-behaved REST API uses these consistently. A POST that mutates data but returns 200 when it should return 201 is technically functional but conceptually muddled.
REST has limits. It is not the fastest wire format, and it does not handle real-time or bidirectional streams well — that is where WebSockets and gRPC earn their place. But for the bulk of machine-to-machine traffic on the web, REST remains the default because it is boring, debuggable, and understood broadly across every ecosystem.
The Edge Review publishes plain-English explainers. This is an introduction to REST concepts; real designs involve pagination, authentication, versioning, and idempotency choices that depend on your domain.