Alle API-Anfragen für dieselbe Ressource sollten gleich aussehen, unabhängig davon, woher die Anfrage kommt. Die REST-API sollte sicherstellen, dass dieselben Daten, wie z. B. der Name oder die E-Mail-Adresse eines Benutzers, nur zu einem URI (Uniform Resource Identifier) gehören. Die Ressourcen sollten nicht zu groß sein, aber alle Informationen enthalten, die der Kunde benötigen könnte.  

Beim Design von REST-APIs müssen Client- und Serveranwendungen völlig unabhängig voneinander sein. Die einzige Information, die die Clientanwendung kennen sollte, ist der URI der angeforderten Ressource. Sie kann nicht auf andere Weise mit der Serveranwendung interagieren. Ebenso sollte eine Serveranwendung die Clientanwendung nicht verändern und ihr lediglich die angeforderten Daten über HTTP übermitteln. Zum einen bedeutet dies, dass Sie Ihre Clientanwendungen frei verändern können, ohne dass dadurch Änderungen an der Serveranwendung vorgenommen werden. Gleiches gilt auch im umgekehrten Sinne. So lässt sich sicherstellen, dass selbst umfassende Änderungen am Server oder Client keine Kompatibilitätsprobleme verursachen, solange die eigentliche Schnittstelle unangetastet bleibt. Dies führt zu deutlich mehr Flexibilität bei der Entwicklung sämtlicher Komponenten.

REST-APIs sind zustandslos. Das bedeutet, dass jede Anfrage alle Informationen enthalten muss, die für ihre Bearbeitung notwendig sind. Mit anderen Worten: REST-APIs erfordern keine serverseitigen Sitzungen. Serveranwendungen dürfen keine Daten speichern, die mit einer Client-Anfrage zusammenhängen. Dies bedeutet beispielsweise, dass Sie nicht zuerst eine Anfrage stellen können, die Sie authentifiziert, um dann im Anschluss mit einer weiteren Anfrage bestimmte Daten ausgeben zu lassen. Stattdessen stellen Sie eine einzelne Anfrage, um sich zu authentifizieren und die gewünschten Daten zu erhalten. Dies reduziert Sicherheits- und Ausfallrisiken und umgeht zudem serverseitigen Speicherbedarf, der durch eine Sitzungsverwaltung entstehen würde.

Wenn möglich, sollten die Ressourcen auf der Client- oder Serverseite gecacht werden können. Die Serverantworten müssen auch Informationen darüber enthalten, ob das Caching für die gelieferte Ressource erlaubt ist. Ziel ist es, die Leistung auf der Client-Seite zu verbessern und gleichzeitig die Skalierbarkeit auf der Serverseite zu erhöhen. Dadurch wird die Notwendigkeit einer konstanten Kommunikation zwischen Client und Server deutlich reduziert, was besonders in Anbetracht der Zustandslosigkeit einen massiven Effizienz- und Geschwindigkeitsvorteil mit sich bringt. Besonders praktisch: Der Server gibt an, wie lange die abgefragten Daten im Cache gespeichert werden können, um auf diese Weise beispielsweise einen Rhythmus für Aktualisierungen festzulegen und so die optimale Balance zwischen Leistung und Aktualität der Daten zu finden.

Bei REST-APIs durchlaufen die Aufrufe und Antworten verschiedene Schichten. Hier gilt die Faustregel, dass man nicht davon ausgehen sollte, dass die Client- und Serveranwendungen direkt miteinander verbunden sind. Bei der Kommunikation kann es eine Reihe verschiedener Zwischenstufen geben. REST-APIs müssen so konzipiert sein, dass weder der Client noch der Server erkennen kann, ob er mit der Endanwendung oder einer zwischengeschalteten Stelle kommuniziert. Basierend auf der mehrschichtigen Architektur lassen sich unterschiedliche Frameworks erstellen, bei denen einzelne Schichten mit verschiedenen Funktionen zusammenarbeiten. So wird die Arbeit mit REST-APIs besonders flexibel und ermöglicht zudem die Implementierung zusätzlicher Sicherheitsschichten.

REST-APIs senden in der Regel statische Ressourcen. In bestimmten Fällen können die Antworten jedoch auch ausführbaren Code enthalten (z. B. Java-Applets). Hier sollte der Code nur bei Bedarf ausgeführt werden, um Sicherheitsrisiken aufgrund von unerwünschtem Code zu vermeiden. Generell wird diese Funktion aktuell aber eher selten genutzt.