RESTful
RESTful describes a widely used blueprint for interfaces through which programs exchange data over the internet. Such an interface speaks the same language as a web browser: you call up an address and receive clearly named information in return.
Programs constantly need to fetch data from other programs. A weather app asks a weather service, an online shop asks the bank whether a payment went through. For this to work, there needs to be an agreed handover point with fixed rules. Such handover points are called interfaces, or APIs in English. An interface is called RESTful when it is built according to a specific, very widespread set of rules. This set of rules dates from the year 2000 and is called Representational State Transfer, or REST for short.
Why almost every app on the net speaks REST
The big advantage is uniformity. Once you have understood one RESTful interface, you quickly find your way around the next one. The addresses are similarly structured, the commands are named the same way, the responses come in a familiar format. A developer therefore does not have to learn an entirely new way of thinking for every single service.
On top of that, REST builds on the technology of the ordinary web. It uses exactly the protocols that your browser also uses to load web pages. As a result, it works through corporate firewalls, can be tested with standard tools, and runs on virtually any server. You don’t need to install any special software to use it.
This is also the normal case for AI services. When a company integrates a language model into its own software, this happens via a RESTful interface provided by the vendor. The company sends the user’s text and gets the model’s answer back. The actual model itself stays in the provider’s data center.
Addresses, verbs, and statelessness
The basic idea is simple: every piece of information gets its own address. A list of users, for example, lives at /users, and the user with the number 42 at /users/42. Such addresses denote things, not actions. You can often tell a well-built REST interface by the fact that its addresses contain nouns.
What is supposed to happen with this address is stated by a short command placed in front of it. GET retrieves data, POST creates something new, PUT changes an existing entry, DELETE removes it. These four commands are sufficient for most cases. What comes back is a response, usually in JSON format, which is still reasonably readable for humans and easy for machines to process. There is also a status number: 200 means success, 404 means the thing doesn’t exist.
An important rule is called statelessness. The server does not remember anything about the requester between two requests. Every request must therefore contain everything needed to process it, including identification in the form of a key. This may seem cumbersome, but it has a practical reason: you can set up as many servers as you like side by side, and it doesn’t matter which one answers a given request. This is exactly how services with millions of users can be run.
From the API key to the per-request price list
REST becomes visible above all in developer documentation. Anyone who registers with an AI provider gets an API key and a list of addresses they are allowed to call. Mapping services, payment providers, and stock market data providers also work this way. Billing then often happens per request or per amount of text processed.
In business news, the term usually appears indirectly. When it is said that a company is opening up its data to partners, or that a service has suddenly become more expensive, this is almost always about such interfaces. Companies like Twitter or Reddit have drastically changed the prices and rules of their APIs, which rendered entire add-on programs unusable. Anyone who builds on someone else’s interface therefore makes themselves dependent.
By the way, a common misconception is that RESTful and API are the same thing. REST is just one of several styles. Competitors are called GraphQL, where the caller specifies exactly which fields it wants, or gRPC, which is faster but harder to see through. REST nevertheless remains the standard, because it is simple and understood everywhere.