Die 5 beliebtesten API-Stile und was sie auszeichnet

Was die Anwendungsfälle betrifft, so ist es erwähnenswert, dass APIs öffentlich, für Partner verfügbar oder vollständig intern sein können. Dieses erste Unterscheidungsmerkmal setzt den Standard für viele der Funktionen, die entwickelt werden müssen: wie Daten gespeichert und gemeinsam genutzt werden, wie Anmeldeinformationen gehandhabt werden, wie viel Datenverkehr die API aufnehmen muss usw.

Wie Sie sehen werden, können die folgenden architektonischen Stile in jedem dieser drei Fälle verwendet werden, aber einige Kombinationen sind sinnvoller als andere.

Dies sind bei weitem die gängigsten APIs heutzutage und auch der Stil, den wir bei der Erstellung von WebScrapingAPI verwendet haben. Das Akronym steht für REpresentational State Transfer, und der Stil schreibt vor, dass die API eine Darstellung des Zustands der angefragten Ressource zurücksendet, wenn Sie als Client eine Anfrage stellen.

RESTful APIs stützen sich stark auf die HTTP-Infrastruktur. Da das Web im Allgemeinen hauptsächlich HTTP verwendet, haben REST-APIs bereits einen Vorteil, da sie einfach zu verstehen, zu integrieren und zu verwenden sind.

Dieser Stil wird auch durch eine Reihe von Beschränkungen definiert, die die API einhalten muss. Auch wenn dies zunächst wie eine lästige Pflicht klingt, sorgen die Einschränkungen dafür, dass sich die API auf vorhersehbare und hilfreiche Weise verhält. Es gibt insgesamt sechs, und sie lauten wie folgt:

• Einheitliche Schnittstelle
• Zustandslos
• Cachefähig
• Client-Server
• Mehrschichtiges System
• Code auf Anfrage

Wir haben einen ganzen Artikel zu diesen Einschränkungen auf Medium veröffentlicht, in dem wir die Details zu REST-APIs näher erläutern.

Wenn eine API einige dieser Beschränkungen einhält, aber nicht alle, kann sie als REST-ähnlich bezeichnet werden. Für einige Anwendungsfälle können die Einschränkungen mehr Probleme als Vorteile mit sich bringen, weshalb es zu einer teilweisen Übernahme des Stils kommen kann.

SOAP, das Simple Object Access Protocol, stützt sich stark auf XML. Um es verwenden zu können, müssen Sie sich an strenge Standards hinsichtlich der Nachrichtenstruktur, der Kodierungsregeln und der Handhabung von Anfragen und Antworten halten.

SOAP-APIs sind zwar sehr genau und umfangreich, aber aufgrund ihrer Auszeichnungssprache ist es schwieriger, sich an sie zu gewöhnen. Anfragen und Antworten können ziemlich lang und komplex werden, was die manuelle Eingabe der Befehle zu einer lästigen Pflicht macht.

Positiv ist, dass dieser Stil den Vorteil einer eingebauten Fehlerbehandlung hat. Wenn Sie auf ein Problem mit der Anfrage stoßen, enthält die Antwort eine Menge wertvoller Informationen, die Ihnen helfen können, den Fehler zu finden und zu beheben.

Dieser Stil wird für die Abfrage von Datenbanken aus clientseitigen Anwendungen über HTTP verwendet. Anstatt jedoch mehrere HTTP-Anfragen an verschiedene Endpunkte zu senden, können Sie eine einzige "Abfrage" für alles, was Sie benötigen, stellen. Im Wesentlichen beschreibt der Client einmal, was er benötigt, und die API tut ihr Bestes, um diese Daten abzurufen.

Ein Server, der mit der GraphLQ-Architektur arbeitet, hat ein vorgefertigtes Modell (oder Schema) für die Daten, die angefordert werden können. Wenn Sie also eine Anfrage stellen, dient das Schema als Leitfaden dafür, was Sie abfragen können, wie die Informationen strukturiert sein sollten und wie Sie mit dem Server interagieren können.

Der Vorteil dieses Systems besteht darin, dass die Nutzer genau wissen, was sie bekommen können, so dass es sehr unwahrscheinlich ist, dass falsche Daten abgerufen werden oder ein Fehler auftritt. Das zugrundeliegende Prinzip besteht darin, den Kunden in den Vordergrund zu stellen und ihm die beste Erfahrung zu bieten.

Ähnlich wie bei GraphLQ erstellen die Falcor-APIs eine virtuelle JSON-Datei, die als Container für die Daten dient, die ein Client nach einer Anfrage erhält. Diese virtuelle Datei kann mit jedem neuen Teil der Daten, die der Client benötigt, erweitert werden. Das ist zwar bequem, aber die Datei kann mit der Zeit ziemlich groß werden.

Glücklicherweise müssen Sie nicht bei jeder Anfrage die gesamte JSON-Datei abrufen. Stattdessen können Sie jederzeit angeben, welche Teile Sie benötigen, und diese in der Antwort abrufen. Dies funktioniert, weil die JSON-Datei unter einer URL veröffentlicht wird und Links zu verschiedenen Ressourcen im Backend enthält. Im Wesentlichen können Sie die virtuelle Datei nach den gewünschten Daten durchsuchen.

Diese virtuelle Schicht zwischen dem Client und dem Server hilft, die beiden miteinander zu verbinden, während beide Architekturen völlig unabhängig bleiben.

Wenn Sie sich um wenige Einschränkungen kümmern müssen, sollte gRPC eine Ihrer ersten Optionen beim Entwurf einer API sein. Es ist sprachunabhängig, plattformunabhängig und aufgrund der Verwendung von Protokollpuffern(protobufs) zur Serialisierung von Daten in binäre Ströme recht schnell. Diese Daten werden dann über HTTP/2 übertragen.

gRPC ist gut für verteilte Systeme geeignet. Der wichtigste Aspekt des Stils sind die Prozeduren. Sie können sowohl auf dem lokalen Rechner als auch auf entfernten Geräten ausgeführt werden. In beiden Fällen ist der Aufruf einer Prozedur schnell und unkompliziert.

Einer der Gründe, warum APIs immer beliebter werden, sind die Vorteile, die separate Microservices gegenüber dem klassischen Softwaremodell mit nur einem Dienst bieten. Auf diese Weise kann jede Funktion/jeder Microservice separat entworfen, entwickelt und aktualisiert werden, ohne andere Komponenten zu beeinträchtigen. In diesem Sinne ist gRPC eine großartige Lösung, um alles miteinander zu verbinden.

Da Sie ein Verfahren aus der Ferne starten können, eignet es sich auch gut für die Anbindung mobiler Geräte an Backend-Dienste.

Dieser Artikel hat Ihnen zwar einen Überblick über die gängigsten API-Architekturstile gegeben, aber das reicht nicht aus, um sicherzustellen, dass Sie den richtigen Stil auswählen. Für uns als Team war es wichtig, mit möglichst vielen Beispielen Erfahrungen aus erster Hand zu sammeln.

Mit Erfahrung meine ich sowohl als Benutzer als auch als Entwickler. Vielleicht gibt es ja einen Stil, mit dem Sie besser vertraut sind, so dass es einfacher wäre, ihn zu entwickeln, aber Sie müssen sich in die Lage des Endbenutzers versetzen und sehen, wie es für ihn funktioniert.

Ein Stil ist nichts, was man einfach mitten in der Entwicklung auswählen oder später ändern kann. Es ist ein Regelwerk, das vorgibt, wie die API Gestalt annimmt. Als solches ist es eine wichtige Entscheidung.

Ein erster Schritt, den Sie tun können, ist, die Dokumentation der bereits auf dem Markt befindlichen APIs zu lesen und sie idealerweise zu testen. Frühere Erfahrungen mit der Erstellung von APIs wären ebenfalls von großem Vorteil.

Wenn Sie sehen möchten, wie wir die WebScrapingAPI zu dem gemacht haben, was sie heute ist, sollten Sie sich unsere Dokumentation ansehen. Es waren auch nicht alle aktuellen Funktionen bei der Veröffentlichung vorhanden. Optionen wie das Scraping von REST-API-Endpunkten oder Dateien wurden auf Wunsch unserer Benutzer hinzugefügt. Denken Sie also daran: Der Architekturstil soll Ihnen eine Richtung vorgeben, aber es ist Ihre Aufgabe, die API zu etwas zu formen, das die Leute lieben werden.