Am kommenden Montag (13. Februar, 1900) findet der Campus zum Thema Amazon Webservices bei Meteotest an der Fabrikstrasse statt.
Bastian Widmer (Liip und Das Recht) gibt uns über einen Überblick über das Cloud-Angebot von Amazon.
Die Veranstaltung ist für alle Interessierte offen und gratis. Anfahrtsinformationen und weiteres wie immer im Campus Wiki.
Freiwillige Anmeldung auf techup.ch.
…ist ein Ausdruck für den absoluten Hass auf SOAP-basierte Webservices.
Auf meinem fortschreitenden Feldzug für eine öffentliche Mobility-API bin ich mittlerweile diese Mail am Verbreiten:
Vorschlag
Schaffung einer offenen Informatikschnittstelle (API) zum Mobility-Reservationssystem
Erläuterung
Der Erfolg des Internet hat dazu geführt, dass nicht nur mehr Benutzer mit Webseiten kommunizieren, sondern auch Webseiten untereinander Daten austauschen. Beispielsweise ruft ein Reiseportal auf Anfrage bei mehreren Fluggesellschaften nach passenden Flügen für den Kunden. Damit dieser Austausch möglich ist, haben sich standardisierte Formate gebildet, zusammengefasst Webservices genannt.
Viele erfolgreiche Firmen im Internet bieten derartige Webservices an: Amazon, Ebay, Facebook, viele Blogs etc. Die Überlegung dahinter: Je einfacher die Kommunikation mit dem Anbieter ist, desto öfter wird er benutzt.
Eine API für Mobility
Vorstellbar ist ein zweistufiger Webservice für Mobility: Auf einer ersten Stufe kann ohne Authentifizierung nach Standorten, Fahrzeugen und deren Zustand (Frei/Reserviert) gesucht werden.
Um Reservationen über den Webservice zu tätigen, muss entweder der Webservice-Anbieter authentifiziert sein, oder der Benutzer einfach auf eine entsprechende Mobility-Webseite weitergeleitet werden, auf dem die Reservationsdetails bereits eingefüllt sind (So ähnlich funktionieren zum Beispiel Zahlung via Postcard übers Internet).
Vorteile
Mit der Standardisierungen dieses Zugangs, ist die Integration von anderen Systemen einfach möglich. Geschäftspartner von Mobility können einfach das Reservationssystem z.B. in ihre eigenen Spesenabrechnung einbinden.
Viel wichtiger aber sind die Individuen, welche zusätzliche Ideen haben, wie man Mobility einsetzen kann: Gratis implementieren sie diese und verhelfen Mobility zu noch grösserer Visibilität im Internet verhelfen. Das ist zum Beispiel mit der inoffiziellen iPhone-Applikation passiert: Der Entwicklungsaufwand wurde von einer Privatperson getragen, Mobility hat das Potential erkannt und die Idee aufgenommen.
Herausforderungen
Dank API-Schlüsselvergabe kann ziemlich gut kontrolliert werden, wer was auf der Schnittstelle tut. Missbrauch kann einfach blockiert werden.
Je einfacher die Schnittstelle gehalten ist, desto mehr Idee werden von Externen implementiert werden.
Nach meiner erfolgreichen Programmierung des Mobility Car Finder habe ich trotzdem eine Mail an Mobility geschickt. Ich wollte wissen, ob Mobility eine offizielle API anbietet oder eine solche plant.
Die Antwort war (Wie ich erwartet hatte) negativ:
Eine öffentliche Schnittstelle (WebService/API) bieten wir aus sicherheitstechnischen Gründen nicht an, und ist auch nicht geplant.
Seufz. Einmal mehr wird ‚Sicherheit‘ als Ausrede vorgeschoben.
Die Sicherheit einer API kann fast beliebig mit Technologien wie SSL (Z.B. Amazon, Anfragezertifikation (Z.B. Amazon) oder Applikationsauthentifizierung (Z.B. Flickr) gewährleistet werden.
Das mag zwar einen Aufwand auf der Seite des Anbieters darstellen, aber es gibt zwei schlagende Argumente warum eine Firma eine API anbieten sollte:
Als Massnahme zur Kundenbindung: Habe ich als Kunde in die Integration eines fremden Systems erst mal etwas investiert, wird mir der Wechsel zur Konkurrenz wesentlich schwerer fallen. Im Fall von Mobility ist dies besonders bezüglich der Business-Kunden besonders interessant. Eine Firme integriert beispielsweise die Autoreservierung (Inklusive automatischer Abrechnung) direkt in ihr Intranet. Ein solches Unterfangen ist für gewöhnlich relativ aufwändig und nur für Grosskunden interessant. Mit einer öffentlich API hingegen könnte diese Anwendung auch kleinere Unternehmen in Kürze implementieren. Und damit stärker an den Dienstleister gebunden werden.
Der zweite Grund sind die gratis Programmierleistungen welche von den API-Benutzern erbracht werden. Ohne einen Finger zu rühren, kriegt der Anbieter von seinen eigenen Kunden Programme und Services geliefert. In diesem Fall hier bietet beispielsweise die Mobile Mobility-Seite zwar Reservationen an, aber keine einfache Möglichkeit einen Standort in der Nähe zu suchen. Ich habe diese Art von Suche bereits implementiert, kann aber keine Reservationen anbieten. Mit einer API hätte ich freiwillig zur Verbesserung des Service beigetragen.
Wer jetzt noch nicht überzeugt ist, für den habe ich ein Beispiel aus der Echten Welt: Hast du dich schon einmal gefragt warum ausgerechnet Facebook so populär geworden ist? Noch vor ein, zwei Jahren war im deutschsprachigen Raum StudiVZ unschlagbar, jetzt kräht kein Hahn mehr danach. Beide Netzwerke beherrschten zu Beginn nur Kontakpflege, Nachrichtenübermittlung und Bildertausch.
Im Mai 2007 stellte Facebook ihre API vor. Aus der einfachen Webseite wurde ein Plattform. Und wurde zur 3. populärsten Webseite überhaupt. Und ist Milliarden wert.
Wenn das kein Argument zur Öffnung der eigenen Systeme ist, was dann?
(Weitere Überlegungen eher technischer Natur finden sich in der exzellenten Präsentation How to Design a Good API and Why it Matters von Joshua Bloch, Google.)
(Und noch ein letzter Link zum API-Verzeichnis von Programmable Web: Amazon und Facebook sind nicht die einzigen Webseiten mit APIs.)