 Ja, hallo und herzlich willkommen. Mein Name ist Patrick Petrovic und ich halte hier heute den Vortrag über Web APIs. Und ja, worum wird es heute gehen? Also wir werden erstmal schauen natürlich, was Web APIs überhaupt sind. Dann werden wir auch dabei grundlegende Konzepte kennenlernen, also zum Beispiel HTTP. Und anschließend werden wir uns dann mit einem ganz tollen Analyse-Werkzeug beschäftigen. Und ja, im letzten Teil werden wir uns dann mal ganz praktisch anschauen, wie man denn eine API so analysiert. Und zwar ein Beispiel Jodl. Ja, also ganz kurz zu mir erstmal. Patrick Petrovic, mein Name, wie gesagt. Ich studiere am Carceral Institute für Technologie Informatik. Und hier links sieht man so ein paar Sachen, mit denen ich mich sonst so beschäftige. Also sprachen wie Ruby, Java, Swift, JavaScript und viele andere Sachen auch. Ja, was sind so Projekte, die ich bis jetzt so gemacht habe? Einerseits ist da die kleine Ruby on Rails Bibliothek. Tele Notify heißt die. Und ja, die macht eigentlich nicht viel, aber sie ermöglicht das Website-Entwicklern mit einer Zeile Codes Nachrichten per Telegram an ihre Benutzer zu schicken. Also gibt's auf GitHub, falls sich jemand dafür interessiert. Ja, mein neuestes Projekt, was auch viel mit diesem Vortrag zu tun hat, ist Jodlestats. Erreichbar unter dieser Adresse hier. Und das ist eine Seite. Und die zeigt euch die neuesten Posts, also die beliebtesten Posts aus ganz Deutschland, die auf Jodl so gepostet werden. Und das ist natürlich ziemlich interessant für diesen Vortrag hier, weil die Seite mit der API von Jodl kommuniziert. Aber bevor wir uns das hier jetzt anschauen können, müssen wir erst mal ganz von vorne anfangen. Und dazu schauen wir uns jetzt erst mal an, was HTTP ist. Kennen vielleicht viele von euch schon wahrscheinlich auch einige genauer, aber trotzdem will ich das jetzt erst mal ganz von vorne anfangen. Also von Aurelie wird HTTP beschrieben als Common Language of the Modern Global Internet. Also ja, die gemeinsame Sprache von unserem Internet, das heißt ohne HTTP wird es kein Internet geben. Und das, was hier drunter steht, ist noch viel wichtiger. Also Anonymous Stateless Request Response Protocol. Und was das bedeutet, schauen wir uns jetzt mal an und zwar von hinten nach vorne. Also was bedeutet denn Request Response? Es bedeutet, dass wir ein Client haben und ein Server und die wollen jetzt miteinander reden. Und das funktioniert über Requests und Responses. Das heißt, der Client will was vom Server wissen, also sendet er ein Request an den Server. Der Server macht irgendwas und antwortet dann dem Client und zwar mit einer Response. Und so funktioniert das ganze Internet. Ja, was bedeutet Stateless? Das bedeutet, dass die einzelnen Requests voneinander unabhängig sein sollen. Das heißt, wenn ich jetzt ein Request sende und dann fünf Sekunden später wieder eins, dann soll das keinen Unterschied machen. Also es soll einfach sich nicht gegenseitig beeinflussen. Und nicht zuletzt Anonymous, das ist eigentlich ganz einfach. Das bedeutet, dass der Server nicht wirklich wissen muss, wer ich eigentlich bin. Also es reicht einfach, wenn er weiß, wo er die Response zurückschicken soll, aber er muss nicht wissen, wie ich heiße und wo ich wohne. Ja, jetzt können wir gleich zum nächsten wichtigen Konzept kommen. Und zwar zu Resources. Also hier haben wir wieder unser Bild mit dem Client und den Server, die miteinander reden. Und der Client will typischerweise irgendwas vom Server haben. Und alles, was es auf dem Server so gibt, nennt man einfach eine Resource. Zum Beispiel kann das jetzt eine HTML-Seite sein oder ein Bild. Oder es kann auch irgendwas sein, was in der Datenbank gespeichert ist. Also zum Beispiel eine Benutzer-Datenbank und der Client will einen einzelnen Benutzer haben. Ja, also Resources hatten wir jetzt. Und genau, also wer ist der Client eigentlich? Das kann natürlich zum Beispiel ein Browser sein. Also jedes Mal, wenn ihr irgendeine Website öffnet, dann ist euer Browser der HTTP Client und sendet Request an den Server. Oder es kann natürlich auch eine App sein. Und die kann auch Request senden. Genau jetzt, wo wir HTTP und Resources kennen, können wir uns mal HTTP ein bisschen genauer anschauen. HTTP kennt unter anderem diese sogenannten Methods. Ja, die heißen Post, Get, Patch, Put oder Delete. Und jede von diesen Methods macht was ganz Bestimmtes. Und man kann sich diese Method vorstellen wie ein Befehl an den Server. Und ja, da gehen wir jetzt einfach mal alle durch kurz. Also Post mache ich immer, wenn ich irgendwas Neues auf dem Server erstellen will. Wenn ich eine neue Resource erstellen will. Und das bedeutet dann, dass man ein Create macht. Also das hier auf der rechten Seite steht immer, was die Methode macht. Get mache ich immer, wenn ich irgendwas vom Server wieder haben will. Also wenn ich ein Read machen will. Ja, Patch Put mache ich, wenn ich eine Resource schon habe, auf dem Server und die updaten will. Und natürlich Delete, falls ich irgendwas löschen will. Das kann man sich jetzt auch noch genauer anschauen, wie denn zum Beispiel jetzt ein Post Request aussieht. Also wir haben hier wie immer den Client und den Server. Der Client will jetzt zum Beispiel ein Bild hochladen auf den Server. Was macht er dann? Nun er macht ein Post Request. Er gibt hier noch den Dateipfad an, also Pictures. Und dann sendet er das Bild einfach hinterher. Das ist jetzt hier nicht drauf, das ist natürlich eine Ellen lange Datei. Der Server rechnet dann rum, bekommt das Bild und am Ende gibt er den sogenannten Status zurück. Und das hat man einfach irgendwann festgelegt, dass der Server okay ist und geklappt hat. Dann gibt der Server jetzt 200 okay zurück. Das ist natürlich nicht immer so. Es kann natürlich auch sein, dass der Client gar keinen Zugriff darauf haben darf. Und in dem Fall kommt dann zum Beispiel 401 unauthorized zurück. Aber der Client weiß in jedem Fall, was eigentlich auf dem Server passiert ist. Ja, eben der Teil sieht ein Post Request dann so aus. Das besteht aus einem Header und aus einem Body. Das ist jetzt nur ein Beispiel. Also wir können im Header, da geben wir erstmal die URL an, wo das hingehen soll, der Request. Und anschließend können wir noch Zusatzinformationen angeben. Zum Beispiel hier, wer wir sind. Also wir sind Google Chrome jetzt zum Beispiel. Und dann können wir noch sagen, ich sende dir Text und der Text hat die Länge 8. Und dem Body, da senden wir dann den Inhalt. Und dann sende ich es dann zum Beispiel John Doe jetzt. Da könnte man sich jetzt vorstellen, dass ein Benutzer mit dem Namen John Doe eben erstellt wird. Ja, ein GetRequest sieht ganz ähnlich aus. Angenommen, wir wollen jetzt ein Bild wieder vom Server haben. Dann senden wir einfach ein GetRequest an den Server. Und der Server, der sucht das Bild, findet es und gibt uns dann 200 okay zurück und das Bild hinterher. Es kann natürlich aber auch wieder hier sein, dass irgendetwas schief geht, wie zum Beispiel, dass es das Bild gar nicht gibt. In dem Fall kommt dann ein Fehler zurück, wie 404 not found. Ja, dann gibt es noch Patch, Put and Delete. Die sind natürlich auch sehr wichtig für HTTP, aber für uns jetzt gerade nicht so arg. Deswegen werde ich da jetzt mal schnell drübergehen und nur sagen, dass es so ähnlich funktioniert wie Post und Get. Ja, jetzt haben wir schon mal die wichtigsten Vorsteine kennengelernt. Und jetzt können wir endlich zu den Web-APIs kommen. Was ist denn eine Web-API? Also naja, Web heißt offensichtlich irgendwas mit Internet. Und API steht für Application Programming Interface. Das heißt, es ist eine Schnittstelle, die mir sagt, wie ich ein Programm oder in dem Fall den Server verwenden kann. Oder man kann es auch als eine Liste von Regeln beschreiben. Und die Regeln sagen mir, wie ich das verwenden kann. Das könnte dann zum Beispiel so aussehen. Man könnte hier so eine Regel definieren, die so aussieht, GetUsersName, und die sagt einfach, ja, wenn ich ein GetRequest auf den PathUsers mache und dahinter noch den Namen schreibe, dann bekomme ich den Benutzer mit diesem Namen zurück. Und hier in Blau sieht man dann, wie man das dann machen würde. Also hier würde man dann den GetRequest einfach dahinsenden und dann den Benutzermax zurückbekommen, in dem Fall. Es gibt natürlich noch viele andere Möglichkeiten. Man könnte sich zum Beispiel vorstellen, dass man auch neue Benutzer erstellen kann mit Posts oder Alter Löschen mit Delete. Oder vielleicht auch GetUsersName, damit man eine Übersicht über die Benutzer erhält. Ja, also das Ganze sieht jetzt in einem Diagramm so aus. Wir haben hier den Server, der ist wahrscheinlich mit irgendeiner Datenbank verbunden. Und ja, die API setzt praktisch auf dem Server drauf. Also die API ist praktisch ein Stück Software, eine Liste von Regeln, die eben auf dem Server drauf läuft. Ja, und genau, der Client, also in dem Fall ist es jetzt eine App, kommuniziert dann mit der API. Und jetzt ist natürlich die Frage, wenn die API nicht öffentlich dokumentiert ist, wie wir es dann hinkriegen, das Ganze zu analysieren. Auf dem Server haben wir ja schon mal keinen direkten Zugriff und ja, Datenbank erst recht nicht. Der Client ist auch eher schwierig anzusehen, also den müssen wir erstmal dekompilieren. Ist auch nicht so einfach. Aber hier haben wir ja was. Wir können nämlich einfach zwischen die API gehen und den Client und eine sogenannte Man in the Middle Erzeug machen. Was bedeutet das? Wir setzen uns einfach zwischen die beiden und hören zu, was die so miteinander reden. Wir tun praktisch so, also wir lassen den Server glauben, dass wir der Client sind und wir lassen gleichzeitig den Client glauben, dass wir der Server sind und leiten einfach alles durch. Und dafür gibt es ein ganz besonderes Tool, das sich MITM Proxy nennt, also MITM for Man in the Middle. Das gibt es für Linux und Mac, sieht so aus, wenn man es startet. Und ja, wenn man es zum ersten Mal sieht, dann ist es erst mal ziemlich unübersichtlich, aber wenn wir jetzt mal die unwichtigen Sachen ausblenden, dann sehen wir, dass es ganz logisch aufgebaut ist. Also wir sehen jetzt hier immer in diesem Turquis Blau die Request Method, die angewendet wurde, zum Beispiel Get oder Post. Und dann sehen wir in der Zeile drunter immer den Status, der zurückgekommen ist vom Server und auch noch die ganze Response. Und damit kann man dann sehr viel machen. Aber um das benutzen zu können, muss man es erst mal installieren. Das funktioniert dann ungefähr so, dass man hoffentlich über Google auf diesen Link kommt. Dann, ja, genau, im zweiten Schritt muss man dann erst mal das Ding auf dem Rechner installieren und dann die IP-Adresse vom Rechner rausfinden. Das macht man auf Mac mit dem Command und auf Linux mit dem bisschen kürzeren IAF-Config-Command. Und ja, nachdem man das gemacht hat, kann man dann MIT Mproxy starten und anschließend muss man nur noch sein Smartphone damit verbinden, wenn man jetzt die API von der Smartphone-App eben analysieren will. Wie Schritt 4 und 5 genau funktionieren, kann ich jetzt hier zum Beispiel mal auf dem iPhone zeigen. Also, man geht einfach bei seinem Wi-Fi-Netzwerk hier auf das kleine I. Und dann gibt man die IP, die man gerade eben vorhin gefunden hat, in Schritt 2 da ein und gibt noch den Port 8080 ein, weil das der Standardport ist von MIT Mproxy. Und dann verbindet sich das mit dem Proxy. Anschließend muss man noch kurz ein Zertifikat installieren, weil die meisten APIs über eine verschlüsselte HTTPS-Verbindung laufen und man da sonst nicht einfach rein hören könnte. Es geht aber auch schnell, hier mit zwei Klicks ist es getan. Ja, also jetzt zur Erinnerung, das hier haben wir gerade geschafft, wir sind jetzt hier zwischen der API und dem Client und jetzt können wir uns mal das Beispiel anschauen mit der Jodl-App und angenommen, wir haben das jetzt so alles gemacht, dann können wir doch einfach mal die Jodl-App starten und schauen, was da so rauskommt. Und ja, so sieht man jetzt auf den ersten Blick nicht viel. Hier irgendwas iCloud, Key Value Service, Analytics, Crashlytics. Ja, also ganz viele verschiedene Requests, da kommen auch die ganze Zeit Neuer, wenn man das live macht, je nachdem wie viel Pech man gerade hat. Und wenn man aber ein bisschen länger drüber schaut, dann fällt einem vielleicht irgendwann auf, dass, nachdem man erst mal nicht weiß, was los ist, dass hier eine URL die ganze Zeit auftaucht und zwar hier api.go-tellum.com. Und ja, da könnte man sich schon denken, vielleicht hat es ja was mit Jodl zu tun oder wenn man sich hier die URL genauer anschaut, sieht man auch, da steht irgendwas von Location. Ja, da werden Koordinaten mitgesendet. Das könnte ja tatsächlich was sein. Schauen wir uns das doch mal genauer an. Hier sehen wir jetzt den HTTP-Request, der ausgeführt wurde. Da sieht man jetzt erst mal nicht viel mehr, aber eine Zeile ist jetzt ziemlich interessant und zwar die unterste User Agent Jodl 3.1.2. Und daran sehen wir jetzt, dass der Request tatsächlich von der Jodl-App ausgeführt wurde. Dann schauen wir uns doch mal an, was der Server so geantwortet hat. Da kommt erst mal wieder eine ellenlange Datei als Antwort. Wenn man da ein bisschen rumscrollt, dann findet man irgendwann sowas. Und da sieht man jetzt sehr viele interessante Sachen drin. Also hier ist einmal ein Attribut, was created at heißt. Und nach einer Weile überlegen, kommt man dann darauf, dass es zu einem Jodl-Post gehört. Und zwar, dass es die Zeit, an dem der Jodl-Post veröffentlicht wurde. Okay, hier haben wir irgendwie discovered by. Da wissen wir jetzt nicht genau, was es bedeutet. Da steht auch nur eine Null dahinter. Aber hier, hier haben wir ein Attribut name und da steht Karlsruhe. Das heißt, das ist die Stadt, in der wir gerade sind. Und natürlich hier ganz unten wieder ist interessanteste, da ist dann das Attributmessage. Und da steht dann tatsächlich der Text von dem Jodl-Post drin. Ja, das heißt, wir haben uns jetzt tatsächlich, wir haben es jetzt tatsächlich geschafft, zwischen die API und den Client zu gehen um mal so ein Request und so eine Response zu analysieren. Und ja, wenn man, wenn man es noch ein bisschen länger anschaut, sieht man dann, dass die Datenstruktur von der Response immer so aussieht. Also das hier ist ein JSON-Objekt. Und da gibt es jetzt verschiedene Attribute. Zum Beispiel gibt es das Attribut recent. Und der Name lässt schon darauf schließen, dass da immer die neuesten Jodl-Posts drin sind. Und das jetzt aber noch interessanter ist, ist das Attribut voted. Da sind nämlich jetzt die beliebtesten Jodl-Posts drin. Und das ist alles hier leider ein bisschen verschachtelt. Das verwirrt einen am Anfang ein bisschen. Ja, das voted Attribut ist nämlich jetzt selbst ein Objekt. Da ist dann wieder ein Array drin. Und in diesem Array sind dann tatsächlich die Jodl-Posts. Und ja, die Jodl-Posts selbst sind auch wieder Objekte. Und dann hier dieses Attribut Message. Das heißt, wir wissen jetzt, wie wir auf die Messages zugreifen können. Dann können wir mal versuchen, das nachzubauen. Das hier ist jetzt beispielhaft in Ruby implementiert. Das kann man natürlich in vielen anderen Sprachen auch machen. Ja, in Ruby gibt es nämlich die tolle Bibliothek HTT Party. Die ist wirklich so toll, wie sie sich anhört. Also man kann damit sehr einfach Get-Requests machen und damit können wir jetzt einfach mal so eine Funktion hier schreiben. Get-Posts, die soll eben die Koordinaten übernehmen und dann einfach mal sich mit dem Jodl-Server verbinden und versuchen, die beliebtesten Posts dazu zu bekommen. Genau, und den Code haben wir jetzt geschrieben. Dann können wir mal schauen, ob er wirklich funktioniert. Dazu können wir in Ruby die IRB benutzen. Das ist einfach so eine interaktive Kommando-Zeile, in der man Ruby Code ausführen kann. Also man kann es einfach eintippen und es wird sofort ausgeführt. Ja, genau, dann rufen wir doch mal unsere Funktion, die wir gerade geschrieben haben, auf. Und zwar hier mit den Koordinaten von Berlin. Also das müsst ihr mir glauben. Und das weisen wir dann mal der Variable Posts hierzu. Ja, dann kommt jetzt erstmal als Outputs mega viel Zeug. Das interessiert uns jetzt aber nicht genau. Wir sehen immerhin, dass es kein Fehler war. Also es ist immerhin nicht ganz schlecht gelaufen für uns. Und das Interessante ist jetzt natürlich, was steht denn in Posts drin? Und dazu führen wir jetzt diese Zeile noch aus. Also wir haben ja vorhin die Datenstruktur gesehen. Wir wollen jetzt das Attribut voted. Davon wollen wir jetzt einfach mal willkürlich den ersten Post, also mit dem Index 0. Und davon wollen wir dann das Message Attribut. Und wenn alles gut läuft, dann sollte da jetzt irgendein Yodel kommen. Und tatsächlich funktioniert das. Und dann sehen wir, dass wir jetzt gerade vom Yodel Server einen Post zurückbekommen haben. Ja, also wir haben hier natürlich jetzt nur einen ganz kleinen Teil gesehen von der API. Aber das ist auch sehr wichtig zu sehen. Man muss nicht das ganze System verstehen, um irgendwas damit machen zu können. Und im Allgemeinen kann man auch das ganze System gar nicht verstehen, weil es viel zu groß ist. Und wenn es nicht öffentlich dokumentiert ist, dann ist es ziemlich schwierig, das ganze System zu überblicken. Ja, um so eine Seite wie Yodel Stats zu machen, da gehört natürlich noch ein bisschen mehr dazu. Also die Kommunikation mit der API ist nur ein kleiner Teil davon. Es ist natürlich ein essenzieller Teil davon, aber trotzdem gibt es noch viel, was auch dazu gehört. Also hier nur ein paar Sachen, die ich für die Seite auch benutzt habe. Also basiert auf Ruby on Rails. Benutzt als Datenbank Post Rescue L für die Benutzeroberfläche Boosttrap und noch kleinere Sachen wie zum Beispiel JQuery Lighter für die Bilder, damit die schön angezeigt werden. Oder Rufus Scheduler, damit in regelmäßigen Abständen neue Posts geladen werden. Und so kann man so eine Seite dann zusammenbauen. Also man benutzt viele andere Dinge und kombiniert sie und am Ende kommt irgendwas raus, wenn man Rückkart. Manchmal auch nicht. Ja, jetzt sind wir schon fast am Ende angelangt. Und ja, bevor wir am Ende sind, möchte ich noch Folgendes sagen. Also man muss natürlich mit, insbesondere mit privaten APIs auch aufpassen. Also zum einen verändern sich private APIs, natürlich sehr schnell. Und da die ja nicht dokumentiert sind, weiß man sowieso nicht genau, wie es gedacht ist, dass es benutzt wird. Und es kann eben sein, dass von heute auf morgen auf einmal irgendwas nicht mehr funktioniert. Oder die API gar nicht mehr da ist. Ja, außerdem, wenn man irgendwas mit privaten APIs macht, dann muss man natürlich immer auf die Terms of Service, also Nutzungsbedingungen achten. Und man sollte auf gar keinen Fall versuchen, irgendwas Schlechtes damit zu machen, weil da kriegt man dann sehr schnelle Ärger. Ja, genauso sollte man aufpassen, wenn man irgendwie vorhat, was kommerziell das daraus zu machen, weil ja, da kann man genauso schnelle Ärger kriegen. Aber trotzdem möchte ich euch alle motivieren, dass ihr euch damit beschäftigt, dass ihr damit rumspielt. Ja, und dass ihr kreativ seid und einfach mal schaut, was ihr so machen könnt. Es muss ja nichts Großes sein. Ja, es reicht auch schon, wenn man einfach mal MITM-Proxy startet und so guckt, was das eigene Handy denn so alles sendet. Da ist man dann schon überrascht, was für Daten die ganze Zeit da rein und rausgehen. Ja, zum Ende jetzt hier nochmal einige Links. Also MITM-Proxy gibt es hier auf MITM-Proxy.org. Ja, meine Seite Jodlestats hier erreichbar. Und wenn jemand Lust hat sich den Code davon genauer anzuschauen, es ist auch auf GitHub verfügbar und ja, also auch der ganze API Code. Also da gibt es auch viel zu sehen. Und wer was dazu beitragen will, kann es natürlich auch gerne machen. Nicht zuletzt kann ich euch auch noch empfehlen, wenn ihr euch für HTTP interessiert, dann könnt ihr HTTP The Definitive Guide von O'Reilly lesen. Ja, das war es jetzt erstmal von meiner Seite. Ich bedanke mich ganz herzlich für eure Aufmerksamkeit. Wenn es gleich noch Fragen gibt, dann könnt ihr die natürlich stellen. Dankeschön. Also gibt es da noch Fragen? Ja, bitte. Ja, Jodl hat sich bei mir gemeldet, tatsächlich. Aber die haben nicht gesagt, dass ich es unterlassen soll. Also die haben gesagt, dass es okay ist, dass ich das mache. Aber es ist natürlich nicht bei jeder Firma so. Also man muss da immer schauen. Es gibt auch Firmen, die sofort ein Anwaltschreiben schicken oder sowas. Da hat man natürlich keine Chance, dann muss man halt, dann muss man es halt lassen. Ja, weitere Fragen da hinten? Vielleicht nur eine kurze Frage. Kannst du kurz abreißen, was Jodl ist? Ja, das habe ich gar nicht erwähnt. Das tut mir leid. Also Jodl ist ein lokales soziales Netzwerk. Also es ist eine App für Smartphones. Und da kann man anonym Sachen posten. Das habe ich nur im Umkreis von 10 km gesehen. Deswegen habe ich auch meine Seite Jodl-Stats gemacht, damit man eben auch in andere Städte reinschauen kann, was denn da so gepostet wird. So, beantwortet es die Frage, oder? Gut. So, sonst noch Fragen? Ja, bitte. Über die API oder hast du wirklich nur Sachen abgerufen? Ja, also ich wiederhole nochmal kurz. Das habe ich schon versucht, habe Jodl zu schicken. Das habe ich tatsächlich noch nicht versucht. Wie ich vorhin auch gesagt habe, man muss nicht mal das ganze System kennen, um es benutzen, um es benutzen zu können. Aber das würde, denke ich mal, auch funktionieren. Also nur, ja, also ich konnte mir jetzt irgendwie, ich konnte keinen Sinn darin finden, jetzt das auch mal auszuprobieren. Und ich habe gar nicht daran gedacht, praktisch. Okay. Also ich kann kurz bestätigen, es geht, man kann über die API auch Post verschicken, es gibt zum Beispiel meiner schönen Heimatstadt ein Dienst, der jeden Tag das Mensa-Essen einmal jodelt und solche Spiele da rein. Okay, das ist ja, ja, nicht schlecht. Okay, also gut, ich glaube, es gibt dann keine Fragen mehr. Also dann bedanke ich mich nochmal ganz herzlich. War schön, dass ihr alle hier wart. Und ja, danke schön.