Eine Clientanwendung (z. B. eine mobile App, ein Webbrowser oder ein anderer Server) initiiert eine Anfrage an die API, um eine Aktion auszuführen. Diese Anfrage wird an eine bestimmte URL gesendet und enthält eine HTTP-Methode, Header mit Metadaten und manchmal einen Anfragetext mit Daten.

Der Server empfängt und validiert die Anfrage und bestätigt, dass der Client authentifiziert und autorisiert ist, die angeforderte Aktion auszuführen. Anschließend wird die Anfrage verarbeitet. Dabei können Daten aus einer Datenbank abgerufen, eine neue Ressource erstellt oder eine vorhandene aktualisiert werden.

Nach der Verarbeitung der Anfrage sendet der Server eine Antwort an den Client zurück. Diese Antwort enthält einen HTTP-Statuscode, der das Ergebnis angibt (z. B. 200 OK bei Erfolg, 404 Nicht gefunden, wenn die Ressource nicht vorhanden ist, 401 Nicht autorisiert bei Sicherheitsproblemen), sowie die angeforderten Daten im Antworttext.

Die zwischen Client und Server übertragenen Daten sind eine „Darstellung“ des Zustands der Ressource. JSON (JavaScript Object Notation) ist das gängigste Format für diese Daten, da es schlank, menschenlesbar und für Programmiersprachen einfach zu parsen ist.

Die Leistungsfähigkeit und Skalierbarkeit von REST beruhen auf einer Reihe von architektonischen Einschränkungen, die das Design bestimmen. Ein System, das diese Einschränkungen erfüllt, wird als „RESTful“ bezeichnet.

Eine Ressource ist ein grundlegendes Konzept in REST. Es ist ein Objekt mit einem Typ, zugehörigen Daten, Beziehungen zu anderen Ressourcen und einer Reihe von Methoden, die darauf angewendet werden können. In einer E-Commerce-API wären beispielsweise ein „Produkt“ oder ein „Kunde“ Ressourcen.

Jede Ressource wird klar durch einen URI identifiziert. Eine gut gestaltete API verwendet übersichtliche, beschreibende und konsistente URIs, um ihre Ressourcen zu identifizieren. Beispielsweise kann /users eine Sammlung von Nutzern identifizieren und /users/123 einen bestimmten Nutzer mit der ID 123.

Ein Client interagiert nicht direkt mit der Ressource, sondern mit einer Darstellung dieser Ressource. Das gängigste Darstellungsformat ist JSON, aber auch andere wie XML oder HTML können verwendet werden. So lässt sich der Zustand einer Ressource flexibel darstellen.

Jede Anfrage eines Clients an den Server muss alle Informationen enthalten, die der Server benötigt, um die Anfrage zu verstehen und zu verarbeiten. Der Server speichert zwischen Anfragen weder Clientkontext noch Sitzungsstatus. Diese Einschränkung macht REST APIs hochgradig skalierbar, da jeder Server jede Anfrage verarbeiten kann.

Client und Server sind getrennt, wobei die API als Schnittstelle zwischen ihnen fungiert. Durch diese Trennung der Zuständigkeiten können sich die clientseitige und die serverseitige Anwendung unabhängig voneinander entwickeln.

REST erfordert eine konsistente, einheitliche Schnittstelle zwischen Client und Server. Dies wird durch die Verwendung von Standard-HTTP-Methoden, URIs zur Ressourcenidentifizierung und Hypermedia als Engine des Anwendungsstatus (HATEOAS) erreicht.

Antworten vom Server sollten als cachefähig oder nicht cachefähig definiert werden. Wenn eine Antwort im Cache gespeichert werden kann, kann ein Client oder Vermittler diese Antwort für nachfolgende, identische Anfragen wiederverwenden. Dies kann die Leistung erheblich verbessern und die Serverlast reduzieren.

Ein Client, der mit einer REST API verbunden ist, kann normalerweise nicht erkennen, ob er direkt mit dem Endserver oder mit einem Zwischenserver verbunden ist. Zwischenserver wie API-Gateways oder Load Balancer können in die Architektur eingebunden werden, um Skalierbarkeit, Sicherheit und Leistung zu verbessern.

Ein häufiger Anwendungsfall ist eine mobile Wetter-App, die aktuelle Wetterdaten für einen bestimmten Ort von einer öffentlichen Wetter-API abruft.

Die Clientanwendung sendet eine HTTP-GET-Anfrage an den API-Endpunkt, die den Standort und einen API-Schlüssel zur Authentifizierung enthält.

Der Server verarbeitet die Anfrage, ruft die Wetterdaten für den angegebenen Ort ab und gibt eine JSON-Antwort zurück.

In einer Mikrodienstarchitektur muss ein „Produkt“-Dienst möglicherweise einen aktualisierten Preis von einem „Inventar“-Dienst abrufen, bevor er ihn auf einer E-Commerce-Website anzeigt. 

Der Produktdienst sendet eine interne HTTP-GET-Anfrage an den API-Endpunkt des Inventardienstes für eine bestimmte Produkt-ID.

Der Inventardienst ruft den aktuellen Preis ab und gibt eine einfache JSON-Antwort zurück.