Am Nikolaustag hat Google das Web um ein weiteres API (Application Programming Interface) bereichert: das Chart-API. Der Gebrauch des APIs ist einfach und das Resultat schön anzusehen. Kein Wunder also, dass sich die Ankündigung des Chart-APIs wie ein Lauffeuer in der Bloggosphäre verbreitet. Mit einem einfachen HTTP-Request wie diesem als src-Attribut in einem img-Tag
ergibt sich der folgende visuelle Effekt:
Das API scheint wirklich nützlich zu sein, wenngleich das Interface für Menschen wenig intuitiv ist. Insofern darf man gespannt sein auf die ersten Webseiten, die einem mit einer graphischen Oberfläche beim Erstellen solcher Charts helfen und ein einfaches Experimentieren mit den Parametervarianten ermöglichen. Das sollte mit ein wenig HTML-Code und JavaScript zu machen sein.
Solche APIs gehen in die richtige Richtung: Sie machen Web-Seiten rein beschreibend (deklarativ), die Kern-Information und damit die Semantik von Daten bleibt erhalten und sie verführen zum Gebrauch, da sie sinnvoll und nützlich sind. Es würde mich nicht wundern, wenn in Zukunft solche deklarativen Service-APIs, zusammen mit den sogenannten Microformaten und Meta-Daten (z.B. in Form von Tags) das Web mehr und besser um semantische Information bereichern als es die ganzen bisherigen Standardisierungsversuche des W3C zum semantischen Web geschafft haben. Zumindest dann, wenn Menschen bei der Erstellung von webfähigen Inhalten zur Anreicherung um semantische Informationen verleiten werden sollen.
Ein Problem jedoch bleibt beim Einsatz von APIs: Was, wenn der Google-Dienst einmal ausfällt oder nicht verfügbar ist (z.B. da man offline ist)? Dann durchziehen eine Webseite Informationslöcher. Was, wenn Google das API ändert ohne kompatibel zu früheren Versionen zu sein?
Es wird zunehmend wichtiger, sich mit der Problematik der Nachhaltigkeit (um den Begriff auch mal in so einem Kontext zu verwenden) von Web-Seiten auseinander zu setzen. Wie können Webseiten zuverlässig gerendert (d.h. vollständig visuell aufbereitet) werden, auch wenn die dazu benötigten Web-Dienste nicht jederzeit und immer zur Verfügung stehen? Ein Grundproblem aller verteilten, dezentralen Systeme. Dabei sind einfache Ein-/Ausgabedienste wie Googles Chart-API noch das geringste Problem.
Eine simple Möglichkeit besteht darin, ein einmal über das Chart-API angefordertes Bild abzuspeichern und als Alternative lokal oder auf einem Webserver vorzuhalten. Um diesen Vorgang im Hintergrund zu automatisieren, kann man etwa mit Erweiterungen zum Browser arbeiten oder einen Webserver diese Arbeit machen lassen. Mir fallen einige Lösungsstrategien dazu ein. Und das ist genau der wunde Punkt daran: Lösungsmöglichkeiten zur Nachhaltigkeit von Webseiten gibt es viele. Doch was hilft es, wenn es so viele Nachhaltigkeitslösungen wie Service-APIs gibt? Man wird sich in Zukunft mit offline-Techniken als nahtlose Fortsetzung des online-Zustandes befassen müssen -- und sich gleichzeitig um die Nachhaltigkeit der Darstellung deklarativer Informationen kümmern müssen. Dienste wie Google Gears sind dabei ein Teil möglicher, brauchbarer Lösungsansätze.
http://chart.apis.google.com/chart?cht=p3&chd=s:Uf9a&chs=200x100&chl=A|B|C|D">
ergibt sich der folgende visuelle Effekt:
Das API scheint wirklich nützlich zu sein, wenngleich das Interface für Menschen wenig intuitiv ist. Insofern darf man gespannt sein auf die ersten Webseiten, die einem mit einer graphischen Oberfläche beim Erstellen solcher Charts helfen und ein einfaches Experimentieren mit den Parametervarianten ermöglichen. Das sollte mit ein wenig HTML-Code und JavaScript zu machen sein.
Solche APIs gehen in die richtige Richtung: Sie machen Web-Seiten rein beschreibend (deklarativ), die Kern-Information und damit die Semantik von Daten bleibt erhalten und sie verführen zum Gebrauch, da sie sinnvoll und nützlich sind. Es würde mich nicht wundern, wenn in Zukunft solche deklarativen Service-APIs, zusammen mit den sogenannten Microformaten und Meta-Daten (z.B. in Form von Tags) das Web mehr und besser um semantische Information bereichern als es die ganzen bisherigen Standardisierungsversuche des W3C zum semantischen Web geschafft haben. Zumindest dann, wenn Menschen bei der Erstellung von webfähigen Inhalten zur Anreicherung um semantische Informationen verleiten werden sollen.
Ein Problem jedoch bleibt beim Einsatz von APIs: Was, wenn der Google-Dienst einmal ausfällt oder nicht verfügbar ist (z.B. da man offline ist)? Dann durchziehen eine Webseite Informationslöcher. Was, wenn Google das API ändert ohne kompatibel zu früheren Versionen zu sein?
Es wird zunehmend wichtiger, sich mit der Problematik der Nachhaltigkeit (um den Begriff auch mal in so einem Kontext zu verwenden) von Web-Seiten auseinander zu setzen. Wie können Webseiten zuverlässig gerendert (d.h. vollständig visuell aufbereitet) werden, auch wenn die dazu benötigten Web-Dienste nicht jederzeit und immer zur Verfügung stehen? Ein Grundproblem aller verteilten, dezentralen Systeme. Dabei sind einfache Ein-/Ausgabedienste wie Googles Chart-API noch das geringste Problem.
Eine simple Möglichkeit besteht darin, ein einmal über das Chart-API angefordertes Bild abzuspeichern und als Alternative lokal oder auf einem Webserver vorzuhalten. Um diesen Vorgang im Hintergrund zu automatisieren, kann man etwa mit Erweiterungen zum Browser arbeiten oder einen Webserver diese Arbeit machen lassen. Mir fallen einige Lösungsstrategien dazu ein. Und das ist genau der wunde Punkt daran: Lösungsmöglichkeiten zur Nachhaltigkeit von Webseiten gibt es viele. Doch was hilft es, wenn es so viele Nachhaltigkeitslösungen wie Service-APIs gibt? Man wird sich in Zukunft mit offline-Techniken als nahtlose Fortsetzung des online-Zustandes befassen müssen -- und sich gleichzeitig um die Nachhaltigkeit der Darstellung deklarativer Informationen kümmern müssen. Dienste wie Google Gears sind dabei ein Teil möglicher, brauchbarer Lösungsansätze.