Inhalt

Was ist API? Prägnante Erklärung in einfachen Worten

Dieser Artikel ist für jeden nützlich, der schnell verstehen möchte, was eine API (Application Programming Interface) ist, wie sie aufgebaut ist und funktioniert, wo und wofür sie verwendet wird.

Das Thema API ist sehr interessant und umfangreich, daher habe ich das Material in drei Teile aufgeteilt, die sich jeweils an eine andere Zielgruppe richten. Wenn Sie gerade erst anfangen, das Thema zu verstehen, lesen Sie alles der Reihe nach. Und wenn Sie bereits etwas wissen, wählen Sie den Teil, der Sie interessiert.

Teil 1 - Eine einfache Erläuterung der API (dieser Artikel)

  1. Was ist API
  2. Wie API funktioniert
  3. Protokolle der API

Teil 2 - Wie Sie Ihre API schreiben (Arbeit an einem Artikel)

  1. Die besten Frameworks für API
  2. Wie Sie Ihre eigene API erstellen - FastAPI
  3. Wie Sie Dokumentation für API schreiben

Teil 3 - Wie Sie mit API Geld verdienen (arbeitet an dem Artikel)

  1. Wie Sie mit API Geld verdienen können
  2. Nützliche API-Links
  3. API-Kurse

Also, los geht’s…

What is API

API steht für Application Programming Interface. In dem folgenden Artikel verwende ich einfach “API”.

Was ist API
Kurz gesagt, eine API ist eine Reihe von bedingten Konventionen, die es verschiedenen Anwendungen ermöglichen, miteinander zu kommunizieren und zu interagieren.

Fachleute definieren API als einen Service- Vertrag zwischen zwei Anwendungen. Das heißt, wie jeder normale Vertrag, der festlegt, wie Anwendungen (Programme, Dienste) miteinander interagieren sollen, wie sie ihre Anfragen formulieren sollen und was sie als Antworten erwarten. Übrigens, gute Entwickler beschreiben all dies immer in der API-Dokumentation.

Neben der normalen Dokumentation sind hier weitere wichtige Merkmale einer guten API aufgeführt:

  • Einfach zu verstehen, wie sie funktioniert
  • Einfach zu benutzen, auch ohne Dokumentation
  • Schwer, sie falsch zu verwenden (narrensicher)
  • Einfach zu lesender und zu pflegender Code, der die API verwendet
  • Leistungsstark genug, um die Anforderungen zu erfüllen
  • Einfach zu skalieren und Funktionalität hinzuzufügen
  • Entspricht den Erwartungen der Benutzer

Wie funktionieren APIs?

APIs werden in der Regel als eine Client-Server-Interaktion erklärt. Die Anwendung, die die Anfrage sendet, wird als Client bezeichnet und die Anwendung, die die Antwort sendet, als Server. Die API ermöglicht die Kommunikation zwischen Diensten über Anfrage-Antwort-Schleifen. Diese Schleifen können eine Internetverbindung erfordern, müssen es aber nicht.

Anwendungen tauschen diese Anfragen, Antworten und Daten aus, indem sie spezielle Regeln befolgen, die die Verwendung und Anwendung solcher Aufrufe regeln, die akzeptierten Befehle und Datentypen definieren und bestimmte Standards für die Verwendung der API festlegen. Ein Satz solcher Regeln wird als Protokoll bezeichnet.

API-Protokolle

In den frühen 2000er Jahren gab es eigentlich nur zwei API-Protokolle, die den meisten Entwicklern bekannt sein dürften: SOAP und REST. In den letzten Jahren sind jedoch viele neue Protokolle aufgetaucht, wie neue Implementierungen von RPC, GraphQL, Thrift und andere. Nachfolgend erfahren Sie etwas mehr über einige von ihnen.

SOAP

Das SOAP (Simple Object Access Protocol) verwendet XML-Dateien zur Übertragung von Daten zwischen Webdiensten. XML-Dateien werden über HTTP/HTTPS übertragen. SOAP bietet auch eine gewisse Flexibilität, da Daten über andere Protokolle wie Transmission Control Protocol (TCP), Simple Mail Transport Protocol (SMTP), User Data Protocol (UDP) usw. übertragen werden können.

Obwohl SOAP immer noch am weitesten verbreitet und stabil ist, hat seine Popularität in letzter Zeit gegenüber den neueren Protokollen abgenommen.

RPC

RPC (Remote Procedure Call) ist eine ganze Gruppe von Möglichkeiten zu beschreiben, wie verschiedene Computer miteinander kommunizieren können. Ein solches System gibt es bereits seit den 1970er Jahren. Kurz gesagt, der Client führt eine Funktion (oder Prozedur) auf dem Server aus und der Server sendet das Ergebnis an den Client zurück. Technisch gesehen ist das SOAP-Protokoll ein Beispiel für RPC.

Die folgenden Implementierungen des RPC-Protokolls sind derzeit in Gebrauch:

  • JSON-RPC, das Mitte der 2000er Jahre entwickelt wurde, macht ausgiebig Gebrauch vom JSON-Format, unterstützt aber nur einen kleinen Satz von Befehlen und bietet nicht die Flexibilität, die andere Protokolle haben. Wenn Sie jedoch einen einfachen API-Anwendungsfall haben, könnte dieses Protokoll eine gute Lösung sein.
  • XML-RPC unterscheidet sich von JSON-RPC nur dadurch, dass die Daten als XML Dateien übertragen werden. Das integrierte XML-Vokabular wird zur Erstellung von Abfragen und Antworten verwendet. Der Client definiert die Prozedur und die Parameter in der Anfrage, und der Server sendet eine Antwort, die Daten oder eine Fehlerbeschreibung enthalten kann.
  • Das gRPC Protokoll ist noch neuer, es wurde 2015 von Google veröffentlicht und verwendet ebenfalls HTTP als Transportschicht. Es verwendet das Format ProtoBuff zur Übertragung von Daten. Im Gegensatz zu anderen Protokollen erlaubt gRPC den Entwicklern, die gewünschten Funktionsaufrufe zu definieren, anstatt aus vordefinierten Optionen zu wählen (wie GET und PUT im Fall von REST).

REST

REST (Representational State Transfer) ist heutzutage eine der beliebtesten Methoden. Es sollte jedoch gleich klargestellt werden, dass REST kein Protokoll ist, d.h. es gibt keine klaren und allgemein akzeptierten Regeln. REST ist lediglich ein Ansatz oder, mit anderen Worten, eine Reihe von Empfehlungen an den Entwickler, wie er die Interaktion seiner Anwendungskomponenten im Netzwerk am besten organisieren kann. Deshalb werden Sie je nach Situation alle möglichen unterschiedlichen Möglichkeiten finden, diese Empfehlungen zu implementieren, welche Methoden zu verwenden sind, welcher Code zurückgegeben werden soll, usw.

Die wichtigsten Merkmale der REST-API sind, dass jede Client-Anfrage (REST-Anfrage) an den Server bereits alle Informationen darüber enthält, was der Client in der Antwort (dem gewünschten repräsentativen Zustand) vom Server wünscht, und dass der Server die Client-Daten (Client-Sitzungsinformationen) zwischen verschiedenen Anfragen nicht speichern muss.

Client-Anfragen an den Server sind vergleichbar mit den URLs, die Sie in einen Browser eingeben, um eine Website zu öffnen. Die Antwort des Servers sind einfache Daten ohne grafische Darstellung der Webseite.

Vielleicht ist Ihnen auch schon der Begriff RESTful begegnet. Er beschreibt in der Regel Webservices, die unter Berücksichtigung der REST-Empfehlungen erstellt wurden. Es gibt insgesamt sechs obligatorische Anforderungen (Einschränkungen) für die Erstellung verteilter REST-Anwendungen:

  1. Client-Server-Modell. Die Anwendung muss die Client-Server-Architektur verwenden. Die Trennung der Bedürfnisse des Clients von den Bedürfnissen des Servers mit den Daten erhöht die Portabilität des Codes und die Skalierbarkeit der gesamten Anwendung.
  2. Kein Status. Zwischen den Client-Anfragen werden keine Informationen über den Client-Status auf dem Server gespeichert. Alle Anfragen müssen so gestaltet sein, dass der Server alle Informationen erhält, die er zur Ausführung der Anfrage benötigt.
  3. Caching. Clients können Server-Antworten zwischenspeichern. Die Serverantworten wiederum müssen explizit oder implizit als cachefähig oder nicht cachefähig gekennzeichnet sein, um zu verhindern, dass Clients veraltete oder falsche Daten erhalten.
  4. Einheitliche Schnittstellen. Die Vereinheitlichung der Komponentenschnittstellen vereinfacht die Systemarchitektur und verbessert die Transparenz der Komponenteninteraktionen. Dies kann jedoch die Effizienz beeinträchtigen, da die Informationen nur in einer Standardform übertragen werden.
  5. Mehrschichtiges System. Die Verwendung von Zwischenservern (“Schichten” in der hierarchischen Netzwerkstruktur) kann die Skalierbarkeit aufgrund von Lastausgleich und verteiltem Caching verbessern.
  6. Code on Demand REST ermöglicht es Ihnen, die Funktionalität des Clients durch das Herunterladen und Ausführen von Code in Form eines Applets oder Skripts zu erweitern. Dies vereinfacht den Client, da Sie die Anzahl der Funktionen, die im Voraus implementiert werden müssen, reduzieren können.

Zu den Vorteilen von REST gehören Zuverlässigkeit, Leistung (durch den Cache), Skalierbarkeit, Benutzerfreundlichkeit, Unterstützung und Anpassung an neue Anforderungen, sobald diese entstehen.

GRAPHQL

GraphQL (Graph Query Language) wurde bei Facebook entwickelt und 2015 veröffentlicht. Es ist ein Versuch, einige der Einschränkungen und Unzulänglichkeiten von REST zu überwinden.

Der Hauptvorteil von GraphQL besteht darin, dass der Client selbst die gewünschten Daten und das Format in seiner Anfrage bestimmt und GraphQL die Daten im gleichen Format zurückgibt. Das spart Zeit und Speicherplatz, weil die Antwort des Servers nur das Nötigste ist - nur die Daten, die benötigt werden, und nicht vorgefertigte Dateien mit vielen Informationen, die weiterverarbeitet werden müssen.

Auch die Anzahl der HTTP-Anfragen selbst wird reduziert, denn mit GraphQL können Sie mehrere Datenbanken, Microservices und andere APIs mit einem einzigen GraphQL-Endpunkt abfragen.

APACHE THRIFT

[Apache Thrift] (https://thrift.apache.org/) wurde, wie GraphQL, bei Facebook entwickelt. Es wurde mit dem Fokus auf zwei Hauptziele entwickelt: Ermöglichung der Interoperabilität mit Diensten, die in verschiedenen Sprachen geschrieben wurden, und Skalierbarkeit.

Im Wesentlichen handelt es sich um eine Implementierung von RPC, die einen Mechanismus zur Codegenerierung in Kombination mit einem Software-Stack verwendet, um eine API zu erstellen. Der Stack hilft beim Schreiben von Code für die Client- und Serverseite. Die Codesyntax ist flexibel und intuitiv. Ein spezieller Mechanismus generiert Code in jeder beliebigen Programmiersprache, die der Entwickler wählt.

Der Hauptvorteil von Thrift ist die Leichtigkeit, mit der Sie das von einem Dienst verwendete Protokoll ändern können, sobald der Dienst definiert ist. In Verbindung mit der Tatsache, dass Thrift auch viele verschiedene Transportmethoden und mehrere verschiedene Serverprozess-Implementierungen unterstützt, bedeutet dies, dass Thrift gut für Situationen geeignet ist, in denen Sie Ihre Architektur und API-Implementierung häufig ändern oder aktualisieren müssen.

Andererseits kann die Flexibilität, die Thrift bei der Wahl der API-Implementierung bietet, zu weniger Organisation und Konsistenz führen als bei anderen API-Protokollen, die nur eine einzige Möglichkeit bieten.

Wo APIs verwendet werden

APIs sind allgegenwärtig, wenn es darum geht, wie Anwendungen miteinander und mit verschiedenen Online-Diensten interagieren. So allgegenwärtig, dass, wenn Sie alle APIs auf einmal abschalten, fast alle Dienste im Internet und die meisten der Anwendungen, die Sie gewohnt sind, einfach nicht mehr funktionieren.

Mit einer API können Programmierer die Vorteile von Anwendungen Dritter nutzen, ohne dafür eigenen Code schreiben und pflegen zu müssen. Wenn Ihre Anwendung beispielsweise das Wetter anzeigen soll, ist es einfacher, die öffentlich verfügbare Wetter-API zu verwenden, um Ihren Benutzern diese Informationen zur Verfügung zu stellen, als Ihren eigenen Wettercode von Grund auf zu schreiben.

Weitere Beispiele für solche Dienste sind Benutzerregistrierungs-API, Zahlungssystemdienste, soziale Netzwerke und viele andere. Ich werde in Teil 3 mehr darüber sprechen.

Da wir nun wissen, was eine API ist und wie sie funktioniert, lassen Sie uns einen Blick auf die Tools werfen, die Sie verwenden können, um Ihre API schnell und effizient zu schreiben.

Teil 2 - Wie Sie Ihre API schreiben - folgt in Kürze!

Teil 3 - Wie Sie mit APIs Geld verdienen - arbeitet noch an dem Artikel.

😎