APIs

Vorlesung am SAE Institute

Dozent: Bjoern Zapadlo

About me

Bjoern Zapadlo Konstanz36 Jahre

Development Manager / Consultant @ HolidayCheck AG

Informatik Studium 1999 - 2002 3 Agenturen in Stuttgart

HolidayCheck International Websites / new Framework Neckermann / Thomas Cook

Dozent an der SAE, Dualen Hochschule Stuttgart, Hochschule Furtwangen

PHP, Java, Scala, Javasccript, CSS, Html,MySQL, MongoDB, Elasticsearch, ...

Contact me

bjoern.zapadlo@gmail.com http://www.zapadlo.de

@BjoeZap

https://www.xing.com/profile/Bjoern_Zapadlo http://de.linkedin.com/pub/bjoern-zapadlo/36/889/1a5

Facebook Google+

HolidayCheck AG

Größtes deutsches Meinungsportal für Reise und Urlaub Vermittlung von Reisen Sitz in der Schweiz, direkt am Bodensee Börsennotiert über Tomorrow Focus AG Existiert seit 1999 Ausgründungen in mehreren europäischen Ländern Über 300 Mitarbeiter

Yes, we hire ;)

http://www.holidaycheck.de/jobs

Jetzt aber Schluss mit der Werbung...

Und ihr?

Name

Erwartungen

Wünsche

Agenda

Definitionen

Was ist eine API?

API... WTF?

Active Pharmaceutical Ingredient: englische Bezeichnung für einen Wirkstoff in einem Medikament

Adaptive Planungsintelligenz: mathematische Methoden für industrielle Planungsaufgaben

African Plants Initiative: ein Projekt zur Förderung botanisch-taxonomischer Arbeit in Afrika

anonima petroli italiana SpA: eine italienische Ölgesellschaft

Arbeiterkommunistische Partei Irans: eine iranische Exilpartei

Api: ein Berg im Westen Nepals

...

Application Programming Interface

englisch für Programmierschnittstelle in der Informatik

Definition

Eine Programmierschnittstelle ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Oft wird dafür die Abkürzung API (engl. application programming interface, dt. „Schnittstelle zur Anwendungsprogrammierung“) verwendet. Im Gegensatz zu einer Binärschnittstelle (ABI) definiert eine API nur die Programmanbindung auf Quelltextebene.

Funktionsorientiert

Funktionsorientierte Programmierschnittstellen kennen nur Funktionen mit oder ohne Rückgabewert als Mittel der Kommunikation. Dabei wird fast immer das Konzept der Handles verwendet. Man ruft eine Funktion auf und bekommt ein Handle zurück. Mit diesem Handle lassen sich weitere Funktionen aufrufen, bis abschließend das Handle wieder geschlossen werden muss. Das BIOS eines Personal Computer ist die älteste Programmierschnittstelle für diesen Rechnertyp.

Dateiorientiert

Dateiorientierte Programmierschnittstellen werden über die normalen Dateisystemaufrufe open, read, write und close angesprochen. Sollen Daten an ein Objekt gesendet werden, werden diese mit write geschrieben, sollen welche empfangen werden, werden sie mit read gelesen. Unter UNIX ist dieses Prinzip bei der Ansteuerung von Gerätetreibern weit verbreitet.

Objektorientiert

Objektorientierte Programmierschnittstellen verwenden Schnittstellenzeiger und sind damit deutlich flexibler als die funktionsorientierten Programmierschnittstellen. Häufig wird eine Typbibliothek mitgegeben.

Protokollorientiert

Protokollorientierte Programmierschnittstellen sind unabhängig vom Betriebssystem und der Computerhardware. Allerdings muss das Protokoll stets neu implementiert werden. Um diesen Aufwand zu minimieren, wird die protokollorientierte Schnittstelle durch eine funktions- oder interfaceorientierte Schnittstelle gekapselt. Man kann hier weiterhin zwischen allgemeinen (z. B. SOAP) und anwendungsspezifischen (z. B. SMTP) Protokollen unterscheiden.

Wozu ne API?

Welche APIs kennt ihr?

"Interne" APIs

Jede Programmiersprache und jedes Framework besitzen eine Dokumentation, in welcher der Zugriff auf Funktionen der Programmiersprache / des Frameworks erklärt werden.

In Objekt-orientierten Programmiersprachen (z.B. Java, PHP) nennt man das API.

"Externe" APIs

Gerade im Bereich des Internets werden die „externe“ API's (Google Maps, Flickr, Facebook, ...) immer wichtiger. Hierbei handelt es sich entweder um Webservices (SOAP / Rest) oder um externe Bibliotheken, die eingebunden werden. Hierbei sind vor allem Bibliotheken für Javascript von Interesse.

Hierbei wird meist ein sog. API-Key benötigt.

API Key

An application programming interface key (API key) is a code passed in by computer programs calling an API (application programming interface) to identify the calling program, its developer, or its user to the Web site. API keys are used to track and control how the API is being used, for example to prevent malicious use or abuse of the API (as defined perhaps by terms of service).

The API key often acts as both a unique identifier and a secret token for authentication, and will generally have a set of access rights on the API associated with it.

API keys can be based on the UUID system (e.g. 550e8400-e29b-41d4-a716-446655440000) to ensure they will be unique to each user.

Daten

Welche Datenaustauschformate kennt ihr?

Text

Einfachstes Format

Quasi schon antik ;)

Strukturierung schwierig => CSV

Kaum overhead

Encoding

XML

Strukturierter Text

Viel overhead

Eigene Tags möglich

Muss bestimmten Regeln entsprechen

Lange Zeite der quasi Standard

XML - Beispiel

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<verzeichnis>
     <titel>Wikipedia Städteverzeichnis</titel>
     <eintrag>
          <stichwort>Genf</stichwort>
          <eintragstext>Genf ist der Sitz von ...</eintragstext>
     </eintrag>
     <eintrag>
          <stichwort>Köln</stichwort>
          <eintragstext>Köln ist eine Stadt, die ...</eintragstext>
     </eintrag>
</verzeichnis>
                        

JSON

Javascript Object Notation

Kurzschreibweise für Javascript Objekte

Sehr einfach

Kaum overhead

Native Unterstützung in vielen Programmiersprachen

JSON - Beispiel

{
    "titel": "Wikipedia Städteverzeichnis",
    "eintrag": [
        {
            "stichwort": "Genf",
            "eintragstext": "Genf ist der Sitz von ..."
        },
        {
            "stichwort": "Köln",
            "eintragstext": "Köln ist eine Stadt, die ..."
        }
    ]
}
                        

Und was ist jetzt das beste?

Kommunikation

Warum braucht man einen Standard?

Webservices

Das World Wide Web Consortium definiert die Bereitstellung eines Webservices als Unterstützung zur Zusammenarbeit zwischen verschiedenen Anwendungsprogrammen, die auf unterschiedlichen Plattformen und/oder Frameworks betrieben werden.

Ein Webservice oder Webdienst ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML-Artefakt definiert, beschrieben und gefunden werden kann. Ein Webservice unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle.

WTF...?

Schnittstelle via Netzwerk ansprechbar

Externe Funktionalität

Kommunikation meist via XML, es gibt aber auch andere Formate

SOA in modernen Systemen

SOAP

SOAP (ursprünglich für Simple Object Access Protocol) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP.

Die Abkürzung SOAP wird offiziell seit Version 1.2 nicht mehr als Akronym gebraucht, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

SOAP

Meist entspricht ein Serviceendpunkt einer URI, die mehrere Services anbietet. Diese werden per WSDL bekannt gegeben.

Die Web Services Description Language (WSDL) ist eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Webservices) zum Austausch von Nachrichten auf Basis von XML.

SOAP Nachricht

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
   <s:Header>
       <m:RequestID xmlns:m="http://www.lecture-db.de/soap">a3f5c109b</m:RequestID>
   </s:Header> 
   <s:Body>
       <m:DbResponse xmlns:m="http://www.lecture-db.de/soap">
           <m:title value="DOM, SAX und SOAP">
               <m:Choice value="1">Arbeitsbericht Informatik</m:Choice>
               <m:Choice value="2">Seminar XML und Datenbanken</m:Choice>
           </m:title>
       </m:DbResponse>
   </s:Body>
</s:Envelope>
                        

REST

Representational State Transfer (mit dem Akronym REST) bezeichnet ein Programmierparadigma für Webanwendungen. Es gibt keine explizite Norm, daher gehen die Vorstellungen, was REST ist, auseinander. I m Grunde bezeichnet REST die Idee, dass eine URL genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion (etwa das Anzeigen einer Trefferliste nach einer Suche) darstellt, wie es der Internetstandard HTTP für statische Inhalte (Permalink) bereits vorsieht, ein Ziel, das für dynamisch erzeugte Seiten mitunter jedoch zusätzlichen Aufwand erfordert.

Prinzipien von REST

Adressierbarkeit

Jeder Dienst, den ein REST-konformer Server zur Verfügung stellt, hat eine eindeutige Adresse, den Uniform Resource Identifier (URI). Diese „Straße und Hausnummer im Netz“ durch einen URI stellt sicher, dass das Angebot eines Webservices auf einfache, standardisierte Art und Weise einer Vielzahl von Anwendungen (Clients) zur Verfügung steht. Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.

Unterschiedliche Repräsentationen

Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen ausliefern (z. B. HTML, JSON oder XML). Damit kann der Standard-Webbrowser über die gleiche URI-Adresse sowohl den Dienst, als auch die Beschreibung oder Dokumentation abrufen. Es wird nicht der interne Datenbankeintrag ausgeliefert, sondern das je nach Anfrage evtl. in eine bestimmte Kodierung oder Sprachversion übertragene Dokument.

Zustandslosigkeit

REST setzt auf ein zustandsloses Client-Server-Protokoll. Dabei enthält jede HTTP-Botschaft alle Informationen, die notwendig sind, um die Nachricht zu verstehen. Deshalb muss weder der Server noch die Anwendung Zustandsinformationen zwischen zwei Nachrichten speichern. Eine derartig strikte Trennung der Zuständigkeiten zwischen Client und Server führt dazu, dass ein REST-konformer Webservice als zustandslos (stateless) bezeichnet werden kann: Jede Anfrage eines Clients an den Server ist in dem Sinne in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt werden.

Zustandslosigkeit in der hier beschriebenen Form wirkt sich begünstigend auf die Skalierbarkeit eines Webservices aus. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden: Da jeder Request in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden, ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen jedoch viele HTTP-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen zu behalten.

Verwendung von Hypermedia

Sowohl für Anwendungsinformationen als auch für Zustandsveränderungen werden Hypermedia benutzt: Repräsentationen in einem REST-System sind typischerweise im HTML- oder XML-Format, welche sowohl Informationen als auch Links zu anderen Ressourcen enthalten. Deshalb ist es oftmals möglich, von einer Ressource zu einer anderen zu navigieren, indem man einfach Verknüpfungen folgt, ohne dass dafür Registrierungsdatenbanken oder ähnliche Infrastrukturen erforderlich sind. Diese Verknüpfung von Ressourcen innerhalb einer REST-Architektur wird auch als Verbindungshaftigkeit bezeichnet.

Operationen

REST-konforme Dienste müssen einige Operationen vorsehen, die auf alle Dienste (Ressourcen genannt) angewendet werden können. HTTP, zum Beispiel, hat eine klar definierte Menge von Operationen, darunter GET, POST, PUT und DELETE.

HTTP schreibt vor, dass GET „sicher“ (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.

HTTP / REST Operationen

GET: fordert die angegebene Ressource vom Server an.

POST: fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keine URI besitzt, adressiert den URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden Operationen abzubilden, die von keiner anderen Methode abgedeckt werden.

PUT: die angegebene Ressource wird angelegt oder dazu geändert. Üblicherweise ohne Seiteneffekte.

DELETE: löscht die angegebene Ressource.

HEAD: fordert Metadaten zu einer Ressource vom Server an.

OPTIONS: prüft, welche Methoden auf einer Ressource zur Verfügung stehen.

PATCH: ein Teil der angegeben Ressource wird geändert, Seiteneffekte erlaubt.

Und was jetzt benutzen?

OAuth

Was ist OAuth?

OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Applikationen erlaubt. Es wurde von Blaine Cook und Chris Messina initiiert.

Ein Endbenutzer (User) kann mit Hilfe dieses Protokolls einer Anwendung (Consumer) den Zugriff auf seine Daten erlauben (Autorisierung), die von einer anderen Anwendung (Service) verwaltet werden, ohne alle Details seiner Zugangsberechtigung zur anderen Anwendung (Authentifizierung) preiszugeben. Der Endbenutzer kann so Dritte damit beauftragen und dazu autorisieren, sich von ihnen den Gebrauchswert von Anwendungen erhöhen zu lassen. Typischerweise wird dabei die Übermittlung von Passwörtern an Dritte vermieden.

Begriffe

Wie funktioniert OAuth?

OAuth 2.0

Einfacher

Mehrere Workflows (Javascript Application)

SSL

Regenerate Token

Die eigene API

Wann / Warum?

Eine gute API

Easy to learn

Easy to use, even without documentation

Hard to misuse

Easy to read and maintain code that uses it

Sufficiently powerful to satisfy requirements

Easy to extend

Appropriate to audience

Und was heisst das?

Versionierung

Stabilität

Standards

Dokumentation

Dokumentation

RAML

Famous APIs

Twitter

Abfragen von Tweets, Suchen nach Tweets, Schreiben von Tweets, ....

Twitter Dev Pages

Twitter Clients

Facebook

Authentifizierung, Zugriff auf Profildaten & Freunde, Posting von Artikeln, ...

Facebook Dev

GoogleMaps

Suche nach Stichworte, Anzeige von Kartenauschnitten, Malen auf den Karten, ...

Google Maps API

OSM (OpenStreetMap)

Suche nach Stichworten, Zugriff auf versch. Karten / Kartenteile, ...

API Wiki

Amazon

Zugriff auf den Artikelstamm von Amazon, Preise, Suchen, ...

Spotify

Zugriff auf Musikkatalog von Spotofy und Playlisten

Instgram

Zugriff auf Fotos, Posten von Fotos, ...

Übersicht APIs

Misc / Q&A

Further Info

Google

Wikipedia

Developer Resources Twitter / FB / ...

Fragen?