Die Hinweise auf den heutigen Abend (13. Mai 2009) verdichten sich. Hier ein Einblick in die Abteilung Products & Innovation der Telekom in Berlin.

Telekom: Heute tut sich etwas in Berlin Teil II from Richard Joerges on Vimeo.

Noch ist es geheim, aber irgend etwas wird heute Abend am 13. Mai 2009 in Berlin passieren.

Telekom: Heute tut sich etwas in Berlin from Richard Joerges on Vimeo.

Web 2.0, Social Media, Twitter, die Kommunikation verlagert sich immer mehr in das Internet. Wo liegt also die Zukunft der Voice-Dienste, wie sie von der Deutschen Telekom angeboten werden? Die klare Antwort gibt der renommierte Telekommunikations-Berater und fundierte Kenner der Open API-Szene Thomas Howe. Sein Augenmerk richtet er besonders darauf, dass die Voice-Dienste über eine API in Web-Dienste eingebunden werden können.

mite ist eine webbasierte Software zur Erfassung und Auswertung von Arbeitszeit des Berliner Start-ups Yolk.

Über das schlanke Interface können Arbeitszeiten eingetragen oder auch direkt mit einer Stoppuhr aufgezeichnet werden. Die Zeiteinträge lassen sich über die Zuordnung zu Kunden, Projekten und Leistungen organisieren.
Zur Auswertung stehen flexibel filterbare Reports mit grafischen Übersichten zur Verfügung, die auch im Excel- und CSV-Format exportiert werden können. Über einen externen Zugang besteht die Möglichkeit, Projekte für Kunden einsehbar machen. Neben der Eingabe im Web Interface lässt sich mite auch über das iPhone, per Jabber, Twitter oder Ubiquity füttern. Für die Arbeit im Team lassen sich beliebig viele Nutzer einrichten, um Arbeitszeiten an gemeinsamen Projekten zu tracken und auszuwerten. Mite versteht sich als Software-as-a-Service und kostet pro Nutzer und Monat 5 Euro.

Für Entwickler ist die API besonders interessant. Nach dem Freischalten eines API Keys über die Web-Oberfläche bietet die Schnittstelle Zugang zu allen Funktionen von mite. Im einzelnen lassen sich Einträge zu Kunden, Projekten, Leistungen und Benutzern anzeigen, anlegen, ändern und löschen sowie die Stoppuhr starten und anhalten.
Besonders großer Wert wurde auf die REST-Konformität der API gelegt. Alle Daten besitzen eine eindeutige URL und werden mittels der vier HTTP-Befehle GET, POST, PUT und DELETE gelesen bzw. bearbeitet. Die API ist umfassend dokumentiert und ein Blog informiert über Neuigkeiten aus dem mite-Umfeld.

Wir haben mit dem Mitgründer und Entwickler Sebastian Munz über die Architektur der API und die Zukunftspläne von mite gesprochen.

Sebastian Munz

Viele Web Services bieten mittlerweile offene APIs an - Welche Rolle spielt die API speziell für Euer Geschäftsmodell?

Uns war es von Anfang an wichtig, die Daten unserer Kunden nicht einzusperren, sondern ihnen zahlreiche Möglichkeiten an die Hand zu geben, auf diese zuzugreifen. Die API spielt dabei eine zentrale Rolle. Und so waren die ersten Anwendungen, die auf unsere API aufgesetzt wurden, auch interne Anbindungen, beispielsweise für Back-up-Zwecke oder zur Synchronisation mit internen Datenbeständen.
Inzwischen haben uns mehrere andere Web Services und Desktop-Anwendungen integriert, und greifen auf unsere Daten zu. Dies spielt insofern eine Rolle, da dies unser Produkt stärker im Markt verankert und unseren Kunden einen echten Mehrwert verschafft. Sie selbst können, anstatt ein schweres All-in-one-System einzusetzen, flexibel einzelne Komponenten zusammenstöpseln – und zwar genau die, die sie wirklich benötigen. Zudem erreicht unser kleines Unternehmen auf diesem Wege auch potentielle Neukunden, die sonst vielleicht nicht auf uns aufmerksam geworden wären. Üblich ist ja durchaus, beispielsweise auf den jeweiligen Blogs solche API-Anbindungen zu bewerben. Alle Seiten profitieren von solchen Kooperationen, und keiner verliert, da niemand ein angebundenes Tool nutzen muss – das ist das wirklich Schöne an diesen losen Verknüpfungen.

Welche Gründe waren für die Wahl der Architektur der API ausschlaggebend?

Zum ersten: SOAP ist definitiv der “Industrie-Standard” im Bereich der Webservices, mit aller Sicherheit und allem Overhead der damit einher geht. Als junges Unternehmen ist es uns allerdings wichtig, gerade derartige Standards zu hinterfragen und nach leichtgewichtigeren Alternativen zu suchen.
REST ist hingegen kein neuer Standard, sondern folgt einfach strikt den vorhanden Standards des Webs; mit allen bekannten Einschränkungen und den daraus resultierenden Vorteilen. Dies hat den netten Nebeneffekt, dass die Beschäftigung mit REST mein Verständnis von HTTP nachhaltig vertieft hat, mit positiven Auswirkungen auf alle anderen Bereiche der Entwicklung und Architektur unserer Webanwendungen.
Ausschlaggebend bei der Entscheidung für REST waren für uns in erster Linie unsere eigenen Erfahrungen als API-Konsumenten, sowohl mit SOAP, Pseudo-REST oder auch reinen REST-Schnittstellen. Hier wurde sehr schnell klar, dass wir unseren Anwendern eine REST-konforme API anbieten wollen.
Den technischen Hauptvorteil einer “RESTful API” sehe ich in der strikten Einhaltung entlang vorhandener und bewährter Webstandards. Der Anwender kann unmittelbar mit den vorhandenen Ressourcen arbeiten, ohne sich erst langwierig durch die Dokumentation zu wühlen und auf ein neues Protokoll einstellen zu müssen.
Ein POST- oder gar GET-Request wird bei uns niemals eine Ressource zerstören. Das schafft Vertrauen und lädt zum “Spielen” mit unserer API ein. Als Client kommt alles in Frage, was HTTP spricht. Sich mittels eines Browsers einen Überblick über die eigenen Daten und deren Repräsentation verschaffen zu können, halte ich für eine hervorragende Alternative und Ergänzung zum Lesen der Dokumentation. Als Anbieter des Web-Services sehe ich vor allem den Vorteil, dass wir unsere Web-Anwendungen nicht mehrfach “denken”, bauen und verwalten müssen. mite ist komplett als REST-Service umgesetzt. Der Server liefert einfach das für den Client geeignetste Format aus, sei dies HTML für den Menschen oder eben XML/JSON für die Maschine.
Hinzu kommen noch die Vorteile für die Server-Architektur durch die Verwendung von schlichtem HTTP, beispielsweise bei den Themen Load Balancing und Caching.

Wie wurde die API konkret entwickelt?

Den meisten APIs merkt man an, dass sie am Reißbrett entworfen wurden. Uns war wichtig, auch die API evolutionär, gemeinsam mit unseren Kunden zu entwickeln. Der erste Wurf war noch sehr rudimentär, enthielt nur die wichtigsten Ressourcen und Attribute und war klar als “Beta” gekennzeichnet. Inzwischen haben wir viele Ideen unserer Kunden und Korrekturen einfließen lassen. Die Entwicklung hat sich in letzter Zeit stark stabilisiert. Dennoch kommt es immer wieder zu Situationen, in denen wir uns zusammen mit externen Entwicklern überlegen, wie wir ihren Bedürfnissen noch ein Stück näher kommen können.

Welche Erfahrungen habt Ihr mit externen Entwicklern und deren Mash-ups gemacht?

Ich habe generell den Eindruck, dass sowohl professionelle Programmierer als auch unbedarftere Entwickler die API sehr schnell produktiv einsetzen, überschauen und dann auch sinnvolles Feedback dazu geben können. Dennoch werden die meisten Ankündigungen, vor allem von privaten “Bastlern”, nie fertig gestellt und veröffentlicht. Bisher haben wir eher die Erfahrung gemacht, dass bei externen Entwicklern ein professionelles Interesse vorhanden sein muss, um Entwicklungen abzuschließen und ggf. zu vermarkten. Hier unterscheidet sich mite sicherlich von OpenSource-Projekten oder “freien” Web Services wie Facebook oder Twitter. Die soziale Anerkennung, die durch eine Veröffentlichung eingestrichen werden kann, ist einfach wesentlich geringer. Im Umkehrschluss führt das jedoch auch ganz klar zu einer höheren Qualität der Mash-ups.

Gibt es Ideen, mite auch mobil, z.B. per SMS, nutzbar zu machen?

Im Moment bieten wir für den mobilen Einsatz ausschließlich eine iPhone-optimierte Version von mite an. Angedacht ist die Umsetzung einer entsprechenden Variante für Opera Mobile, um eine wesentlich breitere Anzahl an mobilen Endgeräten zu unterstützen. Aber auch eine schlanke Zeiterfassung via SMS, vergleichbar mit den bereits realisierten Eingabemöglichkeiten via Jabber und Twitter, wäre für uns vorstellbar. Bisher fehlt uns hier allerdings noch der konkrete Kundenwunsch.

Vielen Dank für das Gespräch!

Anfang dieser Woche hat Facebook bekanntgegeben, das Single-Sign-On Verfahren von OpenID vollständig zu implementieren. Dies ist ein bedeutender Schritt, den andere Firmen wie Google, Yahoo und MySpace in der Vergangenheit nur halbherzig gemacht haben. Er ist wegweisend für die Zukunft, was den Einsatz von Single-Sign-On Verfahren im Web 2.0-Umfeld angeht.

OpenID

Facebook, im Gegensatz zu den meisten Konkurrenten, hat sich für die volle OpenID-Implementierung entschieden. Dies bedeutet, dass man Nutzern, die ihre OpenID von einem anderen Anbieter ausgestellt bekommen haben, ebenfalls den Zugriff auf die eigene Plattform gewährt.

Zudem wurde die neue Open Stream API veröffentlicht, mit dessen Hilfe Entwickler einen erleichterten Zugang zum kompletten Feed von Facebook-Nutzern erhalten.

An diesem Punkt werden mit Sicherheit einige Entwickler ansetzen und interessante Applikationen und Mash-ups kreiern. Wir dürfen gespannt sein!