REST before SDK: APIs per Javascript adressieren

Wer sich mit der Idee rumschlägt, seine Webseiten durch Inhalte oder Funktionen anderer Anbieter wie Twitter, YouTube, DropBox, Deezer, Soundcloud usf. zu erweitern, der wird sich mit den APIs der einzelnen Anbieter auseinandersetzen müssen. Weniger als Tutorial, sondern vielmehr als gut gemeinter Ratschlag ist in diesem Kontext nachfolgender Beitrag zu verstehen.

APIs von Internet-Angeboten gibt es wie Sand am Meer. Fast jede Plattform, die was auf sich hält, bietet eine an. Man kann die Inhalte, die über die API zur Verfügung gestellt werden, über sehr viele verschiedene Wege, oder besser, sehr viele verschiedene Programmier- und Scriptsprachen abrufen. Eine davon, mit der viele Webworker häufig zuerst in Kontakt kommen, ist JavaScript.

Gerade aber bei der Kommunikation mit APIs mit Javascript lauert meines Erachtens nach eine Art „Fallstrick“, der allen Maßnahmen zur Optimierung des Internets auf Downloadgröße und Geschwindigkeit zuwider läuft.

REST before SDK

REST oder „Representational State Transfer“ ist eine Programmieridee, die nicht zu Javascript gehört, sondern dem HTTP-Protokoll zugrunde liegt und mit der alle Programmiersprachen konfrontiert werden, mit denen im Internet hantiert werden kann. Sie bedeutet, dass man in einem Moment eine Abfrage startet und im selben Atemzug „eine“ Webseite als Ergebnis erhält. Denn so funktioniert auch das HTTP-Protokol. Bei jedem Klick auf einen Link wird eine Kommunikation mit dem Server gestartet, der genau eine Webseite als Ergebnis zurückliefert. Wer keinen direkten Zugriff auf eine Datenbank im Internet hat, der ist bei der Kommunikation mit APIs auf HTTP und REST angewiesen.

Das Ergebnis so einer Kommunikation ist in der Regel ein JSON-Objekt oder eine XML-Seite. Darin sind dann alle Informationen gebündelt enthalten, die man wiederum weiterverarbeiten „muss“. Denn so, wie sie einem präsentiert werden, sind sie für die eigene Webseite nicht 1:1 zu gebrauchen.

Keine Angst vor Komplexität

In Javascript selbst gibt es Standardfunktionen für die Kommunikation nach dem REST-Schema. Diese wirken nur auf den ersten Blick „vermeintlich“ komplex. Aber gerade weil das so ist, bieten viele Anbieter für ihre API oft ein separates Javascript-SDK an. Das ist nur wieder eine JavaScript-Datei, die man im Kopf einer HTML-Datei lädt, bevor man damit arbeiten kann, so wie jQuery oder andere. Was dabei jedoch außer Acht gelassen wird, ist die Effizienz und Benutzerfreundlichkeit von Webseiten.

Im Fall des Streaming-Anbieters Deezer beispielsweise gibt es ein Javascript SDK, das ist fast 200 KByte groß. Angenommen jemand möchte gerne die Profilseiten seiner Nutzer mit der Möglichkeit bereichern, dass diese dort ihre eigenen musikalischen Deezer-Favoriten zeigen können. Würde man es auf die „vermeintlich“ einfachere Weise mittels SDK tun, dann verlangt man von den Besuchern der Webseite jedes Mal eine zusätzliche JS-Datei mit knapp 200 KB herunterzuladen.

Hausmittel verwenden!!!!!11111eins

Doch das muss nicht sein. Jeder moderne Browser versteht JavaScript, ohne dass man ihm großartig etwas beibringen müsste. Wenn man weiß, in welcher Form eine API seine Ergebnisse liefert (JSON oder XML), dann kann man mit Hausmitteln mit dieser API kommunizieren. Alles was man dazu wissen muss, ist, wie ein HTTP-Request ausschaut und unter welcher Adresse, mit welchen Parametern man an die Informationen der API kommen kann.

1 var xhr = new XMLHttpRequest();
2 xhr.open("GET", "URL mit der kommuniziert wird", false);
3 xhr.setRequestHeader('Content-Type', 'text/xml');
4 xhr.send();
5 xmlDocument = xhr.responseXML;
6 document.write(''+ xmlDocument.childNodes['0'].textContent +'')

Obiges Code-Beispiel zeigt ein paar Zeilen Javascript, die eine Verbindung mit einem Server aufbauen, in der freudigen Erwartung auf eine XML-Seite als Ergebnis. Dieses wird in der Variable, bzw. dem Objekt xhr gespeichert werden. Die Verbindung wird explizit über den Befehl .open() realisiert. Dieser Funktion lassen sich Parameter übergeben, von denen der erste die Art der Kommunikation beschreibt. Im Beispiel oben war es GET, doch es gibt auch POST, PUT und DELETE. In xmlDocument (Zeile 5) wird dann die Antwort gespeichert. In Zeile 6 schließlich wird das Ergebnis der ersten Ebene des XML-Objekts ausgegeben, und dort dasjenige namens textContent. Für ein JSON-Objekt funktioniert es „vergleichbar“.

Welche URL man nutzen muss, ist in der Dokumentation des API-Anbieters angegeben. Wie die einzelnen Felder der XML-Seiten oder JSON-Objekte heißen, steht ebenfalls in den Dokumentationen, könnte man zur Not aber immer am „lebenden“ Objekt erfahren, indem man es als Ergebnis ausgibt und alle Felder notiert.

Ach ja, da war doch was: Authentifizierung

Was ich an dieser Stelle bislang geschlabbert habe, ist die Tatsache, dass man, um mit einer API zu kommunizieren, sich bei der Verbindungsaufnahme „ausweisen“ respektive authentifizieren muss. Das geschieht in der Regel durch einen speziellen API-Key, den man vom Anbieter erhält und auf eine Methode, die dieser akzeptiert.

Nun wird in diesem Kontext oft OAuth als Ausweissystem genutzt. Wie man das mit Javascript gefügig macht, dazu gibt es im Web genügend Beispiele. Doch das ist nicht in jedem Fall notwendig. Twitter beispielsweise erlaubt sowohl bei der REST API als auch bei der SEARCH API eine Per-App-Authorisierung, die man über einen HTTP-Request mit Javascript-Bordmitteln realisieren kann, im direktesten Fall, indem man die Parameter für .send() manipuliert. Das ist bei anderen APIs nicht anders – und drum lautet mein Appell: Setzt euch ein bisschen mit dem Giftschrank von Javascript auseinander und schaut, was ihr ohne die Hilfe externer 200-KByte-Bibliotheken auf die Beine stellen könnt.

Ähnliche Nachrichten