Was ist eine REST API?

Das REST-oder RESTful-API-Design (Representational State Transfer) wurde entwickelt, um vorhandene Protokolle zu nutzen. Während REST über fast jedes Protokoll verwendet werden kann, nutzt es normalerweise HTTP, wenn es für Web-APIs verwendet wird. Dies bedeutet, dass Entwickler keine Bibliotheken oder zusätzliche Software installieren müssen, um ein REST-API-Design nutzen zu können. REST API Design wurde von Dr. Roy Fielding in seiner Doktorarbeit 2000 definiert. Es zeichnet sich durch seine unglaubliche Flexibilität aus., Da Daten nicht an Methoden und Ressourcen gebunden sind, kann REST mit der korrekten Implementierung von Hypermedia mehrere Arten von Aufrufen verarbeiten, verschiedene Datenformate zurückgeben und sogar strukturell ändern.

Mit dieser Freiheit und Flexibilität, die dem REST-API-Design innewohnt, können Sie eine API erstellen, die Ihren Anforderungen entspricht und gleichzeitig den Anforderungen sehr unterschiedlicher Kunden entspricht. Im Gegensatz zu SOAP ist REST nicht auf XML beschränkt, sondern kann XML, JSON, YAML oder ein anderes Format zurückgeben, je nachdem, was der Client anfordert., Im Gegensatz zu RPC müssen Benutzer keine Prozedurnamen oder bestimmten Parameter in einer bestimmten Reihenfolge kennen.

Das REST-API-Design weist jedoch Nachteile auf. Sie können die Fähigkeit verlieren, den Status in RUHE aufrechtzuerhalten, z. B. in Sitzungen, und es kann für neuere Entwickler schwieriger sein, ihn zu verwenden. Es ist auch wichtig zu verstehen, was eine REST-API RESTful macht und warum diese Einschränkungen existieren, bevor Sie Ihre API erstellen. Wenn Sie nicht verstehen, warum etwas so gestaltet ist, wie es ist, können Sie Ihre Bemühungen behindern, ohne es zu merken.,

REST-API-Design verstehen

Während die meisten APIs behaupten, RESTful zu sein, verfehlen sie die Anforderungen und Einschränkungen von Dr. Fielding. Es gibt sechs wichtige Einschränkungen für das REST-API-Design, die bei der Entscheidung, ob dies der richtige API-Typ für Ihr Projekt ist, beachtet werden müssen.

Client-Server

Die Client-Server-Einschränkung arbeitet nach dem Konzept, dass Client und Server voneinander getrennt sein und sich einzeln und unabhängig entwickeln sollten., Mit anderen Worten, ich sollte in der Lage sein, Änderungen an meiner mobilen Anwendung vorzunehmen, ohne die Datenstruktur oder das Datenbankdesign auf dem Server zu beeinträchtigen. Gleichzeitig sollte ich in der Lage sein, die Datenbank zu ändern oder Änderungen an meiner Serveranwendung vorzunehmen, ohne den mobilen Client zu beeinträchtigen. Dies schafft eine Trennung von Bedenken, die jede Anwendung unabhängig voneinander wachsen und skalieren lässt und es Ihrem Unternehmen ermöglicht, schnell und effizient zu wachsen.,

Stateless

REST-APIs sind zustandslos, was bedeutet, dass Aufrufe unabhängig voneinander erfolgen können und jeder Aufruf alle Daten enthält, die erforderlich sind, um sich erfolgreich abzuschließen. Eine REST-API sollte sich nicht darauf verlassen, dass Daten auf dem Server oder in Sitzungen gespeichert werden, um zu bestimmen, was mit einem Aufruf zu tun ist, sondern sich ausschließlich auf die Daten verlassen, die in diesem Aufruf selbst bereitgestellt werden. Identifizierende Informationen werden beim Tätigen von Anrufen nicht auf dem Server gespeichert. Stattdessen enthält jeder Aufruf die erforderlichen Daten wie API-Schlüssel, Zugriffstoken, Benutzer-ID usw., Dies trägt auch dazu bei, die Zuverlässigkeit der API zu erhöhen, indem alle für den Aufruf erforderlichen Daten vorhanden sind, anstatt sich auf eine Reihe von Aufrufen mit Serverstatus zu verlassen, um ein Objekt zu erstellen, was zu teilweisen Fehlern führen kann. Um den Speicherbedarf zu reduzieren und Ihre Anwendung so skalierbar wie möglich zu halten, erfordert eine RESTful—API, dass ein beliebiger Status auf dem Client gespeichert wird-nicht auf dem Server.

Cache

Da eine zustandslose API den Anforderungsaufwand erhöhen kann, indem große Lasten eingehender und ausgehender Anrufe verarbeitet werden, sollte eine REST-API entwickelt werden, um die Speicherung zwischenspeichbarer Daten zu fördern., Dies bedeutet, dass, wenn Daten zwischenspeichbar sind, die Antwort angeben sollte, dass die Daten bis zu einer bestimmten Zeit gespeichert werden können (expires-at), oder in Fällen, in denen Daten in Echtzeit sein müssen, dass die Antwort nicht vom Client zwischengespeichert werden sollte. Wenn Sie diese kritische Einschränkung aktivieren, reduzieren Sie nicht nur die Anzahl der Interaktionen mit Ihrer API erheblich und reduzieren die interne Servernutzung, sondern stellen Ihren API-Benutzern auch die Tools zur Verfügung, die für die Bereitstellung der schnellsten und effizientesten Apps erforderlich sind. Beachten Sie, dass das Caching auf der Clientseite erfolgt., Während Sie möglicherweise einige Daten in Ihrer Architektur zwischenspeichern können, um die Gesamtleistung auszuführen, soll der Client angewiesen werden, wie er vorgehen soll und ob der Client die Daten vorübergehend speichern kann oder nicht.

Einheitliche Schnittstelle

Der Schlüssel zum Entkoppeln des Clients vom Server liegt in einer einheitlichen Schnittstelle, die eine unabhängige Entwicklung der Anwendung ermöglicht, ohne dass die Dienste, Modelle oder Aktionen der Anwendung eng mit der API-Schicht selbst verbunden sind., Die einheitliche Schnittstelle ermöglicht es dem Client, unabhängig vom architektonischen Backend beider Sprachen in einer einzigen Sprache mit dem Server zu sprechen. Diese Schnittstelle sollte eine unveränderliche, standardisierte Möglichkeit zur Kommunikation zwischen dem Client und dem Server bieten, z. B. die Verwendung von HTTP mit URI-Ressourcen, CRUD (Erstellen, Lesen, Aktualisieren, Löschen) und JSON.

Schichtensystem

Wie der Name schon sagt, ist ein Schichtensystem ein System, das aus Schichten besteht, wobei jede Schicht eine bestimmte Funktionalität und Verantwortung hat., Wenn wir an ein Modellansichts-Controller-Framework denken, hat jede Ebene ihre eigenen Verantwortlichkeiten, wobei die Modelle umfassen, wie die Daten gebildet werden sollen, der Controller sich auf die eingehenden Aktionen konzentriert und die Ansicht sich auf die Ausgabe konzentriert. Jede Schicht ist getrennt, interagiert aber auch mit der anderen. Im REST-API-Design gilt dasselbe Prinzip, wobei verschiedene Schichten der Architektur zusammenarbeiten, um eine Hierarchie aufzubauen, die eine skalierbarere und modularere Anwendung erstellt.,

Mit einem mehrschichtigen System können Sie auch Legacy-Systeme kapseln und weniger häufig aufgerufene Funktionen auf einen gemeinsam genutzten Vermittler übertragen und gleichzeitig modernere und häufig verwendete Komponenten davon abschirmen. Darüber hinaus gibt Ihnen das Layered-System die Freiheit, Systeme in und aus Ihrer Architektur zu verschieben, wenn sich Technologien und Dienste weiterentwickeln, was die Flexibilität und Langlebigkeit erhöht, solange Sie die verschiedenen Module so locker wie möglich koppeln., Es gibt erhebliche Sicherheitsvorteile eines mehrschichtigen Systems, da Sie damit Angriffe auf der Proxy-Ebene oder auf anderen Ebenen stoppen können, um zu verhindern, dass sie zu Ihrer tatsächlichen Serverarchitektur gelangen. Durch die Verwendung eines mehrschichtigen Systems mit einem Proxy oder das Erstellen eines einzelnen Zugriffspunkts können Sie kritische und anfälligere Aspekte Ihrer Architektur hinter einer Firewall behalten und eine direkte Interaktion des Clients mit ihnen verhindern., Denken Sie daran, dass Sicherheit nicht auf einer einzigen „Stop all“ – Lösung basiert, sondern auf mehreren Ebenen mit dem Verständnis, dass bestimmte Sicherheitsprüfungen fehlschlagen oder umgangen werden können. Je mehr Sicherheit Sie in Ihr System implementieren können, desto wahrscheinlicher ist es, dass Sie schädliche Angriffe verhindern.

Code on Demand

Möglicherweise die am wenigsten bekannte der sechs Einschränkungen und die einzige optionale Einschränkung Code on Demand ermöglicht die Übertragung von Code oder Applets über die API zur Verwendung innerhalb der Anwendung., Im Wesentlichen erstellt es eine intelligente Anwendung, die nicht mehr ausschließlich von ihrer eigenen Codestruktur abhängt. Aber vielleicht, weil es seiner Zeit voraus ist, hat Code on Demand um die Akzeptanz gekämpft, da Web-APIs in mehreren Sprachen verwendet werden und die Übertragung von Code Sicherheitsfragen und Bedenken aufwirft. (Zum Beispiel müsste das Verzeichnis schreibbar sein, und die Firewall müsste den normalerweise eingeschränkten Inhalt durchlassen.)

Zusammen bilden diese Einschränkungen die Theorie der repräsentativen Zustandsübertragung oder RUHE., Wenn Sie durch diese zurückblicken, können Sie sehen, wie jede aufeinanderfolgende Einschränkung auf der vorherigen aufbaut und schließlich eine ziemlich komplexe, aber leistungsstarke und flexible Anwendungsprogrammschnittstelle erstellt. Am wichtigsten ist jedoch, dass diese Einschränkungen ein Design ausmachen, das ähnlich funktioniert wie der Zugriff auf Seiten in unseren Browsern im World Wide Web. Es erstellt eine API, die nicht von ihrer Architektur, sondern von den zurückgegebenen Darstellungen diktiert wird, und eine API, die—obwohl architektonisch zustandslos—auf die Darstellung angewiesen ist, um den Status der Anwendung zu diktieren.,

Weitere Informationen zum REST-API-Design finden Sie im eBook Ungestörte RUHE: Eine Anleitung zum Entwerfen der perfekten API.