What Is a REST API?

Open a proposal or listen in on a tech meeting and “REST API” comes up again and again, often as if everyone already knew what it was. In reality the idea is simpler than the acronym suggests, and it’s worth understanding: REST is by far the most common way to build APIs for the web, and almost every integration you encounter will speak exactly that. Here’s the explanation without unnecessary technicality.

Resources and verbs

The basic idea in REST is to look at data as resources, and a resource is simply a thing the API manages: a customer, an order, a product. Each resource gets its own URL, the same way every page on a website has its own address.

To work with the resources, a small, fixed set of standard verbs is used – the web’s own: get, create, update, and delete. The combination of an address and a verb says everything that’s needed. Get the customer at this address. Create a new order. Update this product. Delete that record.

The nice part is how predictable the pattern is. Once you understand how one resource works, you’ve essentially understood them all, since they follow the same logic. That’s a big part of why REST feels easy to work with.

A readable example

Say you have a system with customers. To get a specific customer, the app makes a call with the verb “get” against the customer’s address, something like “get customer number 42.” The server responds with data about that specific customer, usually in JSON format, which is readable even for a human:

• name: Anna Svensson
• email: anna@example.se
• city: Gothenburg

If the app instead wants to add a new customer, it uses the verb “create” against the customers address and sends along the new details. If it wants to update a customer, it uses “update” against that specific customer’s address. The same simple pattern all the way through: an address that points to what, a verb that says what should be done, and a response in a format both systems and humans can read.

One property that makes REST predictable is that every call stands on its own. The server doesn’t need to remember what the client asked last time – all the information needed is in the call itself. That means calls can be handled independently of each other, spread across multiple servers, and scaled up without hassle. That same property is part of why REST responses are easy to save and reuse: a given call against a given address produces a predictable response.

Why REST became the standard

REST isn’t the only conceivable form, but it became the dominant one. Three properties explain why.

• Simple. The pattern of resources, addresses, and verbs is small and easy to learn. Developers recognize it immediately, which makes APIs faster and cheaper to both build and connect to.
• Cacheable. REST rests on the web’s own infrastructure, which can save responses to avoid fetching the same thing over and over. That makes solutions faster and cheaper to run, without extra effort.
• Language-independent. A REST API doesn’t care what programming language the client is built in. An app, a website, and another system can all talk to the same API. That makes REST a common denominator that ties different technologies together.

Together, those properties made REST the natural default for the web. When something “just needs to talk to an API,” it’s usually a REST API that’s meant.

The alternatives, briefly

There are other ways to build APIs. GraphQL lets the client ask for exactly the fields it wants in a single call, which is useful when many different clients need different views of the same data. gRPC is made for fast communication between services internally, more than for regular apps.

Both have their place, but neither has displaced REST for typical web APIs. For the vast majority of needs, REST is still both the default and enough.

At Weapp we build REST APIs and the integrations that use them, and help you assess what a system’s API means for your options. Want to understand how your systems can be connected? Check out our services or get in touch.