REST API

Programs often need to supply each other with data. A weather app on a phone doesn’t store the weather data itself. It asks a remote computer on the internet for it and receives it in return. For this to work, both sides need fixed rules: What must the request look like, and in what form does the answer arrive? A REST API is such a set of rules. What’s special about it: it uses exactly the same technology a web browser uses to load pages, namely addresses on the net and simple commands like “fetch” or “save”.

Why almost every app has a REST API behind it

REST has become widespread because it reuses the web’s existing technology. Before REST, there were more complicated procedures in which programs exchanged long messages in a rigid format. REST gets by with what every server and every programming language already supports anyway. A developer can often try out a REST interface in a matter of minutes simply by typing the address into a browser.

For businesses, this is an economic point. Anyone offering a REST API makes their data usable for outside developers without giving away their own program code. Google, Deutsche Bahn, or payment service providers earn money from other companies using their interfaces. Some providers charge per request, others sell packages with a fixed number of calls per month.

REST APIs are also common within a single company. Large pieces of software today are broken down into many small individual programs that talk to each other via such interfaces. The advantage: each component can be developed further or replaced independently, as long as the interface stays the same.

Addresses, commands, and the response in JSON

In REST, every piece of information has its own address, a so-called URL. One example: at the address of an online shop, /customers/4711 might represent the customer with the number 4711. These addresses point to things, not to actions. What should happen to the thing is stated by an additional command.

At its core there are four of these. GET retrieves data, POST creates something new, PUT changes an existing entry, DELETE removes it. With these, you can cover almost everything an application needs to do with data. The response usually comes back in a format called JSON, a text notation that is still readable by humans and easy for programs to process. In addition, the server sends along a number, the status code. 200 means “everything is fine,” the famous 404 means “not found.”

One important principle is called statelessness. The server remembers nothing about the requester between two requests. Every request must contain all the necessary information itself, including proof of who you are. This seems cumbersome, but it has a practical reason: you can line up as many servers as you like side by side, and it doesn’t matter which one handles the next request. This is exactly what makes large services scalable in the first place.

REST in everyday life and in AI products

People use REST APIs constantly without noticing it. The timetable in the train app, the map in a delivery app, the prices in a trading app: behind almost all of these are such calls. Even when a loading spinner briefly appears in an online shop during checkout, the page is at that moment talking to the interface of a payment service provider.

In the AI industry, REST APIs are the usual way to use a language model. Anyone wanting to build ChatGPT or a similar model into their own software sends the text via POST to an address provided by the vendor and gets the response back as JSON. Billing is based on the amount of text. When news reports say a company has “integrated AI,” this is usually exactly what’s behind it.

Two distinctions are useful. An API is the umbrella term for any program interface; REST is just one particular style of it. And there are alternatives: GraphQL lets the requester specify more precisely which fields they need, while gRPC is faster but harder to inspect. A common misconception is also that REST is a fixed, certified protocol. It is merely a collection of recommendations, and many interfaces that call themselves REST only partially adhere to it.