Eine API für die Aare

Auf Schwumm.ch bin ich gelegentlich etwas am Aare-Apps basteln. Leider sieht man noch nicht so viel. Dafür gibt es ab sofort frische und alte Wasserdaten für Programmierer: Die Aare hat jetzt eine API.

Dokumentation und eine Demoseite gibt’s unter aare.schwumm.ch/api. Bitte nie vergessen bei eigenen Projekten als Datenquelle das Bundesamt für Umwelt zu erwähnen.

Und ich würde mich auch über eine Mail freuen, wenn du was Interessantes damit gebastelt hast.

Der Schweizer Google Maps-Klon: Geo.admin.ch

Ein wenig technischer ging es beim Vortrag an der OpenExpo 2010 über das Geoportal des Bundes vor: David Oesch und Hanspeter Christ stellten die Seite map.geo.admin.ch vor. Sie soll als zentrales Portal für alle Geodaten des Bundes dienen und steht anderen Bundesämtern gratis zur Verfügung. Private Institutionen können auf Anfrage ebenfalls die Karten via API einbinden und benutzen. Der Anstoss gab das Geoinformationsgesetz von 2007.

David Oesch berichtete über die organisatorischen Probleme dieses Mammutprojektes: Wie kann er es innerhalb eines Jahres mit knappen Budget zu Stande bringen, wenn alleine der Serverbeschaffungsprozess für Bundesämter 3 Monate dauert? Wie soll mit diesen Frist eine flexible Infrastruktur entstehen, ohne dass genau absehbar ist, wieviel Nachfrage es geben wird.

Die Lösung war ein Hack: Anstelle der zeitaufwändigen Beschaffung von Servern, hat sich das Team einfach bei Amazon EC2-Server und S3-Speicherplatz gemietet.

Hanspeter Christ konnte auf dieser Infrastruktur mit konsequenter Anwendung von Open Source-Software wie OpenLayers und MapFish innerhalb von kürzester Zeit ein flexibles Kartensystem aufziehen, welches der Konkurrenz in keiner Weise nachsteht. Sein Lieblingsvorteil von Open Source: Es sind keine mühsamen Vertragsverhandlungen notwendig und es entstehen somit keine Anschaffungskosten.

Ich habe mir das Angebot des Bundes etwas angesehen: Das Kartenmaterial besteht aus den legendär guten swisstopo-Karten, gepaart mit denselben Luftaufnahmen, wie man sie bereits von Map Search.ch kennt. Die Kombination dieser zwei Ebenen ist allerdings bei der privaten Konkurrenz besser gelöst. Das Bundesangebot richtet sich demnach auch eher an Benutzer der zahlreichen öffentlichen Geodatensätze.

Trotzdem, ich war sehr positiv überrascht von der Seite. Wer hätte dem Bund schon eine derart agile Entwicklung zugetraut?

Eine API für Mobility – Nachtrag

Währenddem ich weiter über die Genossenschaftsstrukturen versuche, meinen API-Vorschlag für Mobility zu verbreiten, passierte etwas unverhofftes: Ein Mitglied des oberen Managements ist über mein Blog gestolpert* und hat mir daraufhin eine Mail geschickt. Mein Anliegen scheint jetzt zumindest auch von oben in die Firma einzufliessen.

Deren Antwort fordert Geduld: Wenn ich das richtig interpretiere, wird im Moment die internen Informatik überarbeitet. Diese Arbeiten sollten 2011 abgeschlossen sein, und ab diesem Zeitpunkt dürfen neue Funktionen gewünscht werden.

Ich werde abwarten, was geschieht. Und merke mir schon mal vor, nächstes Jahr den nächsten Anlauf zu starten.

* = Oder wurde vom Grossen Bruder vorbeigeschickt.

Eine API für Mobility

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.

No API, no gain.

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.)