it-swarm-eu.dev

Wie funktionieren Web-APIs?

Ich habe von vielen Web-APIs wie Facebook, Twitter usw. gehört, mit denen Dritte auf Daten zugreifen und diese bearbeiten können. Ich würde gerne wissen, wie eine Web-API funktioniert. Was sind die Grundlagen einer Web-API?

Womit muss ich beginnen, wenn ich eine API für meine Site erstellen möchte, damit Benutzer darauf zugreifen oder sie aktualisieren können?

17
Harish Kurup

Im einfachsten Fall erstellen Sie eine Reihe von GET/POST-Anforderungen, die jeder aufrufen und die Informationen zu den URLs, Parametern und Effekten veröffentlichen kann. GET-Anforderungen für schreibgeschützte Aufgaben und POST-Anforderungen für alles, was Daten auf dem Server ändert.

Fügen Sie bei Bedarf ein Authentifizierungssystem hinzu, und Sie haben selbst eine einfache Web-API.

Eine Web API ist nur eine Schnittstelle to Ermöglichen Sie den Zugriff auf Ihr System (z. B. Site) über Standard HTTP-Anforderungsmethoden . Die Daten selbst werden normalerweise in ein Standardformat eingeschlossen (z. B. [~ # ~] json [~ # ~] oder [~ # ~] xml [~ # ~] ), um die Handhabung zu vereinfachen.


Hier ist eine Beispiel Web-API für 'TextWise'

23
Dan McGrath

Ich entwickle gerade eine API für die Virtualisierungsplattform meines Unternehmens. Sie können sie auf verschiedene Arten ausführen, aber mein Favorit (und der schnellste Weg, um etwas zum Laufen zu bringen, das die Leute verstehen können) ist die Verwendung einfacher HTTP-GET-Anforderungen und die Rückgabe einer JSON-Antwort.

Meine URLs sehen ungefähr so ​​aus:

domain.com/method/call/subcall?key=key&data=something

Ich zerlege dann die HTTP-GET-Variablen und mache, was der Aufrufer damit machen möchte. Einer der Hauptgründe, warum ich mich als Beta-Benutzer für die Stack Exchange API-Entwicklung angemeldet habe, war, dass ich wusste, dass dies eine enorme Lernerfahrung sein würde, und in der Tat .

Normalerweise gebe ich zwei JSON-codierte Arrays zurück, von denen eines result ist. Dies sagt im Grunde nur, ob der Aufruf erfolgreich war, und gibt einen Fehlercode/eine Fehlerzeichenfolge an, wenn nicht. Der andere heißt normalerweise nur data, und der Inhalt davon wird in der Dokumentation dieses bestimmten Aufrufs beschrieben. Darüber hinaus sind GET-basierte APIs viel einfacher zu testen und zu debuggen.

Es gibt viele andere Formate, wie z. B. SOAP/XMLRPC). Ich finde nur, dass die Auswahl von JSON mir unglaubliche Einfachheit und Wahlfreiheit bietet.

Wenn ich zum Beispiel eine Menge Felder senden muss und nicht mit einer Menge GET-Variablen umgehen möchte, kann ich dies einfach tun ( Beispiel in PHP)

$to_send = base64_encode(json_encode($some_array));

Das lässt sich auf der anderen Seite leicht dekodieren, sodass ich Dutzende von Variablen bearbeiten kann, während immer noch nur 2 - 3 GET-Variablen über die API akzeptiert werden.

Ich versuche nur, meine Methoden und Aufrufe kurz und prägnant zu halten und sie so zu gestalten, dass jeder Aufruf eine einheitliche Antwort "funktioniert oder fehlgeschlagen" zurückgibt, gefolgt von den angeforderten Daten.

5
Tim Post

Das ist eigentlich eine sehr breite Frage. Im einfachsten Sinne funktioniert eine Web-API, wenn ein Client (wie ein Webbrowser) eine HTTP-Anfrage an einen Webserver sendet. Der Server überprüft diese Anforderung, um herauszufinden, was der Benutzer möchte, und gibt dann Daten in einem Format (wie einer Seite) zurück, das der Client dann untersucht, um das zu erhalten, was er möchte. Dies sind fast die einzigen Dinge, die Web-APIs gemeinsam haben. Mir ist klar, dass dies Ihre Frage nicht wirklich beantwortet, aber ich wollte einen Grund nennen, warum die Frage so weit gefasst ist.

Es gibt viele Möglichkeiten, wie ein Client seine Anforderung oder einen Server seine Antwort formatieren kann. Damit dies sinnvoll ist, müssen sich Client und Server auf einige Grundregeln einigen. Generell gibt es heutzutage zwei sehr allgemeine Stile, die für solche Dinge verwendet werden.

Remote Procedure Call (RPC)

In einer API im RPC-Stil gibt es normalerweise nur eine URL für die gesamte API. Sie rufen es auf, indem Sie ein Dokument POSTEN, das Informationen darüber enthält, was Sie tun möchten, und der Server gibt das Dokument zurück, das das enthält, was Sie möchten. Im Allgemeinen hat das Anforderungsdokument normalerweise einen Funktionsnamen und einige Argumente.

Einige Standards für diesen API-Stil umfassen XML-RPC und SOAP. Diese Standards versuchen, ein Format zu erstellen, mit dem Sie die von Ihnen ausgeführten Funktionsaufrufe oder sogar die gesamte API beschreiben können.

REpresentational State Transfer (REST)

In einer API im Stil von REST) haben Sie weniger eine URL für die API als vielmehr einen Namensraum : Ein Server oder ein Ordner innerhalb eines Servers, in dem sich viele verschiedene Objekte befinden und jede URL in diesem Namespace Teil der API wird. Anstatt dem Server mitzuteilen, dass Sie die API verwenden möchten, teilt die URL dem Server mit, was Sie möchten die API für verwenden. Anschließend verwenden Sie die HTTP-Methode und möglicherweise den Anforderungshauptteil, um zu erklären, was Sie tun möchten zu diesem Objekt: GET (etwas abrufen, das bereits vorhanden ist), POST (etwas Neues erstellen), PUT (etwas ersetzen, das bereits vorhanden ist) ) oder DELETE (entfernen Sie etwas, das bereits vorhanden ist). Es gibt einige andere Verben, die Sie verwenden können, aber diese sind bei weitem die häufigsten.

Bisher habe ich keine Standardformate für REST erwähnt. Theoretisch können Sie nahezu jedes Format verwenden. HTTP bietet bereits die Möglichkeit zu sagen, was Sie tun möchten und was Sie tun möchten, sodass das Format des Anforderungshauptteils so gut wie alles sein kann: eine Darstellung des Objekts, das Sie erstellen oder ersetzen möchten. In der Praxis sind sich die Autoren jedoch REST) sowieso eher über ein Format einig, da es schwierig wäre, jedes mögliche Format zu verstehen.

2
The Spooniest