Interoperabilität im Web 2.0: Evaluierung und...

$: Interoperabilität im Web 2.0: Evaluierung und ...l3s.de/~zerr/teaching/Masterarbeit-Tristan-Wehrmaker-Display.pdf · A New Approach to Web Applications\ erw ahnt [ Gar05]. Damit$
Leibniz Universitat Hannover

Fakultat fur Elektrotechnik und Informatik

Institut fur verteilte Systeme

Fachgebiet Wissensbasierte Systeme

Forschungszentrum L3S

Interoperabilitat im Web 2.0:

Evaluierung und Implementierung

von Mechanismen fur die Integration von

Social Media Diensten

Masterarbeit

im Studiengang Informatik

von

Tristan Wehrmaker

Prufer: Prof. Dr. Wolfgang Nejdl

Zweitprufer: Prof. Dr. Kurt Schneider

Betreuer: M.Sc. Fabian Abel, M.Sc. Dipl.-Inf. (FH) Sergej Zerr

30. April 2009

Zusammenfassung

Im Web 2.0 gibt es zahlreiche sogenannte Social Media Dienste. Viele dieserDienste bieten APIs, uber die ihre Daten und Funktionalitaten anderen Anwen-dungen zur Verfugung gestellt werden. Sollen Daten bei den Web 2.0 Dienstenveroffentlicht oder gesucht werden, mussen sich die Benutzer mit vielen unter-schiedlichen Weboberflachen befassen. In dieser Arbeit werden Web 2.0 Diensteund ihre APIs analysiert. Dafur wird ein konzeptionelles Framework aufgestellt,das zur Charakterisierung von Web 2.0 Diensten angewendet werden kann. Ba-sierend auf den Ergebnissen der Analyse wird eine Plattform implementiert,die zehn verschiedene Web 2.0 Dienste integriert und somit dem Benutzer denZugriff auf die Weboberflachen erspart. Die Plattform ist beliebig um weitereWeb 2.0 Dienste erweiterbar. Daruber hinaus wird eine Clientapplikation inForm einer Firefox Extension implementiert, mit der Benutzer ihre Daten mitnur wenigen Klicks veroffentlichen konnen.

Abstract

In Web 2.0 social media services are very popular. Many of those serviceshave APIs to give other applications access to their data and functionality.Whenever data shall be published or discovered, the user has to interact withmany different web user interfaces. In this thesis we present the analysis of suchWeb 2.0 services and their APIs. Therefor a conceptual framework is provided,that is used to characterize Web 2.0 services. Based on the results of the analysisa platform is implemented, which integrates 10 different Web 2.0 services andhence saves the user the access to the web user interfaces. This platform caneasily be extended with additional Web 2.0 services. Furthermore, we introducea client application that is realized as a Firefox Extension and allows the userto publish her data with just a few clicks.

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einleitung 71.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Beitrag dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Struktur dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Grundlagen 92.1 Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Das programmierbare Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Technologien im programmierbaren Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 REST und ressourcenorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 Kernkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.2 Umsetzung der Prinzipien von REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Architekturen im programmierbaren Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.1 REST-konforme Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.2 Architekturen im RPC-Stil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.3 REST-RPC-Hybridarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Datenaustauschformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.3 RSS und Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Autorisierung und Authentifizierung in Web 2.0 Services 233.1 Login-basierte Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Token-basierte Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Sequential-Token-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Interrupted-Token-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.3 Login-Token-Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 Manual-Token-Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.5 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Vergleich / Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Konzeptionelles Framework 29

5 API-Analyse 325.1 Flickr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 YouTube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Delicious . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4

Inhaltsverzeichnis

5.4 Ipernity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 last.fm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.6 SlideShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Blogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.8 Vimeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.9 Facebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.10 GroupMe! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.11 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Implementierung von InterWeb 606.1 Client ←→ InterWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1.1 Endpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.1.2 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.1.3 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.1.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1.5 Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1.6 Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2 InterWeb ←→ Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2.1 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2.2 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2.3 Freunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.2.4 Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3 Einbindung neuer Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Einsatz in LearnWeb2.0 74

8 Beschreibung der Firefox Extension 768.1 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.2 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.3 Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9 Zusammenfassung 78

A Bewertungsbogen zu Kapitel 4 80

B API Documentation 81

C Quellcode zur Beispielerweiterung 91

D Bibliotheken fur InterWeb 95

E Beiliegende CD und Installationshinweise 101

5

Inhaltsverzeichnis

Akronyme

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

CSS Cascading Style Sheets

DTD Document Type Definition

FQL Facebook Query Language

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

JSON JavaScript Object Notation

RDF Resource Description Framework

REST Representational State Transfer

ROA Ressourcenorientierte Architekur

RPC Remote Procedure Call

RSS Rich Site Summary, RDF Site Summary, Really Simple Syndication

SGML Standard Generalized Markup Language

SMTP Simple Mail Transport Protocol

SOA Serviceorientierte Architektur

SQL Structured Query Language

URI Uniform Resource Identifier

XHTML Extensible HyperText Markup Language

XML Extensible Markup Language

XSL Extensible Stylesheet Language

6

1 Einleitung

1 Einleitung

1.1 Motivation

Im Internet entstehen seit einigen Jahren immer mehr Web 2.0 Dienste. Diese sogenannten Social Softwaresdienen der menschlichen Kommunikation und Zusammenarbeit. Zu den großen Anbietern dieser Dienstegehoren heute zum Beispiel YouTube, Flickr, Delicious und Facebook. Zum Zeitpunkt dieser Arbeit listetdas Webportal ProgrammableWeb.com mehr als 1200 solcher Dienste, die Schnittstellen (APIs) anbieten,uber die auf sie zugegriffen werden kann [Pro09].Diese Social Softwares lassen sich grob in zwei Gruppen unterteilen. Das sind zum einen Social Media Diensteund zum anderen Social Networks, wobei die meisten Dienste auch Features der jeweiligen anderen Gruppemit anbieten.Wahrend Social Networks das Netzwerk aus Freunden und Bekannten der Benutzer modellieren, ermoglichenes typische Social Media Dienste den Benutzern ihre Videos, Fotos oder Bookmarks zu verwalten und mitanderen Nutzern zu teilen. Hierbei beschranken sie sich meist auf eine bestimmte Art von Medienobjekten(Videos, Fotos, Bookmarks, Audiodaten, Slideshows, etc.). Durch die Vielzahl moglicher Medientypen ist klar,dass ein Benutzer meist mehrere Accounts bei verschiedenen Services hat. Somit mussen sich die Benutzermit den verschiedenen Weboberflachen der einzelnen Web 2.0 Dienste auseinandersetzen.Wenn man nun eine Menge von Objekten verschiedenen Typs veroffentlichen will, hat das zur Folge, dassman sich bei jedem Service einloggen, die Uploadfunktion verstehen und den Upload durchfuhren muss.Genauso verhalt es sich mit dem Abrufen von Informationen bei diesen Diensten. Jeder Dienst hat eineeigene Prasentation seiner Daten, auf die sich der Benutzer einstellen muss.Einen Ansatz, die Arbeit mit verschiedenen Web 2.0 Diensten zu erleichtern, verfolgt das DataPortabilityProject [Dat08]. Es konzentriert sich hauptsachlich darauf, mit dem Einsatz von Technologien und offenenStandards die Portabilitat von Benutzerdaten (z.B. Profilinformationen) zu ermoglichen. Benutzer sollennicht mehr bei jedem Service ihre personlichen Daten angeben mussen. Einige große Firmen, wie Googleund Yahoo!, haben sich bereits der Initiative angeschlossen. Das Problem daran ist aber, dass diese Formder Interoperabilitat von Seiten des Betreibers ausgeht. Bei uber 1200 bei ProgrammableWeb.com gelistetenServices ist aber nicht davon auszugehen, dass sich alle der Initiative anschließen.Die Vision von Initiativen wie DataPortability ist, dass es Benutzern egal ist, wo seine Daten veroffentlichtwerden, solange sie fur seine Freunde oder die gewunschte Zielgruppe zugreifbar sind. Wenn der Benutzer nachRessourcen sucht, will er nicht bei jedem Dienst eine Suche durchfuhren und die Daten fur sich zusammensammeln, sondern er will einfach die gesuchten Informationen haben und das in einer Form, in der er sieeinfach weiterverarbeiten kann.Um diese Vision zu realisieren, muss ein Weg gefunden werden, das bestehende heterogene Geflecht ausWeb 2.0 Diensten in eine homogene Plattform zu uberfuhren.

1.2 Beitrag dieser Arbeit

In dieser Arbeit werden die APIs verschiedener Web 2.0 Dienste analysiert. Hierzu wird ein konzeptionellesFramework aufgestellt, mit dem Web 2.0 Dienste charakterisiert werden konnen.

7

1 Einleitung

Außerdem wird eine Plattform als Webservice implementiert, die die verschiedensten Dienste integriert.Damit wird dem Benutzer eine einheitliche Zugangsform geboten, um auf die Daten der Web 2.0 Dienstezuzugreifen.Die Plattform dient dem Upload, der Suche und dem Abrufen von Ressourcen bei den Web 2.0 Diensten.Sie kummert sich dabei um die Aggregation der Daten, so dass sie von zugreifenden Anwendungen weiter-verarbeitet werden konnen. Daruber hinaus werden Funktionalitaten zur Verfugung gestellt, mit denen einSocial Network realisiert werden kann.Zusatzlich wird eine Client-Anwendung vorgestellt, die als Extension fur den Webbrowser Firefox 3 im-plementiert ist. Diese Extension nutzt ”Drag & Drop“-Mechanismen, wodurch es dem Benutzer ermoglichtwird, mit wenigen Klicks Daten von seinem Rechner oder aus dem Internet bei den Web 2.0 Diensten zuveroffentlichen.

1.3 Struktur dieser Arbeit

Diese Arbeit besteht aus neun Kapiteln.

• Zuerst werden in Kapitel 2 alle notigen Grundlagen eingefuhrt. Dazu werden das Web 2.0, das pro-grammierbare Web und die darin verwendeten Technologien vorgestellt. Im Anschluss wird beschrieben,wie REST-konforme Architekturen aufgebaut sind und worin sich diese von den meisten Webservicesunterscheiden, die sich selbst aus Werbegrunden REST-konform nennen. Des Weiteren werden Daten-austauschformate vorgestellt, die von vielen Webservices als Ausgabeformate verwendet werden.

• Im dritten Kapitel werden Verfahren zur Autorisierung und Authentifizierung in Web 2.0 Servicesbehandelt. Dazu wird eine Best Practice aus diesen Verfahren ermittelt.

• Ein konzeptionelles Framework, das zur Charakterisierung von Web 2.0 Services und ihren APIs ge-eignet ist, wird in Kapitel 4 entwickelt.

• Dieses konzeptionelle Framework wird dann in Kapitel 5 auf zehn Web 2.0 Dienste angewendet und soder aktuelle Stand existierender APIs ermittelt.

• In Kapitel 6 wird die Implementierung einer Plattform beschrieben, die ihre Funktionalitaten alsWebservice zur Verfugung stellt. Dieser Webservice integriert die in Kapitel 5 analysierten Web 2.0Services und bietet lesenden und schreibenden Zugriff auf diese. Dabei werden erst die Zugriffe einesClients auf den Webservice und danach die Zugriffe vom Webservice auf die Web 2.0 Dienste be-schrieben. Im Anschluss wird an einem Beispiel erlautert, wie das System um weitere Web 2.0 Diensteerweitert werden kann.

• Kapitel 7 beschreibt kurz die Integration des Webservices durch die LearnWeb2.0 Plattform.

• Die Beschreibung einer Firefox Extension, die auf den in Kapitel 6 vorgestellten Webservice zugreift,erfolgt im achten Kapitel.

• In Kapitel 9 werden die Erkenntnisse zusammengefasst.

8

2 Grundlagen

2 Grundlagen

In diesem Kapitel werden die Grundlagen fur diese Masterarbeit eingefuhrt. Dazu wird zuerst auf das Schlag-wort Web 2.0 eingegangen, was dann zum programmierbaren Web fuhrt. Im Anschluss daran werden Tech-nologien und Architekturen im programmierbaren Web beschrieben. Anhand einer ressourcenorientiertenArchitektur werden die Prinzipien von REST dargestellt. Danach werden einige Datenaustauschformatevorgestellt, die ublicherweise von Web 2.0 APIs verwendet werden.

2.1 Web 2.0

Der Begriff des Web 2.0 wurde 2004 erstmals von dem O’Reilly Verlag und MediaLive International furihre gleichnamige Konferenzreihe eingefuhrt und erhielt schließlich 2005 mit Tim O’Reillys Artikel ”What IsWeb 2.0“ große Akzeptanz in der breiten Offentlichkeit [O’R05].Web 2.0 Anwendungen werden oftmals als Anwendungen bezeichnet, die sich Asynchronous JavaScript andXML (AJAX) zu nutze machen. Der Begriff AJAX wurde erstmals von Jesse James Garrett in seinem Essay

”A New Approach to Web Applications“ erwahnt [Gar05]. Damit meint man einen asynchronen Datenaus-tausch zwischen Server und Browser, bei dem mittels JavaScript XML Daten ausgetauscht werden [Gam07].Dabei geht es darum, HTML-Seiten bei Benutzerinteraktionen nicht komplett neu laden zu mussen, sondernnur die gefragten Daten sukzessiv nachzuladen. So kann man eine hohere User Experience erreichen. Es gibtAnsatze, komplette Desktopanwendungen als Webanwendungen nachzubauen.Web 2.0 ist aber viel mehr als das dynamische Laden von Webinhalten. Tim O’Reilly nennt einige Beispielefur den Ubergang von Web 1.0 auf Web 2.0 [O’R05]:

• Ofoto → Flickr(von Fotoalben zu Social Features wie Tagging etc.)

• Akamai → BitTorrent(von Serverfarmen zu Peer-2-Peer)

• mp3.com → Napster(von Downloads zu Tauschborsen)

• Britannica Online → Wikipedia(von zentral publizierten Enzyklopadien zur verteilten Community-basierten Enzyklopadie)

• personal websites → blogging(von Privaten Websites zu Online-Tagebuchern, in denen Beitrage kommentiert werden konnen)

• content management systems → wikis(von Redaktionssystemen zu Plattformen, in denen Webseiten kollaborativ erstellt werden)

• directories (taxonomy) → tagging (folksonomy)(von festgelegten Gliederungen zu dynamischen benutzergesteuerten Einordnungen)

9

2 Grundlagen

Allen gemein ist die Partizipation der Benutzer an der Erstellung von Internetinhalten. Das heißt also, dassdie Inhalte nicht mehr nur von einer Seite publiziert, sondern von allen Nutzern zusammengetragen werdenkonnen. Daher wird das Web 2.0 auch oftmals als ”Mitmach-Web“ bezeichnet.In den vergangenen Jahren haben sich neben den bekannten Social Networks wie LinkedIn und Facebook,die hauptsachlich auf die Kommunikation und die Vernetzung von Menschen abzielen, auch viele andere An-wendungen ergeben, die so erst durch Breitband-Internetanschlusse moglich sind und zu Zeiten des Web 1.0und der POTS-Modems nicht denkbar gewesen waren [Alb07]. Zu solchen Anwendungen zahlen die SocialMedia-Dienste, bei denen Benutzer ihre Daten, z.B. Fotos und Videos, im Internet veroffentlichen konnen.Zu den bekanntesten zahlen hierbei Flickr und YouTube.

2.2 Das programmierbare Web

Das Web ist voll mit Informationen und Daten. Fotos, Videos, Buchinformationen bis hin zu Bahnfahrzeitenkonnen frei abgerufen werden. Außerdem findet man im Web eine Vielzahl von Services/Dienstleistungen imklassischen Sinn. Solche Services sind zum Beispiel Onlineshops, Suchmaschinen und Wikis.Das Web 1.0 ist zur Zeit primar fur Menschen entwickelt. Daten werden als HTML, meist in einer furden Menschen optisch schonen Form, prasentiert. Das programmierbare Web hingegen ist nicht nur fur denMenschen gedacht. Die Daten werden oft in kargem XML oder anderen Formaten ausgegeben, die fur diemaschinelle Verarbeitung geeignet sind [RR07]. Basis aller Technologien im Web ist HTTP.Haufig trifft man im programmierbaren Web auf den Begriff Mashup. Er stammt ursprunglich aus der Musik.Mit ihm bezeichnet man die Kombination der Musik eines Songs mit dem Gesang eines anderen Songs [Alb07].Im Web werden Mashups genutzt, um Inhalte von verschiedenen Diensten zu kombinieren und so neueDienste zu erhalten. Besonders beliebt sind zum Beispiel Mashups, bei denen Karten von Google Maps mitzusatzlichen Informationen, wie zum Beispiel Blitzerwarnungen, versehen werden [CCHZ08].Um Mashups zu realisieren, stellen viele Services sogenannte Application Programming Interfaces (APIs)zur Verfugung. Mit diesen APIs erhalten Entwickler Zugriff auf die wesentlichen Informationen, die in einemService gespeichert sind. Die Anwendung wird in die Lage versetzt, Aktionen im Namen eines Benutzersauszufuhren. So gibt es zum Beispiel zahlreiche Desktopanwendungen, die Fotos direkt zu Flickr oder Videosdirekt nach dem Erstellen zu YouTube laden konnen. Die Untersuchung, wie machtig einige dieser APIs sind,erfolgt in Kapitel 5.

2.3 Technologien im programmierbaren Web

Nun sollen einige Technologien vorgestellt werden, die im Web anzutreffen sind. Angefangen bei der Basisaller Technologien, dem HTTP, hin zu den haufig anzutreffenden Technologien XML-RPC und SOAP.

2.3.1 HTTP

Das HyperText Transfer Protocol (HTTP) ist das fur den Informationsaustausch im Web verwendete Proto-koll [Wil99]. Seit 1999 liegt es in der RFC 2616 als HTTP/1.1 vor [FGM+99]. Es handelt sich bei HTTP umein dokumentenbasiertes Protokoll, in dem der Client ein Dokument in einen Umschlag steckt und diesen anden Server sendet.Nachdem der Server die Anfrage verarbeitet hat, verpackt er wiederum ein Ergebnisdokument in einemUmschlag und gibt diesen zuruck an den Client.Die HTTP-Anfrage fur http://www.et-inf.uni-hannover.de/studium.html kann im Browser zum Beispielfolgendermaßen aussehen:

10

2 Grundlagen

GET /studium.html HTTP/1.1Host: www.et-inf.uni-hannover.deUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.8) Gecko/2009032608

Firefox/3.0.8Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-alive

Listing 2.1: HTTP-Anfrage

Der Umschlag einer HTTP-Anfrage enthalt:

• eine HTTP-Methode: Dies ist der Name einer Methode, der angibt, wie diese Anfrage verarbeitetwerden soll. Hier gibt ”GET“ an, dass Daten vom Server abgerufen werden sollen.

• einen Pfad: Der Pfad (hier: /studium.html) gibt an, auf welche Ressource auf dem Server zugegriffenwerden soll.

• mehrere Anfrage-Header: In HTTP sind eine Vielzahl von Standard-Headern vordefiniert, die umeigene Header erweitert werden konnen. Bei den Headern handelt es sich um Schlussel-Wert-Paare, dieMeta-Daten fur die Verarbeitung festlegen. Im Beispiel enthalt der Header Host den Domain-Namendes Servers, User-Agent beschreibt den aufrufenden Client, Accept gibt an, welche Ruckgabeformate alsAntwort akzeptiert werden, usw. (siehe hierzu [FGM+99]). Die Header, die mit Accept beginnen, dienender sogenannten HTTP Content Negotiation. Damit kann festgelegt werden, welches Format, welcheSprache und welche Kodierung die Antwort haben muss. Dabei konnen Priorisierungen angegebenwerden, nach denen dann entschieden wird, welche Reprasentation zuruckgeliefert wird, wenn die hochstpriorisierte nicht verfugbar ist [Wil99].

• einen Entity-Body: Dies ist das Dokument, das an den Server gesendet werden soll. Das Beispiel inListing 2.1 hat keinen Entity-Body, da sich alle fur die GET-Anfrage notigen Daten in den Headernund im Pfad befinden.

Die entsprechende Antwort sieht etwa wie folgt aus (gekurzt):

HTTP/1.1 200 OKDate: Mon, 13 Apr 2009 19:01:04 GMTServer: ApacheX-Powered-By: PHP/5.2.0-8+etch13Transfer-Encoding: chunkedContent-Type: text/html; charset=utf-8

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

...<title> LUH -nbsp;Studium</title><style type="text/css">...

Listing 2.2: HTTP-Antwort

Der Umschlag einer HTTP-Antwort enthalt folgende Elemente:

11

2 Grundlagen

• einen HTTP-Responsecode: Dies ist ein numerischer Code, der dem Client mitteilt, ob seine An-frage erfolgreich war oder nicht. Hier gibt 200 (”OK“) an, dass der Server die Anfrage erfolgreichausgefuhrt hat. Die Codes lassen sich wie folgt einordnen:

– 1xx - Informational: Die Anfrage ist angekommen und wird gerade verarbeitet.

– 2xx - Success: Die Anfrage konnte erfolgreich ausgefuhrt werden.

– 3xx - Redirection: Die Anfrage muss umgeleitet werden. Weitere Schritte des Clients sinderforderlich.

– 4xx - Client Error: Die Anfrage ist durch einen Fehler des Clients gescheitert. Zum Beispiel istdie Anfrage nicht richtig gestellt oder die Ressource nicht verfugbar.

– 5xx - Server Error: Die Anfrage ist durch einen Fehler des Servers gescheitert. Zum Beispielist der Server gerade uberlastet oder die Ausfuhrung eines datenverarbeitenden Prozesses fuhrtezu einem Fehler.

• mehrere Antwort-Header: Auch in der HTTP-Antwort ist eine Vielzahl von Headern moglich.Hier geben sie Informationen uber den Zeitpunkt der Bearbeitung, den Server und den Typ des imEntity-Body enthaltenen Dokuments.

• einen Entity-Body: Dies ist das Antwort-Dokument des Servers. Es hat den im Content-Type-Headerdefinierten Typ. Im Browser werden meist text/html und text/css ubertragen, aber auch Binardatenwie Bilder (image/jpg etc.) sind ublich.

2.3.2 XML-RPC

XML-RPC ist ein Remote Procedure Calling-Protokoll. Die Spezifikation wurde 1999 von Dave Winer, derunter anderem auch fur RSS 0.91 und RSS 2.0 verantwortlich ist, festgelegt [Win99].Eine XML-RPC-Nachricht ist eine HTTP-POST-Anfrage, in deren Body eine XML-Struktur ubertragenwird. Eine Prozedur auf dem Server verarbeitet dieses XML und gibt wiederum ein XML als Antwortzuruck [LJD01]. Dabei gibt es auf dem Server im Allgemeinen einen Endpunkt, an den die Nachrichtengesendet werden. Aus der Payload einer Nachricht wird dann entschieden, an welche Methode die Datenweitergereicht werden. Im folgenden Beispiel soll eine Multiplikation zweier Werte durchgefuhrt (siehe Listing2.3) und das Ergebnis als Antwort vom Service zuruckgegeben werden (siehe Listing 2.4).

<?xml version="1.0" encoding="utf-8"?><methodCall>

<methodName>service.mul</methodName><params>

<param><value><int>8</int></value></param><param><value><int>7</int></value></param>

</params></methodCall>

Listing 2.3: Beispiel fur eine XML-RPC-Anfrage

<?xml version="1.0" encoding="utf-8"?><methodResponse>

<params><param><value><int>56</int></value></param>

</params></methodResponse>

Listing 2.4: Beispiel fur eine XML-RPC-Antwort

12

2 Grundlagen

Wie man sieht, ist die Methode, die ausgefuhrt werden soll, durch das Element methodName festgelegt. Dasheißt, dass von außen nicht erkannt werden kann, zu welcher Prozedur die Parameter weitergereicht werdenmussen. Dazu muss erst die gesamte Payload verarbeitet werden.

2.3.3 SOAP

Auf XML-RPC basierend, entstanden kurz darauf die sogenannten SOAP-basierten Webservices. Diese ver-wenden SOAP als Protokoll fur den Nachrichtenaustausch. SOAP stand ursprunglich fur ”Simple ObjectAccess Protocol“. Da aber mit der Zeit immer mehr Features aufgenommen wurden, konnte nicht mehrvon einfach (simple) gesprochen werden. Außerdem dient es nicht direkt dem Objektzugriff. Daher wird derBegriff seit der Version 1.2 nicht mehr als Akronym verwendet [ML07].SOAP ist wie HTTP ein Umschlagformat. Das heißt, dass die Daten, die ubermittelt werden sollen, in einemSOAP-Umschlag verpackt werden, der dann wiederum in einen HTTP-Umschlag gesteckt wird.SOAP beschrankt sich auf dem Anwendungslayer des TCP/IP-Referenzmodells nicht auf HTTP, sondernkann zum Beispiel auch uber das Simple Mail Transport Protocol (SMTP) ubertragen werden [STK02]. SolcheServices konnen dann, im Sinne des programmierbaren Web, nicht als Webservices bezeichnet werden, da siesich nicht im Web befinden.An sich handelt es sich bei SOAP nicht um ein RPC-Format, es wird aber meist als ein solches verwen-det. Dies liegt vor allem an der weiten Verbreitung der Web Service Description Language (WSDL), diegenutzt wird, um SOAP-basierte Webservices zu beschreiben. Ein Client kann eine WSDL-Datei laden undweiß dann, welche Methoden er im RPC-Stil aufrufen kann, welche Argumente benotigt werden und wel-che Datentypen er zuruckerwarten kann [RR07]. Vorteil von SOAP-basierten Webservices ist, dass sie einehohe Tool-Unterstutzung haben und so zum Beispiel Code direkt aus WSDL-Informationen, bzw. WSDL-Informationen aus Code generiert werden konnen.Im Laufe der Jahre entstanden im Kontext von SOAP und WSDL viele Standards, die sich auf Anwen-dungsbereiche beziehen, die in SOAP und WSDL nicht festgelegt sind. Dazu gehoren zum Beispiel WS-Security, fur die Integritat und Verschlusselung von Nachrichten, oder WS-BPEL, fur die Modellierung vonGeschaftsprozessen. Da die Namen dieser Standards mit WS beginnen, werden sie zusammen ”WS-*-Stack“genannt [RR07].Webservices, die SOAP, WSDL und den WS-*-Stack einsetzen, werden im Folgenden als dicke Webservicesbezeichnet.

2.4 REST und ressourcenorientierte Architekturen

Dicke Webservices ignorieren entweder alle Features, durch die das Web so erfolgreich wurde, oder sie erfindenes neu [RR07]. Allen voran ist dies zum Beispiel die Missachtung der vorgegeben HTTP-Methoden, durchdie schon eine Semantik des Aufrufs festgelegt werden kann.Roy Fielding hat in Kapitel 5 seiner Dissertation ”Architectural Styles and the Design of Network-basedSoftware Architectures“ eine Sammlung von Prinzipien aufgestellt, die er Representational State Transfer(REST) nennt [Fie00]. Diese Prinzipien besagen, dass alle Zustande und Funktionalitaten in Ressourcenabstrahiert sind, dass alle Ressourcen eindeutig adressierbar sind, dass auf alle Ressourcen uber eine einheit-liche Schnittstelle zugegriffen werden kann und dass das Protokoll, mit dem zugegriffen wird, zustandslosist [RR07]. Ein Beispiel einer REST-konforme Architektur ist das World Wide Web.

Bei der Holzverarbeitung ist es wichtig, mit der Maserung des Holzes zu arbeiten.Das Web hat auch eine Maserung, und ein REST-konformer Web Service ist einer, der damit arbeitet.

(Zitat [RR07])

13

2 Grundlagen

Bei REST geht es also darum, anstatt immer neue schwergewichtige Protokolle auf das Web aufzusetzen,einen Schritt zuruckzutreten und sich auf die Mechanismen zu besinnen, die HTTP einem schon von vorn-herein bietet.REST selbst ist keine Architektur, sondern nur eine Zusammenstellung von Designprinzipien. Aus diesemGrund stellen Leonard Richardson und Sam Ruby in ”Web Services mit REST“ eine REST-konforme Archi-tektur vor [RR07]. Diese ressourcenorientierte Architektur (ROA) enthalt vier Kernkonzepte:

• Ressourcen,

• URIs,

• Reprasentationen und

• Verweise zwischen ihnen.

Mit diesen Konzepten lassen sich die vier Eigenschaften von REST-konformen Architekturen erfullen:

• Adressierbarkeit,

• Zustandslosigkeit,

• Verbindungshaftigkeit und

• eine einheitliche Schnittstelle.

Im Folgenden sollen diese Konzepte vorgestellt werden. Außerdem soll erlautert werden, wie sie die genanntenEigenschaften umsetzen.

2.4.1 Kernkonzepte

Ressourcen

Eine Ressource ist alles, was wichtig genug ist, dass auf es referenziert werden sollte. Sie kann zum Beispielein Dokument, das Ergebnis eines Algorithmus’ oder ein physikalischer Gegenstand sein. Wichtig in derUnterscheidung zu RPC-artigen Architekturen ist hier also, dass nicht auf eine Methode zugegriffen wird,sondern auf die Ressource selbst [RR07].

URIs

Eine Ressource muss mindestens einen Uniform Resource Identifier (URI) haben. Der URI ist der Nameund damit die Adresse einer Ressource. Durch einen URI kann man eine Ressource eindeutig identifizieren.Eine Ressource kann zwar mehrere Namen (URIs) haben, aber ein URI nicht mehrere Ressourcen referen-zieren [RR07].

Reprasentationen

Ressourcen sind keine Daten, die von einem Client abgerufen werden konnen. Sie sind lediglich etwas, wassich der Entwickler des Webservices bei der Identifikation von moglichen Ressourcen darunter vorgestellthat. Solche Vorstellungen kann der Server aber nicht senden. Dazu werden Reprasentationen dieser benotigt.So sind fur eine einzelne Ressource verschiedene Sprachen oder Ausgabeformate denkbar [RR07].Angenommen, man hat als Ressource ein Buch. Dieses Buch kann verschiedene Reprasentationen haben. EineReprasentation ist zum Beispiel die deutsche Fassung des Buches, eine andere die spanische Ubersetzung.

14

2 Grundlagen

Außerdem ist es moglich, dass der Benutzer das Buch als PDF oder als Plaintext geliefert haben mochte. Inallen Fallen handelt es sich um die gleiche Ressource, nur die Reprasentationen sind verschieden.Im Web konnen konkrete Reprasentationen, zum Beispiel uber die Accept-Felder im HTTP-Header, ange-fordert werden. Ublich ist daruber hinaus auch die Angabe des Formats als korrespondierende Dateiendungim URI [RR07]. Fur das Buchbeispiel waren dies etwa http://www.example.org/book.pdf oder http://www.

example.org/book.txt.

Verweise

Reprasentationen konnen nicht nur Ressourcen enthalten, sondern auch Verweise zu anderen Ressourcen.Man stelle sich die Reprasentation eines Suchergebnisses vor. Darin sind sicherlich nicht nur die Titel undBeschreibungen der Ergebnisse enthalten, sondern auch Verweise auf die gefundenen Ressourcen, bzw. zuReprasentationen dieser [RR07].

2.4.2 Umsetzung der Prinzipien von REST

Adressierbarkeit

Eine Anwendung ist adressierbar, wenn auf ihre wichtigen Daten uber URIs als Ressourcen zugegriffen werdenkann. HTTP ist adressierbar [FGM+99]. Wenn HTTP nicht adressierbar ware, konnte die URI der Ressourcehttp://www.et-inf.uni-hannover.de/studium.html hier nicht geschrieben werden. Man musste dem Benutzereine Anleitung geben, wie er auf die Ressource zugreifen kann. Zum Beispiel: ”Offne ein Browserfenster undstelle eine Verbindung zu www.et-inf.uni-hannover.de her. Wahle nun den Menupunkt Studium“.

Zustandslosigkeit

Zustandslosigkeit heißt, dass jede HTTP-Anfrage unabhangig von der vorherigen gestellt werden kann. DerClient gibt in seiner Anfrage alle Informationen mit, die der Server fur die Verarbeitung benotigt [Wil99].Durch die Zustandslosigkeit ist es in Verbindung mit der Adressierbarkeit moglich, dass ein Benutzer einemanderen Benutzer einen URI mitteilt und dieser das gleiche Ergebnis erhalt, wie der erste.Naturlich gibt es weiterhin zwei Arten von Zustanden. Einer ist der Anwendungszustand, der allein durchden Client verwaltet wird. Der andere ist der Ressourcen-Zustand, der auf dem Server verwaltet wird. DerClient arbeitet aber unabhangig vom Ressourcen-Zustand und der Server unabhangig vom Anwendungszu-stand [RR07].

Verbindungshaftigkeit

Die Verbindungshaftigkeit sagt aus, dass Ressourcen in ihren Reprasentationen miteinander verknupft seinsollen. Als Beispiel sei wieder das Betrachten einer Website im Browser angefuhrt. Die wenigsten Benutzerverwenden die Adresszeile des Browsers effektiv zum Navigieren im Web. Die meisten haben ihre voreinge-stellte Startseite, von der aus sie durchs Web navigieren. Damit ist klar, dass Ressourcen, die nicht verbundensind, mit großer Wahrscheinlichkeit nicht aufgesucht werden [RR07].Bei Webservices hat die Verbindungshaftigkeit daruber hinaus den Vorteil, dass der Client nicht alle URIsdes Webservices kennen muss. Er kann einfach bei einer Anfrage nach einer Ressource die URIs zu den damitverbundenen Ressourcen erhalten.

15

2 Grundlagen

einheitliche Schnittstelle

Ein großer Vorteil von REST-konformen Webservices ist, dass sie durch ihre einheitliche Schnittstelle nureine begrenzte Zahl von Methoden haben und man schon vorher weiß, was sie tun [RR07].In HTTP sind acht verschiedene Methoden definiert, von denen die wichtigsten sechs nun betrachtet werdensollen. Die ubrigen zwei Methoden, CONNECT und TRACE, sind nur fur spezielle Anwendungen (Proxysund Diagnosezwecke) gedacht und werden kaum genutzt [Wil99].

• GET: Die Methode GET ruft eine Reprasentation ab, die durch den URI identifiziert wird.

• POST: Mit der Methode POST konnen Informationen an einen Server gesendet werden. Hierbei han-delt es sich um das Hinzufugen von Ressourcen zu einer ubergeordneten Ressource, wie zum Beispiel dasHinzufugen von News zu einer Newsgroup oder die Ubergabe von Daten an einen datenverarbeitendenProzess.

• PUT: Die PUT-Methode dient, wie die POST-Methode, dem Ubertragen von Informationen an einenServer. Der Unterschied zu POST ist aber, dass eine neue Ressource an der durch den URI bestimmtenStelle angelegt wird. Existiert bereits eine Ressource zu diesem URI, so wird die bestehende Ressourcedurch die im Request enthaltene ersetzt.

• DELETE: Sollen Ressourcen auf dem Server geloscht werden, wird die Methode DELETE verwendet.Allerdings kann der Client nicht sicher sein, dass die Ressource geloscht worden ist, da der Server nurangibt, dass er die Absicht hat, die Loschung vorzunehmen.

• HEAD: Ahnlich wie bei GET, wird mit HEAD auf eine Ressource zugegriffen. Allerdings enthalt dieAntwort nur den Header und keinen Entity-Body. Diese Methode wird verwendet, um Veranderungenvon Ressourcen abzufragen, z.B. indem die Header-Felder Content-Length, Content-MD5 oder Last-Modified ausgelesen werden.

• OPTIONS: Mit der OPTIONS-Methode konnen Kommunikationsoptionen fur eine Ressource abge-rufen werden. So lasst sich herausfinden, welche Methoden unterstutzt werden.

Mit dieser begrenzten Anzahl an Methoden lassen sich alle denkbaren Operationen auf Ressourcen durch-fuhren. Diese Operationen werden haufig unter dem Begriff CRUD (Create Read Update Delete) zusammen-gefasst [MO08].Fur diese Methoden konnen zwei Eigenschaften gelten, wobei der Entwickler darauf achten muss, sie einzu-halten. Methoden, die nur fur das Abrufen von Daten verwendet werden, sind sicher. Das heißt, dass sichdurch das Aufrufen einer solchen Methode der Status des Servers nicht verandert. GET und HEAD sindsicher.Eine Methode ist idempotent, wenn sich mehrere identische Requests in ihrer Wirkung nicht von einem Ein-zelnen unterscheiden. Alle sicheren Methoden sind implizit idempotent. Zusatzlich sind DELETE und PUTidempotent [FGM+99]. Wenn eine Ressource geloscht wird, ist sie weg. Wird DELETE erneut aufgerufen,bleibt sie immer noch verschwunden. Das gleiche gilt fur PUT.POST ist weder sicher noch idempotent. Wird eine POST-Anfrage zum Anlegen von Ressourcen mehrmalsausgefuhrt, erhalt man auch mehrere Ressourcen [RR07].

2.5 Architekturen im programmierbaren Web

Wichtig in der Unterscheidung von Architekturen im programmierbaren Web sind die Verarbeitung vonMethodeninformation und Fokusinformation [RR07].

16

2 Grundlagen

Mit Methodeninformation ist die Information gemeint, anhand derer der Service entscheiden kann, wel-che Methode er ausfuhren soll. Die Fokusinformation gibt hingegen an, auf welche Daten er die Methodeanwenden soll.Nimmt man sich dies als Anhaltspunkt fur die Unterscheidung, erhalt man drei Arten von Architekturen,die im Folgenden erlautert werden sollen.

2.5.1 REST-konforme Architekturen

In REST-konformen Architekturen steht die Methodeninformation in der HTTP-Methode und die Fokusin-formation im Pfad der HTTP-Nachricht. Der Server kann anhand dieser Informationen entscheiden, welcheOperationen er ausfuhren soll. Zum Beispiel wurde ein GET auf den Pfad /information.xml bedeuten, dassdie Ressource information im Format xml abgerufen werden soll. Eine DELETE-Anfrage auf diesen Pfadwurde hingegen dem Server sagen, dass er die Ressource loschen soll [RR07].Beispielsweise ist die in Kapitel 2.4 vorgestellte ressourcenorientierte Architektur REST-konform.

2.5.2 Architekturen im RPC-Stil

Ist ein Webservice im RPC-Stil aufgebaut, so werden die Methodeninformation und die Fokusinformationin oder auf einen Umschlag wie XML-RPC oder SOAP geschrieben. Die Informationen sind nicht in demaufgerufenen URI ersichtlich. Meist gibt es fur den Webservice nur einen URI (den Endpunkt). An die-sem Endpunkt wird der Umschlag geoffnet und aus den darin enthaltenen Daten die Methoden- und dieFokusinformation abgeleitet [RR07].Der RPC-Stil zeichnet sich dadurch aus, dass, wie der Name Remote Procedure Call schon sagt, nicht aufRessourcen zugegriffen wird, sondern auf Prozeduren.

2.5.3 REST-RPC-Hybridarchitekturen

REST-RPC-Hybride sind Architekturen, die oftmals von ihren Anbietern als REST-konform bezeichnetwerden. In ihnen werden die Fokusinformationen, wie in REST-konformen Services, in der URI angegeben, dieMethodeninformationen hingegen werden im RPC-Stil ubermittelt. Statt die von HTTP gegebenen MethodenGET, POST, etc. als Entscheidungsmerkmal fur den Methodenaufruf zu verwenden, gibt es meist einenParameter (zum Beispiel method), in dem festgelegt wird, welche Methode aufgerufen wird [RR07].Als Beispiel sei das Abrufen von Videoinformationen bei Vimeo betrachtet:

http://vimeo.com/api/rest?api_key=xxx&method=vimeo.videos.getInfo&video_id=375747

Hier ist die Fokusinformation ”das Video mit der ID 375747“ und die Methodeninformation ”Ermittle VideoInformation!“. Damit sind sowohl Fokus-, als auch Methodeninformation in dem URI angegeben. Die HTTP-Methode wird aber nur bedingt genutzt. So wird dieser Aufruf mit HTTP-GET ausgefuhrt, genauso wie dasLoschen von Videos (vimeo.videos.delete).

2.6 Datenaustauschformate

In diesem Abschnitt sollen einige Datenaustauschformate behandelt werden, die von Web 2.0 APIs als Ein-oder Ausgabeformate verwendet werden. Es soll zunachst XML beschrieben werden, da es die Grundlage furdie meisten anderen Formate darstellt. Danach wird das JSON-Format vorgestellt. Dabei handelt es sich umeinen alternativen Ansatz in der Dateiauszeichnung. Es wurde entwickelt, um eine einfache Verarbeitung inder Sprache Javascript zu ermoglichen. Bei den darauffolgenden Formaten handelt es sich um die sogenannten

17

2 Grundlagen

Syndikationsformate RSS und Atom. Sie werden in erster Linie zum Datenabruf in Newsreadern verwendet,eignen sich aber auch zur maschinellen Verarbeitung.

2.6.1 XML

Die Extensible Markup Language (XML) ist eine Auszeichnungssprache, die es ermoglicht, Daten in hier-archisch strukturierter Form abzuspeichern. Es handelt sich bei XML um eine Teilmenge der StandardGeneralized Markup Language (SGML), auf der z.B. auch die Hypertext-Auszeichnungssprache HTML be-ruht. 1998 wurde XML eine Empfehlung des World Wide Web Consortiums (W3C) [BPSM98] und liegtaktuell in der Version 1.0 in der funften Edition vor [BPSM+08].Bei der Entwicklung von XML wurden unter anderem folgende Designziele verfolgt:

• XML soll einfach im Internet nutzbar sein.

• XML soll eine große Menge an Anwendungen unterstutzen.

• Programme, die XML-Dokumente verarbeiten, sollen einfach zu schreiben sein.

• Die Anzahl von optionalen Merkmalen in XML soll so niedrig wie moglich sein.

• XML-Dokumente sollen fur Menschen lesbar und verstandlich sein.

• Der Entwurf von XML soll formal und prazise sein.

• XML-Dokumente sollen leicht zu erstellen sein.

Ein Hauptmerkmal von XML ist es, im Gegensatz zu HTML, dass Struktur, Inhalt und Aussehen eines Do-kumentes unabhangig voneinander beschrieben werden konnen. Die Struktur wird dabei entweder in einerDocument Type Definition (DTD) [BBC+98] oder in einem XML-Schema [FW04] festgelegt. Bei einemXML-Schema handelt es sich wiederum um ein XML-Dokument, das das Schema eines anderen XML-Dokuments beschreibt. Das Aussehen eines XML-Dokuments kann, wie in HTML, durch ein CascadingStylesheet (CSS) [BCHL09] oder durch eine XSL Transformation (Extensible Stylesheet Language) [Kay07]festgelegt werden. Dabei handelt es sich bei dem XML-Dokument selbst nur um den Inhalt. Wie dieser Inhaltweiterverarbeitet wird, bestimmt die verarbeitende Anwendung.Ein XML-Dokument heißt wohlgeformt, wenn es syntaktisch korrekt ist, und gultig, wenn es semantischkorrekt ist, d.h. es passt zu einer Schemadefinition, die entweder als DTD oder XML-Schema vorliegt.

2.6.2 JSON

Die JavaScript Object Notation (JSON) ist definiert als ein leichtgewichtiges, textbasiertes, sprachunabhan-giges Datenaustauschformat [Cro06]. Sie basiert auf einer Untermenge der JavaScript Programmiersprache,wird heute aber von vielen anderen Programmiersprachen unterstutzt. Bei JSON-Dokumenten handelt essich um serialisierte Objekte [Wen07].Der wesentliche Vorteil von JSON gegenuber XML ist die einfache Verarbeitung. In JavaScript werden diegelesenen Daten als Objekte angenommen. In anderen Sprachen gibt es einfache Methoden, diese Datenals Arrays oder HashMaps abzulegen. Außerdem mussen weniger redundante Daten, wie zum Beispiel dieMarken in XML, ubertragen werden. Ein Nachteil ist hingegen, dass das Dokument fur den Menschen nichtso einfach lesbar ist, wie XML. Des Weiteren konnen keine Schema-Definitionen fur JSON-Dateien und somitauch keine Restriktionen festgelegt werden.Ein Beispiel soll die Unterschiede zwischen XML und JSON zeigen. Bei beiden Listings 2.5 und 2.6 handeltes sich um die gleichen Datenstrukturen.

18

2 Grundlagen

<?xml version="1.0" encoding="utf-8"?><person>

<firstname>John</firstname><lastname>Doe</lastname><nationality>american</nationality>

</person>

Listing 2.5: Beispiel: XML

{"person":

{"firstname":"John","lastname":"Doe","nationality":"american"}

}

Listing 2.6: Beispiel: JSON

2.6.3 RSS und Atom

RSS und Atom sind Formate zur Inhaltsyndizierung. Mit ihnen ist es moglich, auf einem standardisiertenWeg Inhalte, zum Beispiel von Internetseiten, zusammenzufassen.Ursprunglich wurde RSS dazu entwickelt, Portalseiten mit Nachrichten zu versorgen [Kan07]. Dabei hat RSSeine bewegte Vergangenheit hinter sich. Die Anfange machte Netscape 1999 mit der Veroffentlichung vonRSS 0.9. Damals stand RSS noch fur RDF Site Summary, da es sich als Anwendung des Resource DescriptionFramework (RDF) verstand. Netscape nutzte es, um Nachrichten zu beschreiben und diese dem Benutzerauf einer personalisierten Informationsseite von My Netscape zur Verfugung zu stellen [Joh06].Wenige Wochen nach der Veroffentlichung von Version 0.9 vereinfachte Netscape das Format, in dem es nichtmehr auf RDF, sondern von nun an in der Version 0.91 unter dem Namen Rich Site Summary auf einereinfacheren XML-Struktur beruhte.Dies fuhrte dazu, dass sich die Anhanger von RSS in zwei Lager aufspalteten. Das eine Lager kann alsSemantic Web Lager bezeichnet werden. Es wollte die Verwendung von RDF in RSS wieder vorantreiben.Das andere Lager wollte RSS durch die vollstandige Entfernung von RDF-Features einfacher machen.So brachte das Semantic Web Lager im Jahr 2000 die wieder auf RDF basierende Version 1.0 heraus. Indieser Version stand RSS nun wieder fur RDF Site Summary. Es wird haufig auch zur Unterscheidung alsRDF/RSS bezeichnet.Zwei Wochen nach der Veroffentlichung von Version 1.0 brachte das Einfachheitslager als Nachfolger konse-quenterweise die Version 0.92 heraus. Hier war RSS keine Abkurzung mehr.Im Jahr 2002 wurde schließlich RSS 2.0 vom Einfachheitslager freigegeben. Seitdem steht RSS fur ReallySimple Syndication. RSS 2.0 hat sich mittlerweile durchgesetzt, vor allem dadurch, dass Apple seine Podcastsauf Basis von RSS 2.0 entwickelt hat [App09].Bei dieser bewegten Vergangenheit ist klar, dass es sehr schwer fallt Parser zu entwickeln, die mit allen RSS-Versionen zurecht kommen. Die meisten Web 2.0 Dienste, die RSS-Feeds zur Verfugung stellen, verwendenmittlerweile die Version 2.0.Allerdings besitzt RSS einige Unzulanglichkeiten bezuglich der Spezifikation. So ist zum Beispiel nicht ein-deutig festgelegt, welchen Inhalt (XML, HTML, etc.) einige Elemente haben (durfen). Daher wurde 2005Atom, das die Nachfolge von RSS antreten will, vorgestellt.

19

2 Grundlagen

Zusammenfassend kann man sagen, dass heute drei wichtige Formate im Umlauf sind: RSS 1.0, RSS 2.0 undAtom. Zu diesen sollen nun kurz die Unterschiede herausgestellt werden. Dazu wird ein Beispiel-Feed in dendrei Formaten angegeben.

RSS 1.0

RSS 1.0 basiert, wie schon beschrieben, auf RDF. Aus diesem Grund kann die Struktur nicht in einemDurchlauf erstellt werden. Erst wird eine Ressource channel definiert, in der eine Liste von item-Ressourcenenthalten ist. Im Anschluss daran werden in einem erneuten Durchlauf die Informationen uber die einzelnenitem-Ressourcen festgelegt. Die description-Elemente durfen maximal 500 Zeichen reinen Text enthalten.HTML oder XML sind nicht erlaubt.Listing 2.7 zeigt einen Beispielfeed. Wie man sehen kann, handelt es sich um eine RDF-Struktur, in derStandardvokabulare, wie der Dublin Core [Boa08], verwendet werden. Diese Vokabulare legen Formate fest,wie zum Beispiel das Datumsformat von dc:date, das eine Notation nach ISO 8601 [WW98] vorsieht.

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDFxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://www.example.com/feed.rdf">

<title>Example Feed</title><link>http://www.example.com</link><description>This is an example feed.</description><dc:language>de-de</dc:language><dc:date>2009-04-14T12:35:17+01:00</dc:date>

<items><rdf:Seq>

<rdf:li rdf:resource="http://www.example.com/entry1.html" /><rdf:li rdf:resource="http://www.example.com/entry2.html" />

</rdf:Seq></items>

</channel>

<item rdf:about="http://www.example.com/entry1.html"><title>Feed Entry 1</title><link>http://www.example.com/entry1.html</link><description>This is the first example entry.</description><dc:date>2009-04-07T11:27:18+01:00</dc:date>

</item>

<item rdf:about="http://www.example.com/entry2.html"><title>Feed Entry 2</title><link>http://www.example.com/entry2.html</link><description>This is the second example entry.</description><dc:date>2009-04-03T18:54:01+01:00</dc:date>

</item>

</rdf:RDF>

Listing 2.7: Beispiel: RSS 1.0

20

2 Grundlagen

RSS 2.0

RSS 2.0 Feeds konnen, im Gegensatz zu RSS 1.0, in einem Durchlauf erstellt werden. Das description-Element der Items wird in RSS 2.0 meist mangels Alternativen missbrauchlich verwendet. Anstatt einerBeschreibung, wird in dieses Element meist eine Zusammenfassung des Artikels oder der gesamte Artikelselbst eingetragen. Hier ist nicht wirklich klar, ob HTML oder XML verwendet werden darf [Kan07].In Listing 2.8 ist ein RSS 2.0 Feed dargestellt. Das Element pubDate entspricht hier dem dc:date-Elementaus RSS 1.0. Als Datumsformat wird ein Format nach der RFC 822 [Cro82] verwendet, wobei aber eineAusnahme moglich ist, die es erlaubt, Jahreszahlen mit nur zwei Ziffern zu schreiben [Win03]


<rss version="2.0"><channel>

<title>Example Feed</title><link>http://www.example.com/</link><description>This is an example feed.</description><language>de-de</language><pubDate>Tue, 14 Apr 2009 10:00:00 +0100</pubDate><lastBuildDate>Tue, 14 Apr 2009 12:35:17 +0100</lastBuildDate><docs>http://blogs.law.harvard.edu/tech/rss</docs>

<managingEditor>[email protected] (John Doe)</managingEditor><ttl>300</ttl>

<item><title>Feed Entry 1</title><link>http://www.example.com/entry1.html</link><description>This is the first example entry.</description><pubDate>Tue, 07 Apr 2009 11:27:18 +0100</pubDate>

</item>

<item><title>Feed Entry 2</title><link>http://www.example.com/entry2.html</link><description>This is the second example entry.</description><pubDate>Fri, 03 Apr 2009 18:54:01 +0100</pubDate>

</item>

</channel></rss>

Listing 2.8: Beispiel: RSS 2.0

Atom

Die Entwickler von Atom kommen zum großen Teil aus der Blogger-Szene [Kan07]. Dadurch erklart sicheiner der großten Unterschiede zu den beiden anderen Formaten. In Atom gibt es kein Element description,sondern die zwei Elemente summary und content. Dabei ist summary fur eine Zusammenfassung und content furden Inhalt eines Beitrags gedacht. Fur das content-Element kann angegeben werden, welchem Content-Typeder Inhalt entspricht. So konnen auch HTML, XHTML oder XML-Elemente enthalten sein. Außerdem kannfur content ein URI festgelegt werden, der auf eine externe Binardatei weist. So konnen Podcasts realisiertwerden, wie in RSS 2.0 mit der iTunes-Erweiterung.Neben dem Syndikationsformat Atom, gibt es das Atom Publishing Protocol (AtomPub). Damit soll dasErstellen und Bearbeiten von Ressourcen ermoglicht werden. Dazu wird ein einzelnes entry-Element mitden Informationen zu der Ressource versehen und an den Service gesendet. Die Google Data API verwendet

21

2 Grundlagen

dieses Verfahren fur Anfragen.Das Beispiel in Listing 2.9 zeigt einen Atom-Feed. Wie man sehen kann, sind die Unterschiede zu RSS 2.0 sehrgering. Ein wesentlicher Unterschied zu RSS 2.0 liegt in der Spezifikation. So hat Atom eine eindeutige Sche-madefinition und ist im RFC 4287 standardisiert [NS05]. Das Datumsformat ist nach RFC 3339 [KCNS02]kodiert, was wiederum der Notation der ISO 8601 entspricht, die auch von RSS 1.0 verwendet wird.


<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de"><title>Example Feed</title><subtitle>This is an example feed.</subtitle><link href="http://www.example.com/feed.atom" rel="self"/><link href="http://www.example.com/"/><updated>2009-04-14T12:35:17+01:00</updated>

<author><name>John Doe</name><email>[email protected]</email>

</author><id>http://www.example.com/feed.atom</id>

<entry><title>Feed Entry 1</title><link href="http://www.example.com/entry1.html"/><id>http://www.example.com/entry1.html</id><updated>2009-04-07T11:27:18+01:00</updated><summary>This is the first example entry.</summary>

</entry>

<entry><title>Feed Entry 2</title><link href="http://www.example.com/entry2.html"/><id>http://www.example.com/entry2.html</id><updated>2009-04-03T18:54:01+01:00</updated><summary>This is the second example entry.</summary>

</entry>

</feed>

Listing 2.9: Beispiel: Atom

22

3 Autorisierung und Authentifizierung in Web 2.0 Services

3 Autorisierung und Authentifizierung in

Web 2.0 Services

Ein wichtiger Punkt bei der Betrachtung von APIs sind die Verfahren, mit denen ein Benutzer eine An-wendung autorisieren kann, Aktionen in seinem Namen bei einem Service auszufuhren und auf seine Datenzuzugreifen.Viele Web 2.0 Dienste bieten mehrere Verfahren an, die meist auf die verschiedenen Arten von Anwendun-gen (Desktop-, Web- und mobile Anwendungen) abzielen. Oftmals unterscheiden sich die Verfahren nur inwenigen Details. Daher sollen sie generalisiert und, falls nicht standardisiert vorhanden, mit einem Namenversehen werden. Damit kann spater in der konkreten Untersuchung der APIs in Kapitel 5 auf sie referen-ziert werden, so dass sie nicht bei jedem Dienst neu erortert werden mussen. Es kann zwischen Login- undToken-basierten Verfahren unterschieden werden, welche im Folgenden vorgestellt werden sollen.

3.1 Login-basierte Verfahren

Bei Login-basierten Verfahren autorisiert der Benutzer die Anwendung, indem er ihr Benutzername undPasswort mitteilt. Die Anwendung authentifiziert sich dann gegenuber dem Service, indem sie sich als derBenutzer ausgibt. Autorisierung und Authentifizierung geschehen somit in einem Schritt.Diese Vorgehensweise stellt fur Webanwendungen ein Sicherheitsrisiko dar. Die wenigsten Benutzer wollenihre vertraulichen Daten auf einem Webserver speichern. Bei Desktopanwendungen, die auf dem eigenenRechner ausgefuhrt werden, wird dies von den meisten Nutzern wahrscheinlich als weniger kritisch angesehen.Die Ubertragung der Benutzerdaten geschieht bei den Services auf unterschiedliche Weise. Die ublichsteForm ist die in HTTP vorgesehene HTTP Basic Authentication [FGM+99]. Dabei werden die Daten imAuthorization-Header des HTTP-Requests ubermittelt. Das Passwort wird Base64 encodiert, um eventuelleSonderzeichen zu maskieren. Dies stellt aber keine Verschlusselung dar. Der Vorteil der HTTP Basic Au-thentication liegt in der Einfachheit der Generierung des Headers. Um einen solchen Header zu erzeugen,kann die Anfrage einfach an eine URL in der folgenden Form gerichtet werden:

http://[Benutzername]:[Passwort]@[URI des Service]

Manche Services sehen aber auch vor, dass die Benutzerdaten als Parameter im Entity-Body der HTTP-Abfrage ubertragen werden.

Abbildung 3.1: Autorisierung nach einem Login-basierten Verfahren

23


3.2 Token-basierte Verfahren

Bei Token-basierten Verfahren autorisiert der Benutzer eine Anwendung, seinen Account beim Service zuverwenden. Dabei erhalt die Anwendung vom Service ein Token, das sie in den meisten Fallen speichernkann. Mit diesem Token kann sie sich dann authentifizieren.Der entscheidende Vorteil bei diesem Verfahren ist, dass die Anwendung keinerlei Benutzerdaten, bis auf dasToken, kennen muss. Im Folgenden werden nun einige Verfahren vorgestellt, die sich nur in wenigen, aberdoch wichtigen, Details unterscheiden.

3.2.1 Sequential-Token-Request

Dieses Verfahren wird vor allem dazu verwendet, eine Autorisierung von Webanwendungen durchzufuhren.Es zeichnet sich dadurch aus, dass der Benutzer auf einen Link zum Service klickt, die Anwendung autorisiertund so einen Tokenaustausch in Gang setzt.Der Ablauf dieses Verfahrens sieht folgendermaßen aus:

1. Der Benutzer erhalt einen Link zur Authentifizierungsschnittstelle des Services.

2. Wenn der Benutzer diesem Link folgt, wird er aufgefordert, sich gegenuber dem Service zu authentifi-zieren und schließlich die Anwendung zu autorisieren.

3. Hat der Benutzer die Anwendung autorisiert, leitet der Service den Browser des Benutzers auf einefestgelegte Callback-URL der Anwendung um, an die ein RequestToken angehangt wird.

4. Die Anwendung kann nun das RequestToken aus den Parametern des Aufrufs auslesen und anhanddessen ein AccessToken abrufen.

5. Das so gewonnene Token bindet den Benutzer an den API-Schlussel der Anwendung.

Abbildung 3.2: Autorisierung nach dem Sequential-Token-Request-Verfahren

Mit diesem Token konnen nun Operationen im Namen des Benutzers durchgefuhrt werden. Manche Serviceserlauben es, das Token zu speichern. Es ist dann so lange gultig, bis die Autorisierung vom Benutzer widerru-fen wird. Andere Services geben mit dem Token ein Ablaufdatum an, nach dessen Ablauf die Autorisierungerneut durchgefuhrt werden muss.Da es sich bei diesem Verfahren um einen fortlaufenden Prozess handelt, bei dem ein Token abgefragt wird,wird es im Folgenden als Sequential-Token-Request-Verfahren bezeichnet.

3.2.2 Interrupted-Token-Request

Dieses Verfahren ist fur Desktopanwendungen vorgesehen. Der Ablauf ist dem in Abschnitt 3.2.1 beschriebe-nen sehr ahnlich. Allerdings muss die Anwendung ihre Ausfuhrung unterbrechen, bis der Benutzer von sichaus angibt, dass er die Anwendung autorisiert hat.

24


Mit dem folgenden Schritten lasst sich dieses Verfahren realisieren:

1. Die Anwendung ruft vom Service ein RequestToken ab.

2. Daraufhin offnet die Anwendung ein Browserfenster, in dem eine URL zur Authentifizierungsschnitt-stelle des Services aufgerufen wird. An diese URL wird das RequestToken angehangt.

3. An dieser Stelle kann sich der Benutzer nun gegenuber dem Service authentifizieren und die Anwendungautorisieren.

4. Sobald der Benutzer der Anwendung mitgeteilt hat, dass er sie autorisiert hat, kann diese mit derAusfuhrung fortfahren und vom Service ein AccessToken abrufen.


Abbildung 3.3: Autorisierung nach dem Interrupted-Token-Request-Verfahren

Mit diesem Token konnen nun Operationen im Namen des Benutzers ausgefuhrt werden. Auch bei diesemVerfahren unterscheiden die Services zwischen begrenzter und unbegrenzter Gultigkeit.Da hier der Prozess zur Abfrage des Tokens unterbrochen und auf eine Benutzerinteraktion gewartet wird,wird das Verfahren im Folgenden als Interrupted-Token-Request bezeichnet.

3.2.3 Login-Token-Exchange

Bei diesem Verfahren gibt der Nutzer seinen Benutzernamen und sein Passwort einmalig in der Anwendungan. Diese Daten werden dann beim Service gegen ein AccessToken ausgetauscht. Mit diesem AccessTokenkonnen Anfragen im Namen des Benutzers ausgefuhrt werden. Das Verfahren zahlt daher nicht zu denLogin-basierten Verfahren, bei denen die Benutzerdaten bei jeder Anfrage mit ubertragen werden mussen.Da hier Zugangsdaten versendet werden und ein Token als Antwort zuruck kommt, wird dieses Verfahren imFolgenden als Login-Token-Exchange bezeichnet.

Abbildung 3.4: Autorisierung nach dem Login-Token-Exchange-Verfahren

25


3.2.4 Manual-Token-Input

Dieses Verfahren eignet sich vor allem fur Anwendungen auf mobilen Geraten.Es funktioniert folgendermaßen:

1. Der Benutzer erhalt einen Link zur Authentifizierungsschnittstelle des Services. Dieser Link ist furalle Nutzer der Anwendung gleich und kann zum Beispiel auf der Download-Seite zur Anwendung zurVerfugung gestellt werden.

2. Folgt der Benutzer dem Link, muss er sich authentifizieren und die Anwendung autorisieren.

3. Als Ergebnis der Autorisierung erhalt der Benutzer ein MiniToken, das aus einer kurzen Zeichenfolgebesteht.

4. Die Anwendung stellt dem Benutzer ein Eingabefeld zur Verfugung, in das das MiniToken eingegebenwerden muss.

5. Damit kann die Anwendung nun ein AccessToken abrufen.


Mit dem AccessToken konnen nun Operationen im Namen des Benutzers ausgefuhrt werden.Das Verfahren zeichnet sich dadurch aus, dass der Prozess getrennt auf verschiedenen Geraten durchgefuhrtwerden kann. So kann zum Beispiel die Autorisierung am PC oder Mac und die Eingabe des Mini-Tokensvon Hand auf einem Mobiltelefon stattfinden. Daher wird dieses Verfahren im Folgenden als Manual-Token-Input-Verfahren bezeichnet.

Abbildung 3.5: Autorisierung nach dem Manual-Token-Input-Verfahren

3.2.5 OAuth

Als Letztes soll nun, nach den bereits vorgestellten proprietaren Verfahren, ein standardisiertes Verfahrenvorgestellt werden, das von immer mehr Services implementiert wird. OAuth ist ein offenes Protokoll fureine sichere Authentifizierung und Autorisierung von Webanwendungen [OAu07].Der Ablauf einer solchen Autorisierung sieht folgendermaßen aus:

1. Die Anwendung stellt eine Anfrage an die Authentifizierungsschnittstelle und erhalt als Ruckgabe einRequestToken (vgl. Schritt A in Abbildung 3.6).

2. Unter Angabe dieses RequestTokens wird der Browser des Benutzers zum Service geleitet, wo er sichauthentifizieren und die Anwendung autorisieren muss.

26


3. Hat der Benutzer die Anwendung autorisiert, wird das RequestToken zu einem autorisierten Token, wo-bei der Tokenwert gleich bleibt (Abb. 3.6 Schritt C). Der Browser des Benutzers wird, falls angegeben,auf eine Callback-URL der Anwendung zuruckgeleitet.

4. Das autorisierte Token kann nun durch ein AccessToken ersetzt werden (siehe Abbildung 3.6 Schritt Eund F).

Mit dem so gewonnenen AccessToken konnen Operationen im Namen des Benutzers ausgefuhrt werden.

Abbildung 3.6: OAuth Authentifizierungsablauf (aus [OAu07])

Dienste, die das OAuth-Protokoll implementieren, werden Service Provider genannt. Anwendungen, die aufdiese Service Provider zugreifen, werden als Consumer bezeichnet. Dieser Consumer erhalt dann einen Con-sumer Key und ein Consumer Secret, was dem API Key bzw. dem API Secret einiger proprietarer Verfahrenentspricht.Die Ubertragung der Authentifizierungsparameter kann in OAuth auf drei verschiedene Arten geschehen.Diese konnen, wie bei der HTTP Basic Authentication, im Authorization Header des HTTP Requests an-gegeben, an der Query String der URL angehangt oder bei POST-Requests dem Entity-Body hinzugefugtwerden.OAuth bietet in der Version 1.0 einen großen Nachteil fur die Ubertragung von Binardaten. So konnenPOST-Anfragen nur mit dem Content-Type application/x-www-form-urlencoded ubertragen werden. SollenDateien ubertragen werden, ist dies nur uber einen Umweg moglich, bei dem Dateiname, Dateigroße undMIME-Type gesondert als einzelne Parameter mit ubertragen werden.

27


3.3 Vergleich / Diskussion

In diesem Kapitel wurden die verschiedenen Arten von Autorisierungsverfahren vorgestellt. Zusammenfas-send waren dies:

• Login-basierte Verfahren,

• Interrupted-Token-Request,

• Sequential-Token-Request,

• Login-Token-Exchange,

• Manual-Token-Input und

• OAuth.

Diese Verfahren sollen nun abgeglichen werden, so dass nur noch die Best Practices fur die speziellen Anwen-dungsfalle ubrig bleiben. Die Login-basierten Verfahren sollen dabei ausgenommen werden, da diese, wie imAbschnitt 3.1 beschrieben, keine dauerhaft gute Vorgehensweise sind. Benutzer wollen ihre Benutzerdatennicht an Drittanbieter weitergeben und moglicherweise auf Servern speichern.Genauso hat das Login-Token-Exchange-Verfahren einen Sonderstatus, da es beim Benutzer durch die Not-wendigkeit der Eingabe seiner Daten unnotige Unsicherheit verursacht.Fur mobile Anwendungen auf alteren Geraten stellt das Manual-Token-Input-Verfahren sicherlich die besteWahl dar. Es wird aber wahrscheinlich durch die vermehrte Beliebtheit neuerer Gerate, wie zum Beispieldem Apple iPhone, bald ausgedient haben, da diese Gerate uber vollwertige Webbrowser verfugen.Ubrig bleiben somit noch das Interrupted-Token-Request-, das Sequential-Token-Request- und das OAuth-Verfahren. Wie bereits beschrieben, sind sich diese Verfahren sehr ahnlich. Der Sequential-Token-Requestunterscheidet sich vom Interrupted-Token-Request nur in der Reihenfolge des Ablaufs. Wird im Interrupted-Token-Request die Moglichkeit gegeben, beim Aufrufen der Autorisierungsseite eine Callback-URL mitzu-geben, an die der Browser des Benutzers nach der Autorisierung umgeleitet wird, so ware der Nachteil derUnterbrechung aufgehoben und das Verfahren auch fur Webanwendungen geeignet.Somit fallt Sequential-Token-Request bei dieser Betrachtung heraus. Es bleiben:

• Interrupted-Token-Request, mit der Option eine Callback-URL anzugeben, und

• OAuth.

Bei genauer Betrachtung dieser beiden Verfahren stellt man fest, dass sie beide den gleichen Ablauf ha-ben. Da OAuth ein standardisiertes Verfahren ist, konnte man nun sagen, dass es Best Practice ware.Leider unterstutzt die Spezifikation von OAuth keine multipart/form-data-kodierten HTTP-Entity-Bodys,was die Ubertragung von Binardaten nur uber umstandliche Workarounds moglich macht. Entity-Bodys,diemultipart/form-data-kodiert sind, bestehen aus mehreren Teilen, welche den zu ubertragenen Parameternentsprechen. Dabei kann jeder Teil einen eigenen Content-Type haben. Sollen Dateien ubertragen werden,konnen zusatzlich Dateiname und Dateigroße angegeben werden.Damit stellt die aktuelle Best Practice ein Verfahren dar, das wie OAuth funktioniert, aber multipart/form

-data-kodierte Nachrichten unterstutzt und, sobald die OAuth Spezifikation dieses vorsieht, durch diesesleicht ersetzt werden kann.

28

4 Konzeptionelles Framework


In diesem Kapitel soll ein konzeptionelles Framework fur Web 2.0 Dienste aufgestellt werden. Zu diesemFramework gehoren die Bereiche API, Feed-Interface, Autorisierung durch den Benutzer und Datenzugriff.Es ermoglicht eine Einordnung und Charakterisierung von Web 2.0 Diensten und ihren APIs.Bei ProgrammableWeb.com wird bereits eine Charakterisierung von APIs durchgefuhrt [Pro09]. Das hiervorgestellte konzeptionelle Framework geht aber daruber hinaus und bietet tiefere Informationen uber dieverwendeten Verfahren und Architektur-Stile.Im folgenden Kapitel wird es dann auf die jeweiligen Services angewandt. Nun sollen zunachst die einzelnenBereiche aufgeschlusselt werden. Abbildung 4.1 zeigt eine Ubersicht uber die Bereiche und Attribute desFrameworks. Im Anhang A befindet sich ein Bewertungsbogen, mit dem die Charakterisierung eines Web 2.0Dienstes in Checklisten-Form durchgefuhrt werden kann.

Abbildung 4.1: Ubersicht uber das konzeptionelle Framework

API

Dieser Bereich befasst sich mit den Eigenschaften der APIs, die durch die Web 2.0 Dienste zur Verfugunggestellt werden.

• Stand: Der Stand gibt die Version bzw. den Zeitpunkt der API-Analyse an.

• Architektur-Stil: Hier wird der Architektur-Stil aus Abschnitt 2.5 (REST-konform, RPC, REST-RPC-Hybrid) aufgefuhrt.

29


• Methodeninformation: In diesem Attribut wird vermerkt, auf welche Art die Methodeninformationubertragen wird (z.B. im URI, als Anfrageparameter oder als HTTP-Methode).

• Technologie: Dieser Attribut gibt an, welche Mechanismen fur die Anfragestellung verwendet werdenkonnen. REST-ahnlich gibt dabei an, dass die Anfrage uber einfache HTTP-Methoden, z.B. GET oderPOST, geschehen kann und kein Umschlagformat, wie zum Beispiel SOAP oder XML-RPC, eingesetztwird. Dies muss aber nicht unbedingt heißen, dass die Methoden auch korrekt im Sinne von RESTverwendet werden. Die Bezeichnung grundet sich darauf, dass die meisten Services es so nennen.

• Antwortformate: Dies sind Dateiformate, die als Antwort vom Service zuruckgeliefert werden. Ubli-che Werte sind hier zum Beispiel die in Abschnitt 2.6 vorgestellten XML, JSON, RSS oder Atom.

• Anwendungsauthentifizierung: Hier werden die Parameter aufgefuhrt, mittels derer sich die An-wendung gegenuber dem Service authentifiziert. Einige Services schreiben eine Authentifizierung vor,um die Anwendung, zum Beispiel bei hoher Verursachung von Traffic, sperren zu konnen.

• mehrere Anwendungen moglich: Diese Eigenschaft gibt an, ob zu einem Entwickler- bzw. Benut-zeraccount mehrere API-Schlussel angelegt werden konnen. So bieten einige Services nur die Moglich-keit, einen Schlussel pro Account anzulegen, wodurch fur jede weitere Anwendung ein neuer Benut-zeraccount angelegt werden musste.

• offiziell unterstutzte Bibliotheken: Dies ist eine Aufzahlung von Programmiersprachen, fur dieBibliotheken offiziell vom Service zur Verfugung gestellt bzw. empfohlen werden. Durch die Vielzahlvon Programmiersprachen ist es an dieser Stelle nicht moglich, alle Bibliotheken aufzuzahlen, die vonDrittanbietern angeboten werden. Der Vorteil von offiziell unterstutzten Bibliotheken ist, dass bei diesenmeist direkt auf Anderungen der API reagiert wird, wobei es bei inoffiziellen Bibliotheken haufiger zurVeraltung und Projektaufgabe kommt.

Feed-Interface

Viele Web 2.0 Dienste bieten Feed-Interfaces an, uber die Feeds fur Feed-Reader abonniert werden konnen.

• Stand: Wie auch schon im Abschnitt API, wird hier angegeben, zu welchem Stand bzw. zu welcherVersion die Analyse des Feed-Interfaces durchgefuhrt worden ist.

• Antwortformate: Dieses Attribut gibt an, welche Formate die Antworten haben. Mogliche Wertesind hier zum Beispiel RSS, Atom oder RDF.

• abrufbare Daten: An dieser Stelle wird angegeben, auf welche Daten uber das Feed-Interface zuge-griffen werden kann.

• Zugriff auf private Daten: Einige Services bieten die Moglichkeit, uber das Feed-Interface auf privateDaten zuzugreifen. Dazu muss dann eine Authentifizierung durchgefuhrt werden, die im nachsten Punktbeschrieben wird.

• Authentifizierung: Falls Zugriff auf private Daten gewahrt wird, wird hier angegeben, wie die Au-thentifizierung durchgefuhrt wird und welche Parameter dafur benotigt werden.

Autorisierung durch den Benutzer

In Kapitel 3 wurden verschiedene Verfahren vorgestellt, mit denen ein Benutzer eine Anwendung autorisierenkann. In diesem Bereich wird angegeben, welche Verfahren durch die Web 2.0 Dienste angeboten und wiediese realisiert werden.

30


• Art des Verfahrens: In Kapitel 3 wurden zwei Gruppen von Autorisierungsverfahren vorgestellt. DieArt des Verfahrens ist damit entweder Login- oder Token-basiert.

• Verfahren: Hier wird angegeben, welche Autorisierungsverfahren aus Kapitel 3 von dem Service an-geboten werden.

• Parameter: Bei diesem Attribut werden die Parameter aufgezahlt, die fur die Autorisierung undAuthentifizierung vom Nutzer benotigt werden.

• Token speicherbar: Diese Eigenschaft gibt an, ob im Fall einer Token-basierten Authentifizierung dasToken gespeichert werden kann oder ob der Autorisierungprozess bei jeder Session erneut durchlaufenwerden muss.

• Callback-URL dynamisch wahlbar: Viele Services verlangen, dass die Callback-URL, zu der derBenutzer nach der Autorisierung zuruckgeleitet wird, zusammen mit dem API-Schlussel festgelegtwird. Damit ist es nicht moglich, dynamisch zu entscheiden, zu welchem Punkt in der Anwendung derBenutzer zuruckgeschickt wird.

Datenzugriff

Der Bereich Datenzugriff befasst sich mit den abrufbaren Daten sowie der Suche und dem Upload vonRessourcen bei einer API eines Web 2.0 Dienstes.

• Hauptmedientyp: Der Hauptmedientyp ist der Typ der Ressourcen, die vom Service zur Verfugunggestellt werden (z.B. Fotos, Videos, etc.).

• abrufbare Daten: An dieser Stelle werden die anderen Daten und Informationen aufgezahlt, auf dieneben dem Hauptmedientyp zugegriffen werden kann.

• Zugriffsbeschrankung: Benutzer konnen meist den Zugriff auf ihre Ressourcen beschranken. DieserPunkt gibt an, welche Einstellungen sie dazu vornehmen konnen.

• Filter bei der Suche: Hier wird eine Aufzahlung von Filterparametern aufgestellt, mit denen dieSuche nach dem Hauptmedientyp beschrankt werden kann. Meistens wird durch die API eine nativeMethode zur Suche bereitgestellt, bei der eine Filterung feingranular eingestellt werden kann.

• Argumente fur den Upload: Dieses Attribut gibt an, welche Eigenschaften des zu ubertragendenObjektes beim Upload bestimmt werden konnen.

31

5 API-Analyse

5 API-Analyse

In diesem Kapitel soll nun eine Analyse der APIs einiger aktuell großen und gangigen Social Media-Dienstefur die verschiedenen Medientypen (z.B. Photo, Video, Audio, Text, Slideshows etc.) durchgefuhrt werden.Dazu werden die einzelnen Dienste erst kurz beschrieben und dann wird auf der Grundlage des in Kapitel 4vorgestellten konzeptionellen Frameworks auf die Eigenschaften der jeweiligen APIs eingegangen.

5.1 Flickr

Flickr ist ein Web 2.0 Dienst von Yahoo!, in dem die Nutzer ihre Fotos speichern konnen, um sie so anderenBenutzern zur Verfugung zu stellen. Grundsatzlich ist die Mitgliedschaft bei Flickr kostenlos. Allerdingswerden die kostenlosen Accounts beschrankt, so dass hochstens 100 MB pro Kalendermonat hochgeladenwerden konnen. Des Weiteren ist die maximale Foto-Dateigroße auf 10 MB und die Anzahl der Video-Uploadsauf zwei Uploads pro Monat begrenzt. Diese Beschrankungen lassen sich durch eine kostenpflichtige ”Pro“-Mitgliedschaft aufheben. Hier sei von normalen Nutzern mit der kostenlosen Variante ausgegangen. Deswegenbleiben die Videos in dieser Untersuchung außen vor, da die Videofunktion durch die Einschrankung auf zweiVideos pro Monat praktisch nicht nutzbar ist.Hat sich der Benutzer registriert, kann er nach Personen suchen, die sich bereits bei Flickr angemeldet haben,und diese zu seinen Kontakten hinzufugen. Bei diesen Kontakten wird nach Freunden und Familienmitglie-dern unterschieden.Nachdem der Nutzer Fotos hochgeladen hat, konnen diese mit Tags und Geoinformationen versehen werden.

API

Voraussetzung fur die Nutzung der von Flickr zur Verfugung gestellten API sind ein API-Schlussel und eingemeinsamer geheimer Schlussel, die man sich auf der Webseite von Flickr Services anlegen kann [Fli09].Flickr ist einer der wenigen Anbieter, die noch einen Zugriff mittels SOAP und XML-RPC erlauben.

• Stand: 11.12.2008

• Architektur-Stil: REST-RPC-Hybrid und RPC (bei XML-RPC/SOAP als Technologie)

• Methodeninformation: Anfrageparameter

• Technologie: REST-ahnlich, SOAP, XML-RPC

• Antwortformate:

– proprietares XML– XML-RPC– SOAP– JSON– serialisierte PHP Objekte

32

5 API-Analyse

• Anwendungsauthentifizierung: API-Key, Shared-Secret

• mehrere Anwendungen moglich: ja

• offiziell unterstutzte Bibliotheken:

– C– Objective-C– Java– .NET– PHP– Ruby– Python

Feed-Interface

Das Feed-Interface von Flickr bietet zum Beispiel die Moglichkeit, die Photostreams von Nutzern zu abon-nieren. Dazu stellt es neben den ublichen Formaten RSS und Atom fur Feedreader auch eine große Auswahlan Formaten fur die maschinelle Weiterverarbeitung zur Verfugung.

• Stand: 11.12.2008

• Antwortformate:

– RSS– Atom– serialisierte PHP Objekte– SQL– JSON– yaml– CSV

• abrufbare Daten: Fotos, Favoriten, Kommentare

• Zugriff auf private Daten: nein

• Authentifizierung: -


Flickr bietet die Moglichkeit, die Autorisierung durch den Benutzer nach einem Sequential-Token-Request-,einem Interrupted-Token-Request- oder einem Manual-Token-Input-Verfahren durchzufuhren.Bei allen Autorisierungsverfahren wird ein Token zuruckgeliefert, das unbegrenzt gultig ist, solange derBenutzer die Autorisierung nicht auf den Seiten von Flickr zuruckzieht. Daher sollte das Token in derAnwendung gespeichert werden. Innerhalb der Anwendung kann das Token dann mittels der API-Methodeflickr.auth.checkToken auf seine Gultigkeit gepruft werden.

33

5 API-Analyse

• Art des Verfahrens: Token-basiert

• Verfahren:

– Sequential-Token-Request– Interrupted-Token-Request– Manual-Token-Input

• Parameter: Token

• Token speicherbar: ja

• Callback-URL dynamisch wahlbar: nein

Datenzugriff

Der Hauptmedientyp von Flickr sind Fotos. Bei diesen gibt es vier Moglichkeiten, wie der Nutzer den Zugriffbeschranken kann. So konnen sie fur niemanden, nur fur Freunde, nur fur Familienmitglieder, nur fur Freundeund Familienmitglieder oder offentlich freigegeben werden.Zur Suche von Fotos stellt Flickr die Methode flickr.photos.search zur Verfugung. Die Suche kann durchviele optionale Parameter feingranular beschrankt werden. Solange nicht nach Fotos, die als privat markiertsind, gesucht wird, kann die Suchoperation ohne jegliche Authentifizierung durchgefuhrt werden.Der Upload von Fotos kann sowohl synchron als auch asynchron geschehen. Wird ein Foto synchron ubertra-gen, wird der Ablauf der Anwendung solange unterbrochen, bis das Foto auf dem Server von Flickr vollstandigeingegangen ist. Als Ruckgabewert erhalt man dann die ID des Fotos.Bei einem asynchronen Upload wird eine Ticket-ID zuruckgegeben. Die Anwendung kann daraufhin wiegewohnt weiterarbeiten. Mittels der API-Methode flickr.photos.upload.checkTickets kann dann der Statusdes Fotos abgefragt werden. Ist das Foto vollstandig eingegangen, gibt diese Methode zusatzlich die Foto-IDzuruck.

• Hauptmedientyp: Fotos

• abrufbare Daten:

– Kommentare / Notes– Tags– Kontakte– Favoriten– Benutzerinformationen– Personen– Gruppen

• Zugriffsbeschrankung:

– Familienmitglieder– Freunde– Freunde & Familienmitglieder– Privat– Offentlich

34

5 API-Analyse

• Filter bei der Suche:

– Benutzer-ID– Tags– Text– Gruppen-ID– Sortierung– fruhestes bzw. spatestes Uploaddatum– Privatsphareeinstellungen– Anzahl der zuruckgelieferten Elemente

• Argumente fur den Upload:

– Titel– Beschreibung– Tags– Privatsphareeinstellungen (offentlich, fur Freunde, fur Familie, privat)

5.2 YouTube

YouTube ist die Videoplattform von Google. Benutzer konnen Videos anschauen, bewerten und kommentie-ren. Ein Hauptmerkmal von YouTube ist außerdem der Upload von eigenen Videos. Heute konnen bereitseine Vielzahl digitaler Camcorder ihre Videos direkt im YouTube-Formfaktor aufnehmen, so dass sie nachder Aufnahme ohne weitere Konvertierungen zu YouTube hochgeladen werden konnen.

API

Die YouTube Data API ist Teil der Google Data API [Goo09b]. Die Anwendungsauthentifizierung geschiehtuber einen Developer-Key und eine Client-ID, die der Entwickler bei YouTube beantragen kann. Als Ruckgabeauf API-Requests liefert YouTube Atom-Feeds, daher wird hier auf die Unterscheidung zwischen API unddem Feed-Interface verzichtet. Die API liegt aktuell in der Version 2.0 vor.

• Stand: 08.04.2009 / v2.0

• Architektur-Stil: REST-konform

• Methodeninformation: HTTP-Methode

• Technologie: REST-ahnlich

• Antwortformate: Atom, RSS, JSON

• Anwendungsauthentifizierung: Developer-Key, Client-ID



– Java– .NET

35

5 API-Analyse

– PHP– Python– Objective-C


Die Google Data API sieht fur YouTube vier mogliche Verfahren fur die Benutzer-Authentifizierung vor.Ein Sequential-Token-Request-Verfahren (von Google AuthSub genannt) und das OAuth-Verfahren sind furWebanwendungen und ein Login-Token-Exchange-Verfahren (ClientLogin genannt) fur Desktopanwendungenvorgesehen. Zusatzlich bietet YouTube eine Authentifizierung speziell fur Flash-Anwendungen, welche hieraber nicht naher betrachtet werden soll. Auch wenn bei manchen Verfahren zum Token ein Ablaufdatumzuruckgeliefert wird, wird dieses von der Google Data API im Moment nicht verwendet. Das Token kannalso abgespeichert werden.


• Verfahren:

– Sequential-Token-Request– OAuth– Login-Token-Exchange

• Parameter: Token bzw. beim Login-Token-Exchange zusatzlich Benutzername und Passwort


• Callback-URL dynamisch wahlbar: ja

Datenzugriff

Mit der YouTube Data API kann die Anwendung alle wichtigen Informationen uber Videos, Kommentare,Benutzer und Kontakte abrufen. Benutzer konnen dabei den Zugriff auf ihre Videos so beschranken, dasssie entweder offentlich oder privat sind. Bei privaten Videos konnen bis zu 25 Benutzer angegeben werden,die dieses Video betrachten durfen. Diese Benutzer mussen dabei in der Kontaktliste des veroffentlichendenBenutzers stehen.Die Suche von Videos bei YouTube gestaltet sich relativ unflexibel. Man kann lediglich Suchbegriffe bestim-men, die dann auf die kompletten Metadaten der Videos angewendet werden. Es gibt keine Moglichkeit zuunterscheiden, ob im Titel, der Beschreibung, den Tags (Keywords) oder etwa im Autorennamen gesuchtwerden soll.YouTube sieht zwei Arten des Videouploads vor. Eine Moglichkeit ist das Browser-based Uploading, bei demdie Anwendung dem Benutzer ein Formular zur Verfugung stellt, welches dann direkt an YouTube gesendetwird. Die andere Moglichkeit ist das sogenannte Direct Uploading. Hierbei sendet der Benutzer das Video andie Anwendung (mittels Formular oder Dateiauswahl). Die Anwendung reicht das Video dann an YouTubeweiter. Die Anwendung fungiert also sozusagen als Proxy, in dem das Video zum Beispiel abgespeichert odereventuell verandert werden kann.In beiden Fallen wird das Video auf dem Server von YouTube in das fur die Wiedergabe benotigte Flash-Format umgewandelt, was einige Zeit in Anspruch nehmen kann.

36

5 API-Analyse

• Hauptmedientyp: Videos


– Kommentare– Favoriten– Playlists– Benutzerinformationen– Kontakte


– offentlich– privat (fur max. 25 Kontakte)


– Suchbegriff– Benutzername– Kategorie– Anzahl der zuruckgelieferten Elemente– Ort– Sortierung


– Titel– Beschreibung– Kategorie– Tags

5.3 Delicious

Delicious ist ein Dienst von Yahoo! zum Speichern von Web-Bookmarks. Die Bookmarks werden im Profil desangemeldeten Benutzers abgelegt. Wichtigstes Feature ist dabei, dass diese Bookmarks mit Tags versehenwerden konnen. So kann man sowohl aus seinen eigenen als auch aus den Bookmarks anderer Benutzer ubereine Tagsuche alle Bookmarks finden, die mit den jeweiligen Tags versehen sind.Außerdem kann man sehen, wie oft eine URL von anderen Benutzern als Bookmark angelegt worden ist undso die Relevanz fur das betreffende Thema ableiten. Aus den Tags konnen sogenannte Tag Bundles gebildetwerden, in denen mehrere zueinander passende Tags zusammengefasst werden.

API

Die API von Delicious ist sehr einfach aufgebaut [Del09]. So werden alle Anfragen mittels der HTTP-GET-Methode gestellt. Es wird dafur kein API-Schlussel oder ahnliches benotigt.Sie bietet Zugriff auf alle Bookmarks (Posts) des authentifizierten Benutzers. Diese konnen abgerufen, ge-loscht und neu hinzugefugt werden. Außerdem konnen Tags abgerufen, geloscht, umbenannt oder in TagBundles zusammengefasst werden.

37

5 API-Analyse

• Stand: 11.12.2008

• Architektur-Stil: REST-RPC-Hybrid

• Methodeninformation: URI


• Antwortformate: proprietares XML

• Anwendungsauthentifizierung: keine Authentifizierung notig

• mehrere Anwendungen moglich: -

• offiziell unterstutzte Bibliotheken: -

Feed-Interface

Delicious bietet eine ganze Reihe vordefinierter Feeds. Darunter sind Feeds mit den neuesten und beliebtestenBookmarks. Außerdem konnen die Bookmarks und Kontakte einzelner Benutzer abgerufen werden. Fur denAbruf von privaten Daten gibt es die Moglichkeit, an die Feedanfrage einen privaten Schlussel anzuhangen.Dieser ist allerdings fur den normalen Benutzer auf den Internetseiten von Delicious kaum auffindbar.

• Stand: 11.12.2008

• Antwortformate:

– RSS– JSON


– Kontakte– Tags

• Zugriff auf private Daten: ja

• Authentifizierung: HTTP Basic Authentication mit Benutzername und privatem Schlussel


Die Authentifizierung von Delicious ist eine weniger ausgefeilte Prozedur, als zum Beispiel bei Flickr. DieAuthentifizierung geschieht lediglich Login-basiert uber eine HTTP Basic Authentication (siehe Abschnitt3.1). Die Ubertragung geschieht zwar uber HTTPS, der Benutzer muss aber seinen Benutzernamen und seinPasswort der Anwendung im Klartext zur Verfugung stellen. Dies ist ein Sicherheitsrisiko und wird wahr-scheinlich von den meisten Nutzern - zumindest im Fall von Webanwendungen - auch als solches aufgefasst.

• Art des Verfahrens: Login-basiert

• Verfahren: HTTP Basic Authentication (mit HTTPs)

38

5 API-Analyse

• Parameter: Benutzername, Passwort

• Token speicherbar: -

• Callback-URL dynamisch wahlbar: -

Datenzugriff

Uber die API bietet Delicious Zugang zu Bookmarks, Tags und Tag Bundles. Auf Kontakte eines Benutzerskann man allerdings in der vorliegenden Version nur uber das Feed-Interface zugreifen. Delicious unterschei-det zwar zwischen offentlichen und privaten Bookmarks, diese Unterscheidung ist aber nicht in die APIeingegangen. So konnen nur alle Bookmarks abgerufen werden.Die Suche von Bookmarks gestaltet sich bei Delicious sehr schwierig. Die API ist aktuell sehr unausgereift.So kann eine Suche nur auf die Tags der Bookmarks angewandt werden. Generell wird nur in den Bookmarksdes aufrufenden Benutzers gesucht. Außerdem kann mit der API-Methode posts/get zwar eine beliebigeAnzahl an Tags angegeben werden, aber kein Zeitraum, in dem die Bookmarks erstellt worden sind.Mit der API-Methode posts/all kann zwar ein Zeitraum angegeben werden, aber nur ein einzelnes Tag, nachdem gesucht werden soll. Bei der Benutzung von posts/all besteht desweiteren das Problem, dass Deliciousnur eine begrenzte Anzahl an Aufrufen zulasst, da diese Funktion sehr rechenintensiv ist.Durch die Verwendung von Feeds kann die Beschrankung auf Bookmarks des aufrufenden Benutzers umgan-gen werden. Es besteht aber weiterhin das Problem, dass kein Zeitraum angegeben werden kann.Bookmarks konnen mit der API-Methode posts/add in das Benutzerprofil bei Delicious eingetragen werden.Dazu sind eine URL und eine Beschreibung verpflichtend. Außerdem kann das Bookmark mit Notizen undTags versehen werden. Mit dem Parameter shared kann festgelegt werden, ob das Bookmark als offentlichoder privat markiert werden soll.

• Hauptmedientyp: Bookmarks


– Bookmarks– Tags– Tag Bundles


– Offentlich– Privat


– Tags– Benutzername


– Beschreibung– Notizen– Tags– Datum– Privatsphareeinstellungen

39

5 API-Analyse

5.4 Ipernity

Ipernity ist eine Plattform, die sich zum Ziel gesetzt hat, alle Arten von Medientypen zu unterstutzen. Daherspricht Ipernity global von Dokumenten. Damit sind vor allem Photos, Videos und Audio-Dateien gemeint.Außerdem erhalt jeder Benutzer ein Weblog, in dem er zum Beispiel uber diese Dokumente schreiben kann.

API

Die API von Ipernity bietet die Moglichkeit, Dokumente hochzuladen, zu Alben zusammenzufassen undDokumente anderer zu kommentieren [Ipe09]. Sie ist sehr stark an die API von Flickr angelehnt, angefangenbei der Autorisierung durch den Benutzer, bis hin zu den Einstellungen zur Privatsphare von Dokumenten.

• Stand: 11.12.2008

• Architektur-Stil: REST-RPC-Hybrid und RPC (bei XML-RPC/SOAP als Technologie)


• Technologie: REST-ahnlich, SOAP, XML-RPC

• Antwortformate:

– proprietares XML– JSON– SOAP– XML-RPC– serialisierte PHP Objekte

• Anwendungsauthentifizierung: API-Key, Secret



– JavaScript– PHP

Feed-Interface

Ipernity stellt ein umfangreiches Feed-Interface zur Verfugung, mit dem sogar private Dokumente als Feedsabgerufen werden konnen, sofern die notigen Berechtigungen existieren. Dazu stellt Ipernity jedem Nutzereinen sogenannten Feed-Key zur Verfugung. Dieser Feed-Key wird dann als Passwort fur eine HTTP BasicAuthentication verwendet.

• Stand: 11.12.2008

• Antwortformate:

– RSS– Atom– RDF

40

5 API-Analyse

– JSON– serialisierte PHP Objekte


– Dokumente– Blogposts– Kommentare

• Zugriff auf private Daten: ja

• Authentifizierung: HTTP Basic Authentication mit Benutzername und personlichem Feed-Key


Bei Ipernity ist die Benutzer-Authentifizierung stark an die von Flickr angelehnt. So wird auch hier zwischenWebanwendung und Desktopanwendung unterschieden. Dabei benutzt Ipernity sogar die gleiche Terminolo-gie, wie sie von Flickr verwendet wird.


• Verfahren:

– Sequential-Token-Request– Interrupted-Token-Request




Datenzugriff

Mit der Ipernity-API konnen alle Informationen, die auch auf der Website von Ipernity zur Verfugung stehen,abgerufen werden. Lediglich auf die Benutzerblogs und Kontakte hat man keinen Zugriff.Ipernity stellt fur die Dokumentensuche die Methode doc.search zur Verfugung. Bei einem Aufruf dieserMethode erhalt man eine entsprechende Antwort mit den Metadaten aller gefundenen Dokumente. Mit derAngabe von extra=medias werden zusatzlich die URLs zu den Dokumenten mitgeliefert.Eine Suche uber das Feed-Interface zu realisieren macht dabei wenig Sinn, da hierbei lediglich in den Tagsder Dokumente gesucht werden kann.Um Dokumente zu Ipernity ubermitteln zu konnen, muss der Benutzer die Anwendung mit der ”write“-Berechtigung autorisiert haben. Beim Upload konnen Privatsphare-Einstellungen vorgenommen werden.Ipernity gibt sogar die Moglichkeit, Berechtigungen fur das Kommentieren und Taggen von Dokumentenzu vergeben.Bei der Upload-Methode handelt es sich um einen asynchronen Upload. Das heißt, wurde der Upload gest-artet, erhalt die Anwendung eine Ticket-ID zuruck, anhand derer der Status mit der API-Methode upload.

checkTickets gepruft werden kann.

41

5 API-Analyse

• Hauptmedientyp: Dokumente (Photo, Video, Audio, andere)


– Alben– Kommentare / Notes– Favoriten– Gruppen– Benutzerinformationen– Tags


– Familienmitglieder– Freunde– Familienmitglieder & Freunde– Privat– Offentlich


– Benutzer-ID– Text– Tags– Medientyp– Privatsphareeinstellungen– Alben-ID– Gruppen-ID– fruhestes bzw. spatestes Uploaddatum– Anzahl der zuruckgelieferten Elemente– Sortierung


– Titel– Beschreibung– Privatsphareeinstellungen (offentlich, fur Freunde, fur Familie, privat)– Tags– Album-ID– Zugriffsbeschrankung fur Kommentare, Tags

5.5 last.fm

last.fm ist eine Musikplattform. Sie unterscheidet sich insofern von den anderen Web 2.0 Diensten, dass dernormale Benutzer selbst keine Musik zur Verfugung stellen kann. Dies bleibt angemeldeten Kunstlern undMusiklabels vorbehalten. Aktionen, die der Benutzer ausfuhren kann, sind zum Beispiel der Aufbau einerMusiksammlung oder von Playlists, die er anderen Benutzern zur Verfugung stellen kann.

42

5 API-Analyse

API

Die API von last.fm stellt eine Vielzahl von Methoden zur Verfugung, um Informationen uber Kunstler,Alben, Lieder, Veranstaltungen und den abfragenden Benutzer abzurufen [Las09].Die Anwendungsauthentifizierung geschieht uber einen API-Schlussel und einen geheimen Schlussel.

• Stand: 11.12.2008

• Architektur-Stil: REST-RPC-Hybrid und RPC (bei XML-RPC als Technologie)


• Technologie: REST-ahnlich, XML-RPC

• Antwortformate:

– proprietares XML– JSON– XML-RPC


• mehrere Anwendungen moglich: nein


– Java– .NET– Python– PHP

Feed-Interface

Uber das Feed-Interface gibt last.fm lediglich die Moglichkeit, Termine von Veranstaltungen als RSS oderim iCal-Format abzurufen.

• Stand: 11.12.2008

• Antwortformate:

– RSS– iCal

• abrufbare Daten: Veranstaltungen




last.fm bietet, wie andere Dienste auch, drei Arten der Benutzerauthentifizierung an (fur Webanwendungen,fur Desktopanwendungen und fur mobile Anwendungen). Fur mobile Anwendungen ist hierbei eine Autori-

43

5 API-Analyse

sierung nach dem Login-Token-Exchange-Verfahren vorgesehen. Dazu muss das Passwort allerdings nicht imKlartext vorliegen. Zur Ubertragung wird lediglich ein MD5-Hash des Passwortes benotigt.


• Verfahren:

– Sequential-Token-Request– Interrupted-Token-Request– Login-Token-Exchange




Datenzugriff

Die last.fm-API bietet Methoden an, um alle Arten von Informationen, die zu Kunstlern, Liedern etc. in derDatenbank von last.fm gespeichert sind, abzurufen. Einschrankungen zur Privatsphare gibt es in der last.fmkeine, da Benutzer keine eigenen Lieder online stellen konnen.Zur Suche von Liedern bietet die last.fm-API zwei relativ effiziente Methoden. Bei track.search muss alsParameter ein Tracktitel angegeben werden. Obwohl es einen Parameter artist gibt, wird bei Angabe desTracks auch in den Namen von Kunstlern gesucht.Die API-Methode tag.getTopTracks kann fur eine Tagsuche verwendet werden. Sie gibt die Lieder zuruck,die am haufigsten mit dem Tag versehen worden sind.

• Hauptmedientyp: Lieder


– Kunstler– Veranstaltungen– Playlists– Benutzerinformationen– Kontakte

• Zugriffsbeschrankung: -


– Titel– Tags– Anzahl der zuruckgelieferten Elemente

• Argumente fur den Upload: -

44

5 API-Analyse

5.6 SlideShare

SlideShare ist ein Dienst zum Speichern von SlideShows. Dabei werden Prasentationen in den PowerPoint-Formaten (ausgenommen MS Office 2007 bzw. MS Office:mac 2008) und im OpenOffice Presentation-Format,sowie Textdokumente und Tabellen als Word-Datei, Excel-Datei, OpenOffice Writer-Datei, OpenOffice Calc-Datei und als PDF-Datei akzeptiert.Diese Dateien werden von SlideShare nach dem Upload in einem Flash-Format abgespeichert, so dass sieahnlich wie YouTube-Videos betrachtet werden konnen. Außerdem kann der Uploader festlegen, ob dieDateien zum Download zur Verfugung gestellt werden sollen.

API

Zur Benutzung der API wird ein API-Schlussel und ein geheimer gemeinsamer Schlussel benotigt, den manauf der Website von SlideShare beantragen kann. Alle Anfragen an die API mussen außerdem mit demaktuellen Zeitstempel und einem SHA1 Hash versehen sein, der sich aus der Konkatenation von geheimemSchlussel und Zeitstempel ergibt [Sli09].Die API gibt die Moglichkeit, alle Slideshows eines Benutzers, einer Gruppe oder eines Tags zu ermitteln.Beim Upload von Slideshows wird eine ID zuruckgegeben, mit der man nach der Konvertierung auf demServer von SlideShare die Slideshow wiederfinden kann. Des Weiteren konnen mit Hilfe der API bestehendeSlideshows bearbeitet, aktualisiert und geloscht werden.SlideShare beschrankt die Nutzung der API auf maximal 1000 Zugriffe pro Tag und API-Schlussel. Die Datensollten daher moglichst zwischengespeichert werden.

• Stand: v2.0 / 14.01.2009





• Anwendungsauthentifizierung: API-Key, Shared Secret

• mehrere Anwendungen moglich: nein


– PHP– .NET– Java– Python– Ruby

Feed-Interface

SlideShare bietet die Moglichkeit, RSS-Feeds mit Slideshows zu abonnieren. Darunter sind z.B. die neues-ten und die meist betrachteten Slideshows. Aber auch die Slideshows einzelner Benutzer und zu einzelnenTags konnen abgerufen werden. Allerdings bietet das SlideShare Feed-Interface keine Einstellungen, um zumBeispiel die Anzahl der zuruckgelieferten Elemente anzugeben.

45

5 API-Analyse

• Stand: 06.04.2009

• Antwortformate: RSS

• abrufbare Daten: Slideshows




Um Daten zu andern und Slideshows hochzuladen bzw. zu loschen, muss der Benutzer die Anwendungautorisieren, dies in seinem Namen zu tun. Dazu wird ein Login-basiertes Verfahren verwendet, bei demBenutzername und Passwort im Entity-Body bzw. im Query-String jeder HTTP-Nachricht im Klartextubergeben werden. Das heißt, diese Benutzerdaten mussen in der Anwendung gespeichert werden.Obwohl die SlideShare-API im Januar 2009 in der Version 2.0 veroffentlicht worden ist, wurde sich diesemSicherheitsrisiko nicht angenommen.

• Art des Verfahrens: Login-basiert

• Verfahren: Klartext-Ubertragung im Query-String (HTTP-GET) bzw. im Body (HTTP-POST)

• erforderliche Parameter: Benutzername, Passwort

• Token speicherbar: -

• Callback-URL dynamisch wahlbar: -

Datenzugriff

Die Slideshare-API ermoglicht es, Informationen uber Slideshows abzurufen. Dazu zahlen zum Beispiel Titel,Beschreibung, URL und HTML-Embed-Code.Die Suche von Slideshows wird durch Suchbegriffe bestimmt. Mit dem Parameter what kann eingestelltwerden, ob es sich um eine Textsuche oder eine Tagsuche handeln soll. Außerdem kann uber den Parameterlang die Sprache der Slideshows festgelegt werden.Zum Upload von Slideshows wird die API-Methode upload_slideshow verwendet. Es werden die verschie-densten Formate, wie zum Beispiel PowerPoint, OpenOffice Presentation und PDF, akzeptiert. Sogar Word-und Excel-Dokumente konnen verarbeitet werden.Beim Upload kann der Benutzer einstellen, ob die Slideshow herunterladbar oder einbettbar sein soll. Au-ßerdem konnen fur private Slideshows geheime URLs generiert werden, die der Benutzer dann an anderePersonen weitergeben kann.Nachdem eine Slideshow auf den Server von SlideShare geladen worden ist, wird diese dort in ein Flashformatumgewandelt. Diese Umwandlung kann selbst bei kleinen Dateien mehrere Tage in Anspruch nehmen.

• Hauptmedientyp: Slideshows


46

5 API-Analyse

– Kontakte– Benutzergruppen– Tags


– Offentlich– nur fur Kontakte– Privat


– Suchbegriff– Anzahl der zuruckgelieferten Elemente– Sprache– Downloadbar– Sortierung– Dateiformat– Lizenz


– Titel– Beschreibung– Tags– Privatsphareeinstellungen (offentlich, fur Kontakte, privat)

5.7 Blogger

Blogger ist ein Blogging-Service. Es bietet dem Nutzer die Moglichkeit, Artikel zu verfassen. Diese Artikelkonnen von anderen Nutzern mit Kommentaren versehen werden.

API

Blogger verwendet die Google Data API [Goo09a]. Innerhalb dieser bietet die Blogger Data API die Moglich-keit, Artikel und Kommentare zu erstellen, zu bearbeiten, zu loschen und abzurufen. Eine Authentifizierungder Anwendung uber einen Developer-Key oder ahnliches ist dabei nicht notig.Wie bei YouTube, das auch auf der Google Data API aufbaut, werden von Blogger generell Feeds zuruckge-geben. Daher wird auch hier auf die Unterscheidung zwischen API und dem Feed-Interface verzichtet.

• Stand: 08.04.2009 / v2.0

• Architektur-Stil: REST-konform

• Methodeninformation: HTTP-Methode


• Antwortformate: Atom, RSS

47

5 API-Analyse

• Anwendungsauthentifizierung: keine Authentifizierung notig

• mehrere Anwendungen moglich: -


– Java– .NET– PHP– JavaScript– Python– Objective-C


Die Google Data API sieht fur Blogger zwei Arten der Autorisierung durch den Benutzer vor. Das Sequential-Token-Request-Verfahren ist in Form von Googles AuthSub fur Webanwendungen und das Login-Token-Exchange-Verfahren als ClientLogin fur Desktopanwendungen vorgesehen.

• Verfahren:

– Sequential-Token-Request– Login-Token-Exchange

• Parameter: Token bzw. fur Login-Token-Exchange zusatzlich Benutzername und Passwort



Datenzugriff

Mit der Blogger Data API konnen Blogeintrage und Kommentare zu Blogeintragen abgerufen werden. EinBlogeintrag kann nur als privat markiert werden, indem er als Draft, also Entwurf, gespeichert wird.Bei unauthentifizierten Aufrufen erhalt man nur veroffentlichte Eintrage zuruck, bei authentifizierten Auf-rufen alle Eintrage.Eine Suche ist in Blogger nicht moglich. Es konnen lediglich Blog, Kategorie und Veroffentlichungsdatumals beschrankende Faktoren angegeben werden. Es gibt aber keine Moglichkeit, Suchbegriffe zur Tag- oderFreitextsuche anzugeben.Blogeintrage bestehen aus einem Titel, einem Text (formatiert als XHTML) und eventuellen Kategorien.Außerdem kann mit dem Parameter draft angegeben werden, ob es sich um einen Entwurf handelt odernicht.

• Hauptmedientyp: Blogeintrage


– Kommentare

48

5 API-Analyse


– Draft– Published

• Filter bei der Suche: -


– Titel– Kategorie– Privatsphareeinstellungen

5.8 Vimeo

An dieser Stelle sei nun Vimeo als alternative Videoplattform zu YouTube vorgestellt. Die Nutzung vonVimeo ist kostenlos. Dabei sind die Internetseiten mit Werbeeinblendungen versehen. Außerdem stehen500 MB pro Woche fur Uploads zur Verfugung und die Anzahl der High Definition Video Uploads ist auf einVideo pro Woche beschrankt. Durch eine kostenpflichtige Plus-Mitgliedschaft konnen diese Beschrankungenaufgehoben werden. Zusatzlich wird dann die Verarbeitung von hochgeladenen Videos hoher priorisiert, alsdie von kostenlosen Accounts.

API

Vimeo stellt mehrere APIs zur Verfugung. Es wird unterschieden in die Simple API fur einfache unauthentifi-zierte Anfragen, die Advanced API fur komplexere Anfragen und Modifikationsoperationen und die oEmbedAPI. oEmbed ist ein offener Standard zur Einbettung von Videos und Bildern in Webseiten [HMCC08]. DieseAnalyse beschaftigt sich mit der Advanced API, da sie machtiger als die Simple API ist.

• Stand: 06.04.2009




• Antwortformate:

– proprietares XML– serialisierte PHP Objekte– JSON




– PHP

49

5 API-Analyse

Feed-Interface

Uber die im Feed-Interface zur Verfugung stehenden Feeds gibt Vimeo nur wenig Informationen. Es lassensich Feeds mit eigenen Videos, mit Videos von Kontakten und solchen Videos abonnieren, die einem vonanderen Benutzern freigegeben worden sind.

• Stand: 06.04.2009

• Antwortformate: RSS

• abrufbare Daten: Videos




Vimeo stellt in der Advanced API zwei Methoden zur Verfugung, wie eine Autorisierung realisiert werdenkann.


• Verfahren:

– Sequential-Token-Request– Interrupted-Token-Request




Datenzugriff

Fur den Datenzugriff auf Videos, Kommentare und Personen stellt die Advanced API einige Methoden zurVerfugung. Bei der Suche konnen Suchbegriffe und eine Benutzer-ID als beschrankende Faktoren angegebenwerden. Außerdem bietet sie die Moglichkeit, nur in den Videos von Kontakten eines durch die Benutzer-IDfestgelegten Benutzers zu suchen. Die Suchbegriffe werden, wie bei YouTube, auf die gesamten Metadatender Videos angewandt. Eine Einschrankung auf eine Tagsuche ist nicht moglich.Der Upload von Videos gestaltet sich anders als der anderer Dienste. Um ein Video hochzuladen, musszuerst ein sogenanntes Upload-Ticket angefragt werden. Unter Angabe dieses Tickets kann dann ein Videogesendet werden. Im Anschluss daran muss dann die Methode vimeo.videos.checkUploadStatus aufgerufenwerden. Als Antwort erhalt man nun eine Video ID. Erst wenn diese Methode aufgerufen worden ist, wirdauf Seiten von Vimeo mit der Verarbeitung begonnen. Beim initialen Upload ist es nicht moglich, Titel,Beschreibung oder Tags festzulegen. Dies geschieht erst durch einzelne Anfragen an die Methoden vimeo.

videos.setTitle, vimeo.videos.setCaption und vimeo.videos.addTags. Das heißt also, dass fur einen Uploadmit den wichtigsten Informationen mindestens sechs Anfragen an die API notig sind.

50

5 API-Analyse

• Hauptmedientyp: Videos


– Kommentare– Personen– Kontakte


– offentlich– Kontakte– einzelne Nutzer– privat


– Suchbegriff– Benutzer-ID– Beschrankung auf Videos der Kontakte– Anzahl der zuruckgelieferten Elemente


– Titel– Beschreibung– Tags

5.9 Facebook

Mit - nach eigenen Angaben - mehr als 200 Millionen Nutzern und uber 660.000 Entwicklern, die Anwen-dungen fur die Facebook-Plattform entwickeln, ist Facebook der weltweit großte Social-Networking-Anbieter(Stand: 10.04.2009) [Fac09a]. Hauptfeature von Facebook ist das Verknupfen von Freunden.

API

Facebook bietet Entwicklern eine umfangreiche Plattform, um Profile mit weiteren Funktionen anzureichern.Dazu konnen eigene Anwendungen entwickelt und direkt in Facebook eingebettet werden. Die API bietetZugriff auf Freunde, Benutzerprofile, Gruppen und viele weitere Features [Fac09b]. Außerdem stellt Facebookeine eigene Anfragesprache FQL zur Verfugung, mit der, ahnlich wie mit SQL, Anfragen an die Datenbankvon Facebook gestellt werden konnen.

• Stand: 06.04.2009





51

5 API-Analyse

• Anwendungsauthentifizierung: API-Key, Application Secret



– PHP– JavaScript– C++– Ruby– Java– Python

Feed-Interface

Facebook bietet von sich aus nur sehr begrenzte Moglichkeiten, Feeds zu abonnieren. Dazu zahlen die Status-Updates, Links und Notizen von Freunden. Auf weitere Daten, wie zum Beispiel einen Feed, der alle Freundeenthalt, hat man uber das Feed-Interface keinen Zugriff. Es besteht allerdings sicherlich die Moglichkeit,eigene Anwendungen fur die Facebook-Plattform zu schreiben, die dann einen solchen Feed zur Verfugungstellen.

• Stand: 07.04.2009

• Antwortformate: RSS, Atom


– Status-Updates

– Links

– Notizen




Fur die Autorisierung verwendet Facebook ein Verfahren, das aus einer Kombination von Sequential-Token-Request und Manual-Token-Input besteht. Zuerst wird dabei eine Autorisierung durchgefuhrt, wie sie vonanderen Services bekannt ist. Nachdem der Benutzer die Anwendung autorisiert hat, muss die Anwendungeinen IFrame oder ein Browserfenster offnen, worin dann der Benutzer ein Token generieren muss. DiesesToken wird in der Anwendung eingegeben und dann gegen ein AccessToken ausgetauscht. Dieses kann dar-aufhin in der Anwendung gespeichert werden. Durch dieses umstandliche Verfahren soll wahrscheinlich eineautomatisierte Autorisierung verhindert werden.Eine Besonderheit bei der Facebook-Autorisierung liegt in der Callback-URL. Bei anderen Services reichtes aus, dass die Callback-URL vom Browser des Benutzers aufrufbar ist. Das heißt, dass zum Beispiel auchlokale Anwendungen als Callback-URL verwendet werden konnen. Bei Facebook hingegen muss die URLaus dem Internet erreichbar sein. Das Token wird hier nicht wie ublich an die Callback-URL angehangt,sondern es wird ein Request an die URL gestellt, der dann das Token enthalt. Somit ist eine Autorisierung

52

5 API-Analyse

von lokalen Anwendungen nur dann moglich, wenn man eine von außen zugangliche Schnittstelle anbietet,die das Token annimmt und an die lokale Anwendung weiterreicht.


• Verfahren: Sequential-Token-Request in Verbindung mit Manual-Token-Input




Datenzugriff

Die wichtigsten Daten von Facebook sind die Freunde. Diese konnen mit einer Anfrage in der FacebookQuery Language (FQL) abgerufen werden. Eine FQL-Anfrage, die die Benutzerinformationen von Freundeneines Nutzers abruft, konnte zum Beispiel wie folgt aussehen:

SELECT uid, name, profile_url FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1=1234)

Listing 5.1: Facebook-FQL-Anfrage

Die Suche nach Personen ist mit der API nicht wirklich brauchbar. So kann hier nur nach Personen gesuchtwerden, wenn der vollstandige Name angegeben wird.Einen schreibenden Zugriff auf die Freunde eines Nutzers bietet die Facebook API aktuell nicht.

• Hauptmedientyp: Personen

• abrufbare Daten: Freunde


• Filter bei der Suche: nur mit vollstandigem Namen

• Argumente fur den Upload: -

5.10 GroupMe!

GroupMe! ist ein Social Tagging System. Dabei handelt es sich um ein Projekt der Semantic Web Gruppe desFachgebiets Wissensbasierte Systeme am Institut fur Verteilte Systeme der Leibniz Universitat Hannover.Es ermoglicht das Tagging und die Gruppierung von Ressourcen. Daruber hinaus konnen die Gruppenselbst auch getaggt werden. Mit GroupMe! ist es moglich, Gruppen zu beliebigen Themen anzulegen unddiesen dann Ressourcen zuzuordnen [AFH+07]. Die Gruppen werden auf der Weboberflache von GroupMe!ubersichtlich visualisiert.

API

GroupMe! bietet drei Arten von APIs. Dies sind die Search API, die Export API und die RESTful API[Gro09]. Die Search API dient der Suche von Gruppen und Ressourcen. Die Export API enthalt das Feed-

53

5 API-Analyse

Interface von GroupMe!. Mit der RESTful API konnen Gruppen abgerufen, erstellt und ihnen Ressour-cen hinzugefugt werden. Bis auf die Methode zum Erstellen von Gruppen, wird auf diesen Webservice inREST-konformer Form zugegriffen. Die API befindet sich aber in standiger Entwicklung, daher ist davonauszugehen, dass sie in naher Zukunft als vollstandig REST-konform bezeichnet werden kann.

• Stand: 06.04.2009

• Architektur-Stil: REST-konform (RESTful API), REST-RPC-Hybrid (Search API)

• Methodeninformation: HTTP-Methode (RESTful API), Anfrageparameter (Search API)


• Antwortformate: RDF (RESTful API), proprietares XML (Search API)

• Anwendungsauthentifizierung: Consumer Key, Consumer Secret

• mehrere Anwendungen moglich: auf Anfrage

• offiziell unterstutzte Bibliotheken: -

Feed-Interface

Das Feed-Interface von GroupMe! wird als Export API bezeichnet. Damit konnen Feeds mit Gruppen undRessourcen als RSS oder RDF ausgegeben werden.

• Stand: 06.04.2009

• Antwortformate:

– RSS– RDF


– Gruppen– Ressourcen

• Zugriff auf private Daten: -



Zur Autorisierung und Authentifizierung wird das OAuth-Verfahren eingesetzt. Die einzigen Funktionen, dieeine Authentifizierung benotigen, sind das Erstellen von Gruppen und das Hinzufugen von Ressourcen zuGruppen. Alle anderen Methoden konnen unauthentifiziert aufgerufen werden.


• Verfahren: OAuth

54

5 API-Analyse




Datenzugriff

Die RESTful API von GroupMe! gibt Zugriff auf die RDF-Reprasentation von Gruppen und Ressourcen.Genauso konnen Benutzerinformationen der GroupMe!-Benutzer abgefragt werden.Die Search API stellt drei Methoden zur Verfugung:

• groupme.search: Suche von Ressourcen und Gruppen

• groupme.search.groups: Suche von Gruppen

• groupme.search.resources: Suche von Ressourcen

Von diesen Methoden wird dann eine proprietare XML-Struktur zuruckgegeben.Zum Erstellen von Gruppen wird ein HTTP-POST-Request an die Methode create-new-group gestellt. DieserRequest enthalt die RDF-Reprasentation der Gruppe, in der Titel, Beschreibung und Tags, sowie eventuellRessourcen, die der Gruppe zugeordnet werden sollen, festgelegt werden. Außerdem konnen mit einem HTTP-POST-Aufruf auf den URI einer Gruppe neue Ressourcen zu dieser hinzugefugt werden.

• Hauptmedientyp: Gruppen und Ressourcen


– Benutzer



– Tags– Anzahl der zuruckgelieferten Elemente


– Titel– Beschreibung– Tags

5.11 Diskussion

In diesem Kapitel wurden die APIs von zehn Webservices vorgestellt. Nun sollen noch einmal die Eigenschaf-ten zusammengefasst werden. Es werden die Bereiche Architektur-Stile, Autorisierungsverfahren, Antwortfor-mate und Bibliotheken behandelt. Im Anschluss daran wird auf die Verwendung von HTTP-Methodennameneingegangen. Es soll damit ermittelt werden, was der aktuelle State of the Art ist.

55

5 API-Analyse

Architektur-Stile

Wie Tabelle 5.1 zeigt, verwenden die meisten Service-Anbieter eine REST-RPC-Hybridarchitektur. Das heißtalso, dass die Methodeninformation nicht, wie in REST vorgesehen, in den HTTP-Methodennamen steckt,sondern als Teil des URI oder als Parameter angegeben wird. Nur wenige Anbieter stellen zusatzlich nocheine reine RPC-Schnittstelle fur SOAP oder XML-RPC zur Verfugung.

REST-konform RPC REST-RPC-Hybrid

Flickr 4 4

YouTube 4

Delicious 4

Ipernity 4 4

last.fm 4 4

SlideShare 4

Blogger 4

Vimeo 4

Facebook 4

GroupMe! 4 4

Tabelle 5.1: Architektur-Stile

Autorisierungsverfahren

Die meisten Webservices verwenden Sequential-Token-Request- und Interrupted-Token-Request-Verfahrenfur die Autorisierung. Daher macht es Sinn, wie in Abschnitt 3.3 beschrieben, ein Verfahren zu verwenden,das nahe an diesen liegt. Dabei ist es durch ein Interrupted-Token-Request-Verfahren mit Callback-URL-Option, das an OAuth angelehnt ist, moglich, sowohl Desktopanwendungen als auch Webanwendungen zubedienen.

Login-basiert STR ITR LTE MTI OAuth

Flickr 4 4 4

YouTube 4 4 4

Delicious 4

Ipernity 4 4

last.fm 4 4 4

SlideShare 4

Blogger 4 4

Vimeo 4 4

Facebook 4

GroupMe! 4

Legende:

STR Sequential-Token-Request

ITR Interrupted-Token-Request

LTE Login-Token-Exchange

MTI Manual-Token-Input

Tabelle 5.2: Verwendung der Autorisierungsverfahren

Antwortformate

Wenn man die Antwortformate, also die zuruckgelieferten Reprasentationen, betrachtet, stellt man fest, dassFormate wie RDF und serialisierte PHP Objekte eher zu den Exoten gehoren.

56

5 API-Analyse

Die meisten Services verwenden ein proprietares XML-Format. Dies hat fur den Anbieter den Vorteil, dasses leicht fur die eigenen Zwecke anpassbar ist und zudem in der Ubertragung weniger Traffic verursacht, alsein standardisiertes Format, das fur alle Eventualitaten vorbereitet sein muss. Der Nachteil ist wiederum,dass fur jeden Service ein eigener Parser geschrieben werden muss, was bei einem Standard wahrscheinlichnicht notig ware.JSON hat sich zum Quasistandard fur AJAX-Anwendungen entwickelt. Daher macht es Sinn, auch solcheReprasentationen zur Verfugung zu stellen.Als Format fur Feedreader liegt die Wahl zwischen RSS und Atom. Dabei ist Atom RSS vorzuziehen, da esgenauer spezifiziert ist und es somit wahrscheinlicher ist, dass die Daten so interpretiert werden, wie es vomEntwickler vorgesehen ist.

XML JSON Atom RSS RDF PHP-Objekte XML-RPC SOAP

Flickr 4 4 4 4 4

YouTube 4 4 4

Delicious 4

Ipernity 4 4 4 4 4

last.fm 4 4 4

SlideShare 4

Blogger 4 4

Vimeo 4 4 4

Facebook 4

GroupMe! 4 4

Tabelle 5.3: Antwortformate

In der Datenbank von ProgrammableWeb.com sind 1273 APIs gelistet. Abbildung 5.1 zeigt, welche Formatevon diesen APIs verwendet werden.

Abbildung 5.1: Antwortformate der bei http://programmableweb.com gelisteten APIs (uberpruft am21.04.2009)

57

5 API-Analyse

Bibliotheken

Tabelle 5.4 zeigt die offiziell unterstutzten Bibliotheken fur die gebrauchlichsten Programmiersprachen. Zubeachten ist hierbei, dass diese Liste naturlich nicht vollstandig sein kann. Dies liegt an der Vielzahl vonProgrammiersprachen und Drittanbieterbibliotheken.

Java PHP JavaScript .NET Ruby Objective-C Python

Flickr 4 4 4 4 4 4

YouTube 4 4 4 4 4

Delicious

Ipernity 4 4 4

last.fm 4 4 4 4

SlideShare 4 4 4 4 4

Blogger 4 4 4 4 4 4

Vimeo 4

Facebook 4 4

GroupMe!

Tabelle 5.4: Bibliotheken

Verwendung von HTTP-Methoden

In Abschnitt 2.4.2 wurde die einheitliche Schnittstelle vorgestellt. An dieser Stelle soll zuerst gezeigt werden,welche HTTP-Methoden die einzelnen Services verwenden. Danach wird untersucht, ob diese Methodenrichtig eingesetzt werden.Tabelle 5.5 zeigt die vier wichtigsten HTTP-Methoden und von welchen Webservices sie verwendet werden.

GET POST PUT DELETE

Flickr 4 4

YouTube 4 4 4 4

Delicious 4

Ipernity 4 4

last.fm 4 4

SlideShare 4 4

Blogger 4 4 4 4

Vimeo 4 4

Facebook 4 4

GroupMe! 4 4

Tabelle 5.5: Verwendung der HTTP-Methoden

Die Verwendung der Methoden allein bedeutet aber noch nicht, dass sie auch richtig verwendet werden. Hiersei noch einmal kurz erinnert, fur welche Zwecke die Methoden vorgesehen sind:

• GET: Abfragen von Ressourcen

• POST: Hinzufugen einer neuen Ressource zu einer ubergeordneten Ressource

• PUT: Hinzufugen/Ersetzen einer Ressource mit einem bestimmten URI

58

5 API-Analyse

• DELETE: Loschen von Ressourcen

Wie man sehen kann, werden die vier HTTP-Methoden bei weitem nicht von allen Services genutzt. FolgendeBeispiele hierzu sollen dies verdeutlichen:

• Bei fast allen Services wird statt der DELETE-Methode die POST-Methode zum Loschen von Res-sourcen verwendet.

• Delicious bedient sich fur alle Aktionen der GET-Methode.

• Vimeo macht uberhaupt keine Einschrankungen zur Methode. Die von Vimeo zur Verfugung gestell-te PHP-Bibliothek verwendet fur alle Anfragen die POST-Methode. Genauso konnen aber auch alleMethoden (außer dem Upload) mit GET aufgerufen werden.

Ein Nichtbenutzen von Methoden muss aber nicht zwangslaufig darauf hindeuten, dass gegen die einheitli-che Schnittstelle verstoßen wird. Die API von GroupMe! stellt zum Beispiel schlicht keine Funktionen zurVerfugung, die eine PUT- oder DELETE-Methode notig machen wurden. Ein positives Beispiel sind dieGoogle-Dienste YouTube und Blogger, welche alle Methoden vorbildlich umsetzen.Die Beschrankung auf die GET- und die POST-Methode liegt wahrscheinlich daran, dass die heutigen Brow-ser nur diese Methoden unterstutzen. Wenn im Browser ein Formular dargestellt wird, kann fur dieses lediglichGET oder POST als Ubertragungsmethode festgelegt werden.

59

6 Implementierung von InterWeb


In diesem Kapitel wird die Implementierung der Integrationsplattform InterWeb vorgestellt. InterWeb hatdas Ziel, eine Schnittstelle zu bilden, die verwendet werden kann, um auf einem einheitlichen Weg auf Web2.0 Services zuzugreifen. Dazu bietet InterWeb seine Daten und Funktionalitaten selbst als Webservice an.Der Webservice von InterWeb positioniert sich dabei zwischen Client und den Web 2.0 Services (sieheAbbildung 6.1). Der Client kann InterWeb beauftragen, eine Suche durchzufuhren, Ressourcen an einenWebservice zu senden und Daten uber Benutzeraccounts abzurufen. Dabei muss sich der Benutzer nicht mitden Weboberflachen der einzelnen Web 2.0 Services auseinandersetzen, um zum Beispiel eine Ressource aneinen Web 2.0 Service zu senden.Wenn im Folgenden von Webservice gesprochen wird, ist immer ein Web 2.0 Service (wie Flickr, YouTubeetc.) gemeint. Wenn die hier implementierte Plattform und der dazugehorige Webservice gemeint ist, wirdvon InterWeb gesprochen.

Abbildung 6.1: Positionierung von InterWeb

InterWeb soll folgende Features zur Verfugung stellen:

• Suche nach Ressourcen

• Upload von Ressourcen

• Abrufen von Freunden

• Abrufen der Ressourcen eines Nutzers

Außerdem bietet InterWeb uber seine API die Moglichkeit, Benutzer anzulegen und ihre Autorisierungenbei den Web 2.0 Services zu verwalten.

60


Wie in Abschnitt 5.11 gezeigt, bieten die meisten untersuchten Webservices Bibliotheken fur ihre APIs in PHPan. Daher liegt es nahe, InterWeb auf der Grundlage des Symfony Frameworks in PHP zu implementieren.Symfony orientiert sich an dem Rapid Development Framework Ruby on Rails und bietet alle Voraussetzun-gen, um REST-konforme Architekturen aufzubauen. Außerdem bietet Symfony die Moglichkeit, das Modellin einer YAML-Datei zu definieren und vollstandig generieren zu lassen. Das Framework kummert sich auchum das Object-Relational Mapping zu einer beliebigen relationalen Datenbank.Die Architektur soll nun aus zwei Blickwinkeln beschrieben werden: zum einen der Zugriff von einem Clientauf InterWeb und zum anderen der Zugriff von InterWeb auf die Web 2.0 Services. Im Anschluss daran wirdgezeigt, wie InterWeb um weitere Web 2.0 Services erweitert werden kann.

6.1 Client ←→ InterWeb

Abbildung 6.2: Zugriff von einem Client auf InterWeb

Entwickler konnen unter http://semweb.kbs.uni-hannover.de/~tristan/auth/api_keys einen Consumer Keyund ein Consumer Secret beantragen. Diese werden benotigt, um Anfragen an die API von InterWeb zustellen.Um eine Anfrage an die API zu stellen, muss eine HTTP-Nachricht an die URL http://semweb.kbs.uni-

hannover.de/~tristan/api/ gesendet werden. An diese URL werden die in Abschnitt 6.1.1 definierten End-punkte angehangt. Außerdem wird das Format der gewunschten Reprasentation mit der zugehorigen Datei-endung am Endpunkt angegeben (zum Beispiel search.xml oder search.json). Die implementierten Formatesind XML, JSON und, wo es sinnvoll ist, auch Atom. Fur eine detaillierte Ubersicht sei auf die API Doku-mentation im Anhang B verwiesen.Jede authentifizierte Anfrage an die API benotigt die folgenden Parameter:

• iw_consumer_key: Der Consumer Key

• iw_token: Das AccessToken des Benutzers (siehe hierzu Abschnitt 6.1.2)

• iw_signature: Eine Signatur

Die Signatur wird benutzt, um die Authentifizierung zu verifizieren. Sie ist ein MD5-verschlusselter String, dermit dem Consumer Secret beginnt, gefolgt von den Parametern fur den Aufruf in alphabetischer Reihenfolge.Zusatzlich wird fur die Signierung der Parameter iw_path benotigt, der dem Endpunkt (ohne Formatangabe)entspricht. Fur eine Anfrage an auth/request_token muss iw_token nicht enthalten sein, da es zu diesemZeitpunkt noch kein solches gibt.

Beispiel

Der Consumer Key sei 1234, das Consumer Secret sei abcd und das AccessToken sei foobar. Angenommen essoll eine Anfrage an http://semweb.kbs.uni-hannover.de/~tristan/api/users/default/friends.xml gestelltwerden, somit wird der Endpunkt users/default/friends angesprochen.

61


Der Signatur-String baut sich nun folgendermaßen auf (+ ist die Konkatenation):

iw_consumer_secret + "iw_consumer_key" + iw_consumer_key + "iw_path"+ iw_path + "iw_token" + iw_token

Listing 6.1: Konstruktion des Signatur-Strings

also:

abcdiw_consumer_key1234iw_pathusers/default/friends/iw_tokenfoobar

Listing 6.2: Vollstandiger Signatur-String

und die MD5-verschlusselte Signatur ist:

4d67f6d3afa3848a7c197e6f8e71b0cf

Listing 6.3: Fertige Signatur

6.1.1 Endpunkte

Tabelle 6.1 zeigt einen Uberblick uber die in InterWeb implementierten Endpunkte.

Autorisierung

RequestToken abfragen auth / request_token

Autorisierungsseite auth / authorize

AccessToken abfragen auth / access_token

Suche

Suche nach Ressourcen search

Standing Query abfragen search / [QueryID]

Services

Implementierte Webservices abfragen services

Benutzer

Benutzer anlegen users

Benutzerinformation abfragen users / [username]

Benutzerinformationen zu den implementierten

Webservices abrufen

users / [username] / services

Benutzerinformation zu einem bestimmten Webser-

vice abrufen

users / [username] / services / [ServiceID]

Autorisierung bei Webservice durchfuhren

Autorisierung bei Webservice zurucknehmen

users / [username] / services / [ServiceID] / auth

Upload von Ressourcen

Uploads eines Benutzers abrufen

users / [username] / uploads

Freunde eines Benutzers abrufen users / [username] / friends

Ressourcen eines Benutzers abrufen users / [username] / resources

Gruppe anlegen

Gruppen eines Benutzers abrufen

users / [username] / groups

Tabelle 6.1: Endpunkte von InterWeb

62


Dabei meint [username] den Benutzernamen eines bei InterWeb registrierten Benutzers. Bei einigen Zugrif-fen, wie zum Beispiel dem Upload von Daten, muss [username] ”default“ sein. Das heißt, dass der Zugriffauthentifiziert und signiert geschehen muss.Bei den Endpunkten gibt es zwei Sonderfalle. Die Autorisierungsseite und Autorisierung bei einem Webservicebenotigen Benutzerinteraktionen. Das heißt, der Client kann keine einfache HTTP-Anfrage an sie stellen,sondern er muss den Browser des Benutzers zu diesen Endpunkten leiten.

6.1.2 Autorisierung

Wie in Abschnitt 3.3 beschrieben, kommt zur Autorisierung durch den Benutzer ein Verfahren zum Einsatz,das an OAuth angelehnt ist.Dazu sendet der Client zuerst eine GET-Anfrage an den Endpunkt auth/request_token. Als Antwort be-kommt er ein RequestToken. Dieses RequestToken wird nun zur Signierung und zum Aufruf der Autorisie-rungsseite mit der URL http://semweb.kbs.uni-hannover.de/~tristan/api/auth/authorize verwendet. DerBenutzer muss nun in seinem Browserfenster den Client autorisieren, damit dieser Anfragen in seinem Na-men ausfuhren kann. Wurde mit der URL zur Autorisierungsseite eine Callback-URL angegeben, wird andiese ein AccessToken angehangt und zu dieser umgeleitet. Wurde keine Callback-URL angegeben, kann derBenutzer das Browserfenster schließen und der Anwendung mitteilen, dass sie mit der Ausfuhrung fortfah-ren kann. Diese ruft dann den Endpunkt auth/access_token auf, um ein AccessToken abzufragen. DiesesAccessToken kann nun in der Anwendung gespeichert werden, um mit ihm alle authentifizierten Anfragendurchzufuhren.

6.1.3 Suche

In InterWeb ist eine machtige Suche nach Medienobjekten implementiert. Benotigte Parameter fur die Su-che sind Suchbegriffe und die Art der gesuchten Medien. Mogliche Medientypen sind dabei Fotos, Videos,Bookmarks, Slideshows, Audiodateien oder Musik. Außerdem kann angegeben werden, ob in allen Metadatenoder nur in den Tags gesucht werden soll. Des Weiteren ist eine Eingrenzung nach dem Erstellungsdatummoglich.Bei dieser Suche werden die Suchfunktionen der einzelnen Web 2.0 Services aufgerufen und die Ergebnissein einer einheitlichen Form kumuliert.Das Resultat der Suchanfrage kann als XML, JSON oder auch als Atom-Feed abgerufen werden. Außerdemwird bei der Suchanfrage eine Standing Query erstellt, deren URL mit im Resultat ausgegeben wird. Uberdie URL der Standing Query kann dann jederzeit auf die Ergebnisse der Suche zugegriffen werden.Die Suche ist an einen Benutzer gekoppelt. Ruft der Benutzer die Suche mit den gleichen Parametern erneutauf, werden die Suchergebnisse aktualisiert.

<?xml version="1.0" encoding="utf-8"?><rsp stat="ok">

<query id="1234" link="http://semweb.kbs.uni-hannover.de/~tris/api/search/1234.xml"><user>ExampleUser</user><query_string>car</query_string><search_in>text</search_in><media_types>photos</media_types><date_from></date_from><date_till></date_till><ranking>interestingness</ranking><number_of_results>10</number_of_results><updated>2009-04-21 00:11:07</updated><results>

<result><service>Ipernity</service>

63


<id_at_service>C1011057</id_at_service><type>photos</type><title>Interior red</title><description></description><url>http://www.ipernity.com/doc/16158/1011057</url><image>http://u1.ipernity.com/3/10/57/1011057.b47c5dd0.75x.jpg</image><date>2007-11-21 21:05:31</date>

</result>...

</results></query>

</rsp>

Listing 6.4: XML-Antwort auf eine Suchanfrage

6.1.4 Services

Uber den Endpunkt services kann eine Liste der in InterWeb implementierten Web 2.0 Services abgerufenwerden.Außerdem wird bei jedem Service angegeben, auf welche Art und Weise eine Autorisierung zu diesem Servicedurchgefuhrt werden kann. Dabei gibt es zwei mogliche Typen von Autorisierungen. Zum einen ist diesdie Token-basierte Autorisierung. Dazu wird eine URL angegeben, die aufgerufen werden muss, um eineAutorisierung bei dem Service durchzufuhren. Zum anderen ist das die Login-basierte Autorisierung. Bei derLogin-basierten Autorisierung wird zusatzlich zu einer URL auch eine Menge von Parametern angegeben,die benotigt werden, um eine Authentifizierung durchfuhren zu konnen.


<services><service id="Delicious">

<title>Delicious</title><authorization type="login">

<parameters><parameter type="text">username</parameter><parameter type="password">password</parameter>

</parameters><link method="POST">

http://semweb.kbs.uni-hannover.de/~tristan/api/users/default/services/Delicious/auth</link>

</authorization></service>...

</services></rsp>

Listing 6.5: XML-Antwort mit den implementierten Services

Anhand dieser Liste konnen Clients eine Benutzeroberflache dynamisch generieren, die immer die aktuellimplementierten Services und die passenden Formulare fur die Autorisierung anzeigt. Siehe hierzu auch dieImplementierung von LearnWeb2.0 in Kapitel 7, in der dies genutzt wird.

6.1.5 Benutzer

Der großte Teil der implementierten Endpunkte bezieht sich auf einen bestimmten Benutzer.InterWeb ermoglicht es Anwendungen, automatisiert Benutzer anzulegen. Mit einer HTTP-POST-Anfragean users wird unter Angabe von gewunschtem Benutzernamen und Passwort ein Benutzeraccount erstellt.Als Antwort auf die Anfrage erhalt die Anwendung ein AccessToken, das sie zur Authentifizierung nutzen

64


kann. Zuvor sollte der Endpunkt users/[username] aufgerufen werden, um zu prufen, ob der gewunschteBenutzername ([username]) verfugbar ist oder nicht. Durch diese Funktion muss sich der Benutzer - nebendenen der ganzen Web 2.0 Services - nicht um noch eine weitere Benutzeroberflache kummern.

Services des Benutzers

Uber die Endpunkte zu den Services des Benutzers konnen Informationen zum Autorisierungsstatus abgeru-fen werden. Wird users/[username]/services aufgerufen, wird die Autorisierung bei jedem Service gepruftund der Status ausgegeben. Zudem kann dies mit users/[username]/services/[ServiceID] fur einen einzel-nen Service ausgefuhrt werden. Dabei werden die gleichen Informationen ausgegeben, wie beim Aufruf vonservices, nur dass sie hier auf den Benutzer abgestimmt sind. Außerdem wird bei bestehender Autorisierungmit ausgegeben, wie diese Autorisierung zuruckgenommen werden kann.Um eine Autorisierung zuruckzunehmen, wird eine HTTP-DELETE-Anfrage an users/[username]/services

/[ServiceID]/auth gestellt. Dabei werden dann alle Daten, die eine Verbindung zwischen Benutzer undService herstellen, geloscht.

Freunde

InterWeb verfugt uber eine Funktion, mit der die Freunde und Kontakte aller implementierten Webservices,die Zugriff auf die Kontakte geben, abgerufen werden konnen. Dazu wird einfach eine HTTP-GET-Anfragean users/[username]/friends mit dem Namen des gewunschten Benutzers gestellt. Als Antwort erhalt mandann eine Liste, die als XML, JSON oder Atom-Feed ausgegeben werden kann.


<friends id="[URL to Friends of the User]"><updated>2009-04-21T00:24:12+02:00</updated><friend url="http://www.last.fm/user/interweb20">

<service>LastFm</service><username>interweb20</username><realname></realname><photo>http://cdn.last.fm/flatness/catalogue/noimage/2/default_user_large.png</photo><serviceuserid>interweb20</serviceuserid>

</friend>...

</friends></rsp>

Listing 6.6: XML-Antwort mit den Freunden eines Benutzers

Gruppen

Der users/[username]/groups-Endpunkt dient dem Abrufen und dem Anlegen von Gruppen bei GroupMe!.Bei einer GET-Anfrage werden die Gruppen eines Benutzers zuruckgegeben. Bei einer POST-Anfrage wirdzu einem angegebenen Titel eine neue Gruppe angelegt.


<groups id="URL to Groups of the User"><updated>2009-04-21T00:28:23+02:00</updated><group id="3029">

<service>GroupMe</service><uri>http://groupme.org/GroupMe/group/3029</uri><title>Test</title><description>Description</description>

65


</group>...

</groups></rsp>

Listing 6.7: XML-Antwort mit den Gruppen eines Benutzers

Upload

Ein Hauptfeature von InterWeb ist der Upload von Medienobjekten. Die Uploadfunktion nimmt eine Vielzahlvon Dateiformaten sowie Textsnippets und URLs entgegen und leitet sie zu den Web 2.0 Services weiter.Dabei konnen Titel, Beschreibung und Tags, sowie eine Gruppe, zu der die Ressource hinzugefugt werden soll,angegeben werden. Diese werden in einer HTTP-POST-Anfrage an den Endpunkt users/[username]/uploadsgesendet. [username] muss hierbei default sein. Das heißt, dass die Anfrage authentifiziert durchgefuhrtwerden muss. InterWeb leitet die Ressource zu einem passenden Service weiter, fur den der Benutzer dieNutzung autorisiert hat. Die Antwort, die der Client zuruck bekommt, enthalt dann unter anderem die IDder Ressource und die URL, unter der die Ressource beim Service abrufbar ist.


<resource id="106"><user>ExampleUser</user><service>Ipernity</service><title>Testimage</title><description>Testdescription</description><tags>

<tag>test</tag></tags><type>photos</type><url> http://u1.ipernity.com/7/39/05/4463905.0a6e44c0.png</url><date>2009-04-21T00:28:23+02:00</date>

</resource></rsp>

Listing 6.8: XML-Antwort auf einen Upload

Wird an den selben Endpunkt eine HTTP-GET-Anfrage gestellt, wird eine Liste zuruckgeliefert, die alle mitInterWeb hochgeladenen Ressourcen enthalt.


<resources id="http://semweb.kbs.uni-hannover.de/~tristan/api/users/3stan/uploads.xml"><resource>

<id>121</id><service>Delicious</service><title>InterWeb Extension</title><description></description><tags></tags><isprivate></isprivate><url>http://www.youtube.com/watch?v=QIBBElEP8go</url><date>2009-04-16 00:43:43</date>

</resource>...

</resources></rsp>

Listing 6.9: XML-Antwort mit den Uploads eines Benutzers

66


Ressourcen

Zusatzlich zu der unter Abschnitt 6.1.3 vorgestellten Suchfunktion, konnen die eigenen Ressourcen einesBenutzers abgerufen werden. Diese konnen uber den Endpunkt users/[username]/resources entweder kom-plett abgerufen oder nach Suchbegriffen, Medientypen und Uploaddaten gefiltert werden. Die Ergebnissewerden als XML, JSON oder Atom-Feed ausgegeben. Die Antwort ist dabei identisch formatiert wie die derallgemeinen Suche.

6.1.6 Fehler

Fur den Fehlerfall definiert InterWeb eine Vielzahl von Fehlercodes. Eine genaue Auflistung befindet sich inder API-Dokumentation im Anhang B.Kommt es zu einem Fehler, wird eine Antwort zuruckgegeben, die in XML folgendermaßen aufgebaut ist:

<?xml version="1.0" encoding="utf-8"?><rsp stat="fail">

<error code="[Error Code]" message="[Error Message]" /></rsp>

Listing 6.10: XML-Antwort im Fehlerfall

Am Schlusselwort fail kann der Client direkt erkennen, dass etwas falsch gelaufen ist.

6.2 InterWeb ←→ Webservices

Nachdem beschrieben worden ist, wie ein Client auf InterWeb zugreifen kann, soll nun erlautert werden, wieInterWeb die Zugriffe auf die Webservices realisiert.

Abbildung 6.3: Zugriff von InterWeb auf die Webservices

InterWeb bietet vier Interfaces, die implementiert werden mussen, um Aktionen in den verschiedenen Be-reichen Autorisierung, Suche, Freunde und Upload ausfuhren zu konnen. Die Interfaces und Namenskon-ventionen, die im Folgenden erlautert werden, werden dann von Factory-Methoden verwendet. So wird eineeinfache Erweiterung ermoglicht. Diese wird im nachsten Abschnitt erlautert.

67


Listing 6.11 zeigt die Konfiguration der implementierten Services, die in der Datei apps/frontend/config/

apps.yml vorgenommen wird. Dabei handelt es sich um eine Liste von IDs und Namen der Services. DieIDs werden fur die Anwendung der Namenskonventionen in den Factory-Methoden, sowie fur den Parameter[ServiceID] in den Endpunkten (siehe Abschnitt 6.1.1) verwendet. Die Namen sind vor allen Dingen zurPrasentation fur den Benutzer gedacht.

services:implemented:Blogger: BloggerDelicious: DeliciousFacebook: FacebookFlickr: FlickrGroupMe: GroupMe!Ipernity: IpernityLastFm: last.fmSlideShare: SlideShareVimeo: VimeoYouTube: YouTube

Listing 6.11: Konfiguration der implementierten Services (app.yml)

In Listing 6.12 wird die Zuordnung von Services zu Medientypen durchgefuhrt. Fotos werden zum Beispiel vonIpernity und Flickr abgerufen bzw. zu diesen gesendet. Dasselbe gilt fur die Medientypen Videos, Bookmarks,Slideshows, Audio, Musik und Blogging. Der Punkt friends gibt die Services an, die Zugriff auf ihr SocialNetwork geben.

mediatype:photos: [Ipernity, Flickr]videos: [Vimeo, YouTube]bookmarks: [Delicious]slideshows: [SlideShare]audio: [Ipernity]music: [LastFm]blogging: [Blogger]friends: [Flickr, LastFm, Delicious, SlideShare, YouTube, Facebook, Vimeo]

Listing 6.12: Konfiguration der Medientypen (app.yml)

6.2.1 Autorisierung

Fur die Autorisierung mit einem Service muss das Interface ApiAuth implementiert werden. Dieses Interfaceerfordert vier Methoden:

• auth() fuhrt die Autorisierung durch.

• unauth() loscht die Autorisierungsinformationen zu einem Service.

• check() pruft, ob eine Autorisierung funktioniert. Es wird also zum Beispiel eine authentifizierte An-frage an einen Webservice gestellt und gepruft, ob eine Fehlermeldung zuruckkommt.

• getUserId() fragt die Benutzer-ID bei einem Service ab und gibt diese zuruck.

Der Name der Autorisationsklasse eines Services muss mit der Service-ID beginnen und auf _ApiAuth enden(zum Beispiel Flickr_ApiAuth). Bei Zugriffen auf die Services-Endpunkte werden die betreffenden Klassendann automatisch geladen und die gewunschte Aktion ausgefuhrt.

68


Abbildung 6.4: ApiAuth-Interface

6.2.2 Suche

Die Suche befindet sich im Modul api_search. Dabei wird unterschieden zwischen der allgemeinen Suche undder Suche nach den eigenen Ressourcen eines Benutzers. Bei der allgemeinen Suche wird die Anfrage, imGegensatz zur Suche nach Benutzerressourcen, in der Datenbank gespeichert, um spater als Standing Queryauf sie zugreifen zu konnen.Wenn eine Suchanfrage gestellt wird, wird in der Datenbank nach einem Query-Objekt des Benutzers mitden selben Parametern gesucht. Gibt es eine solche Anfrage nicht oder ist die gespeicherte Anfrage alter alsfunf Minuten, wird die Anfrage an die Suchhandler der einzelnen Services fur die gewahlten Medientypenweitergereicht. Die Klassen dieser Suchhandler mussen das Interface ApiQuery implementieren, in dem eineMethode search() definiert wird. Die Namenskonvention ist auch hier [ServiceID]_ApiQuery.Die Search-Methode ruft dann die Suchfunktionen des jeweiligen Services auf, legt die Suchergebnisse inQueryResult-Objekten ab und gibt ein Array mit diesen Objekten zuruck.In der Suchaktion werden dann die Arrays mit den Suchergebnissen zusammengefasst und mit der Queryin der Datenbank gespeichert. Daraufhin wird die gesamte Anfrage samt den Ergebnissen an die Template-Engine weitergereicht, die sich darum kummert, die gewunschten Reprasentationen der Anfrage auszugeben.

Abbildung 6.5: ApiQuery-Interface, Query-Klasse und QueryResult-Klasse

Das Mapping von Anfragen auf Suchparameter ist bei einigen Services schwierig, da diese einige Filte-rungen, zum Beispiel ein fruhestes oder spatestes Uploaddatum, nicht entgegennehmen. Daher muss dasErgebnis in diesen Fallen nach dem Abrufen gesondert gefiltert werden. Das Mapping von Suchergebnis-sen auf QueryResult-Objekte macht hingegen weniger Probleme, da die meisten Services alle notigen Datenzuruckliefern, bzw. man diese aus den gegeben Informationen bilden kann.

69


6.2.3 Freunde

Stellt ein Webservice Zugriff auf die Freunde und Kontakte eines Benutzers zur Verfugung, kann dieser zumMedientyp friends hinzugefugt werden.Außerdem muss eine Klasse existieren, die das Interface ApiFriendGetter implementiert. Die Namenskonven-tion schreibt vor, dass der Name der Klasse mit der Service-ID beginnen und mit _ApiFriendGetter endenmuss (z.B. Facebook_ApiFriendGetter). In dieser Klasse gibt es die Methode getFriends(), die die Freun-de eines Nutzers vom Webservice abruft und diese in FriendResult-Objekten ablegt. Ein Array, das dieFriendResult-Objekte enthalt, wird dann zuruckgegeben.

Abbildung 6.6: ApiFriendGetter-Interface und FriendResult-Klasse

6.2.4 Upload

Der Upload von Ressourcen ist sehr flexibel aufgebaut. Das Upload-Modul nimmt prinzipiell jegliche Art vonDaten entgegen. Es macht dabei intern eine Unterscheidung zwischen Dateien und Zeichenketten. Fur dieDateien gibt es eine Zuordnungsliste, in der alle erlaubten Dateiformate auf Medientypen gemappt werden. Sokonnen Objekte fur die Medientypen Fotos, Videos, Audio und Slideshows erkannt werden. Fur Zeichenkettenwird gepruft, ob es sich um eine URL handelt. Wenn dem so ist, wird fur sie der Medientyp Bookmarksfestgelegt. Ist dem nicht so, zahlt die Zeichenkette zum Medientyp Blogging.Ist der Typ des Objekts identifiziert, wird nach einem Service gesucht, der diesen Typ unterstutzt und fur dender Benutzer eine Autorisation angelegt hat. Wurde ein Service gefunden, wird das Objekt zusammen mitden ubergebenen Parametern (Titel, Beschreibung, Tags) an den Uploadhandler des Services weitergeleitet.

Abbildung 6.7: ApiUploader-Interface und Resource-Klasse

Die Klasse des Uploadhandlers folgt der Namenskonvention [ServiceID]_ApiUploader und implementiert dasInterface ApiUploader. Wurde das Objekt zum Service geladen, wird die Antwort in ein Resource-Objekt

70


abgelegt und ausgegeben.Da InterWeb selbst ein Webservice ist und der aufrufende Client eine direkte Antwort erwartet, muss einsynchroner Upload stattfinden. Nur so kann sichergestellt werden, dass man eine ID und eine URL zurRessource zuruckliefern kann. Einzig bei SlideShare ist es nicht moglich, nach dem Upload an eine URLzur Ressource zu kommen. SlideShare gibt erst eine URL aus, wenn die Konvertierung der Slideshow in dasFlashformat durchgefuhrt worden ist. Diese Konvertierung dauert allerdings in der Regel mehrere Stundenbis mehrere Tage.

6.3 Einbindung neuer Dienste

Da die Features von InterWeb vorgestellt worden sind, soll jetzt an einem Beispiel erlautert werden, wie einneuer Service in InterWeb integriert werden kann.Daher sollen nun die Schnittstellen fur den Bookmarking-Service BibSonomy implementiert werden. BibSo-nomy bietet Zugriff auf die gespeicherten Bookmarks und BibTex-Eintrage [Kno09]. In diesem Beispiel solldie Autorisierung, die Suche nach Bookmarks und das Ablegen von Bookmarks bei BibSonomy beschrie-ben werden. Social Network Features bietet BibSonomy nicht. Die Implementierung eines FriendGetters furServices, die dieses anbieten, funktioniert aber analog.

Vorbereitung

Zuerst muss unter apps/frontend/lib/services ein Ordner bibsonomy angelegt werden.Bibsonomy bietet eine PHP-Bibliothek an. Diese muss heruntergeladen und in einem Unterordner lib un-terhalb des eben erstellten Ordners gespeichert werden.

Autorisierung

Nun wird die Autorisierungsklasse fur BibSonomy geschrieben. Dazu wird im Ordner bibsonomy eine neuePHP-Datei BibSonomy_ApiAuth.class.php angelegt. Der Quellcode dieser und der folgenden Klassen findetsich im Anhang dieser Arbeit. BibSonomy hat eine Besonderheit bei der Autorisierung. Hier hat der Ent-wickler keinen API-Key. Allerdings kann jeder einzelne Benutzer einen personlichen API-Key in seinemBenutzerprofil generieren. Dieser API-Key wird als Passwort fur eine HTTP Basic Authentication verwen-det.Da es sich hier also um eine Login-basierte Autorisierung handelt, speichert die Methode auth() einfachBenutzername und API-Key. In der Methode check() wird ein beliebiger Aufruf an die API gemacht. Kommteine gultige Antwort zuruck, funktioniert die Autorisierung. Kommt ein Fehler-Response-Code zuruck, hatdie Autorisierung nicht funktioniert.

Suche

Fur die Suche wird eine Klasse BibSonomy_ApiQuery in dem selben Verzeichnis wie BibSonomy_ApiAuth angelegt.In dieser werden zuerst die Werte aus dem Query-Objekt an die Suchoptionen fur BibSonomy angepasst.Bibsonomy bietet lediglich die Moglichkeit, Tags anzugeben. Die Anzahl der zuruckgegebenen Parameterkann durch einen Parameter end angegeben werden. Wird nach den Bookmarks eines bestimmten Benutzersgesucht, kann zusatzlich ein Benutzername angegeben werden.Leider gibt es keine Moglichkeit, die Ergebnisse nach dem fruhesten bzw. spatesten Erstellungsdatum zufiltern. Diese Filterung musste also nach dem Abrufen in der Suchmethode durchgefuhrt werden. Davonwird an dieser Stelle zur Verringerung der Komplexitat Abstand genommen.

71


Upload

InterWeb soll es ermoglichen, Bookmarks bei BibSonomy abzulegen. Dazu wird zunachst eine Klasse mitdem Namen BibSonomy_ApiUploader erstellt. BibSonomy erlaubt es, eine URL, einen Titel, eine Beschreibungund Tags festzulegen. Dies sind auch genau die Parameter, die InterWeb beim Upload vom Benutzer erhalt.Daher kann einfach die createPost()-Methode aus der Bibsonomy-Bibliothek aufgerufen werden. Nun mussnurnoch ein Resource-Objekt erstellt und mit den notigen Daten zuruckgegeben werden.

Abschluss

Jetzt existieren alle benotigten Klassen. Noch kann InterWeb aber nicht auf sie zugreifen. Erst muss derService bekannt gemacht und einem Medientypen zugeordnet werden. Dazu werden in der Datei app/frontend/config/app.yml folgende Zeilen hinzugefugt bzw. geandert:

services:implemented:

#--------------------------------------------------------------------------------## BibSonomy (ID und Name) zur Liste der implementierten Services hinzufuegen: ##--------------------------------------------------------------------------------#

BibSonomy: BibSonomyBlogger: BloggerDelicious: DeliciousFacebook: FacebookFlickr: FlickrGroupMe: GroupMe!Ipernity: IpernityLastFm: last.fmSlideShare: SlideShareVimeo: VimeoYouTube: YouTube

mediatype:photos: [Ipernity, Flickr]videos: [Vimeo, YouTube]

#--------------------------------------------------------------------------------## Bibsonomy zum Medientyp Bookmarks hinzufuegen: ##--------------------------------------------------------------------------------#

bookmarks: [Delicious, BibSonomy]slideshows: [SlideShare]audio: [Ipernity]music: [LastFm]blogging: [Blogger]friends: [Flickr, LastFm, Delicious, SlideShare, YouTube, Facebook, Vimeo]

Listing 6.13: Abschließendes Hinzufugen zu den implementierten Services

Nun weiß InterWeb von BibSonomy und welche Aktionen es ausfuhren kann.

6.4 Ausblick

Die Integrationsplattform InterWeb kann in Zukunft erweitert und verbessert werden. Allen voran ist einvollstandiger Zugriff auf Ressourcen denkbar. So konnte man, neben dem Abruf und dem Upload, auchdas Loschen und Manipulieren von Ressourcen implementieren. Ein weiterer wichtiger Faktor sind Zugriffs-policies, die dem Benutzer ermoglichen festzulegen, auf welche Ressourcen von wem und unter welchenBedingungen zugegriffen werden kann [CKOZ09].Des Weiteren konnte der Webservice bei Antworten auf HTTP-Anfragen entsprechende HTTP-Response-Codes zuruckgeliefern, anhand derer der Client direkt einen Fehler erkennen kann. So konnte man einige

72


zuruckgelieferte Fehlercodes einsparen. Außerdem konnen weitere Reprasentationen angeboten werden. Dazuzahlen zum Beispiel RSS-Formate und RDF-Reprasentationen, die sich an bekannte Vokabulare wie denDublin Core halten. Daruber hinaus kann dem Client die Moglichkeit gegeben werden, die Reprasentionenuber HTTP Content Negotiation [FGM+99] anzufordern.Bei Abfragen nach Freunden konnte anhand der InterWeb-Benutzeraccount ein erstes User-Mapping durch-gefuhrt werden. Dazu konnen Ansatze, wie der in [CC08] beschriebene, implementiert und anhand der explizitbekannten Mappings evaluiert werden.Fur die Einbindung weiterer Services konnten die Schnittstellen generischer gestaltet werden, so dass neueServices, wie Bibliotheken, nach dem Plug-and-Play-Prinzip hinzugefugt werden konnen. Dazu musste dieKonfiguration der Services (also die Informationen, was fur Funktionalitaten ein Service anbietet), anstattin einer zentralen Konfigurationsdatei, dezentral im jeweiligen ”Modul“ des Services gespeichert werden.Außerdem sind Mechanismen moglich, bei denen Clients selber entscheiden konnen, welche Services sieverwenden wollen. Genauso kann dem Benutzer eine Moglichkeit gegeben werden, die Services fur einzelneMedientypen zu priorisieren, falls zum Beispiel die Fotos zu Ipernity anstatt zu Flickr gesendet werdensollen.

73

7 Einsatz in LearnWeb2.0


LearnWeb2.0 ist eine Plattform, die im Rahmen des TENCompetence Projektes am Forschungszentrum L3Sentwickelt wird. TENCompetence ist ein von der europaischen Union gefordertes Projekt mit 15 Partnernaus 9 verschiedenen Landern. Ziel des Projektes ist es, ein lebenslanges Lernen mit geeigneten Technikenzu unterstutzen [TEN09]. Mit LearnWeb2.0 sollen Lehrende und Lernende in der Suche, Verteilung undVerwaltung von Web 2.0 Ressourcen unterstutzt werden [AMNZ09]. Dabei setzt LearnWeb2.0 den WebserviceInterWeb als Integrationsplattform fur Web 2.0 Services ein. Im Anhang D befindet sich die PHP-Bibliothek,die LearnWeb2.0 zum Zugriff auf InterWeb verwendet.Wenn sich ein Benutzer bei LearnWeb2.0 registriert, wird automatisch ein Benutzeraccount bei InterWebangelegt. Der Benutzer kann dann, wie in Abbildung 7.1 gezeigt, auf der Oberflache von LearnWeb2.0 dieAutorisierung mit den Web 2.0 Services durchfuhren.

Abbildung 7.1: Autorisierung in LearnWeb2.0

Abbildung 7.2: Eigene Ressourcen in LearnWeb2.0

Um eine Liste der verfugbaren Webservices zu erhalten, wird der Endpunkt users/[username]/services auf-gerufen. Mit dieser Liste wird der Autorisierungsstatus fur den Benutzer ubermittelt, so dass LearnWeb2.0

74


bei der Darstellung zu jedem Service Funktionen zur Verfugung stellen kann, mit denen eine Autorisierungdurchgefuhrt oder zuruckgenommen werden kann. Ist keine Autorisierung vorhanden, kann anhand der Unter-scheidung zwischen Login- und Token-basierten Verfahren dynamisch entschieden werden, ob dem Benutzerein Eingabeformular oder ein einfacher Button angezeigt werden soll, um die Autorisierung durchzufuhren.In LearnWeb2.0 gibt es einen sogenannten Virtual Working Space (Abbildung 7.2). In diesem kann derBenutzer seine Ressourcen bei den Web 2.0 Services abrufen und Suchen auf diesen durchfuhren. Dazuintegriert es den Endpunkt users/[username]/resources von InterWeb.

Abbildung 7.3: Liste der Freunde in LearnWeb2.0

Außerdem ruft LearnWeb2.0 die Liste der Freunde eines Benutzers ab und stellt diese mit Namen und Fotosdar. Daruberhinaus gleicht es die Web 2.0 Benutzeraccounts mit den LearnWeb2.0 Benutzeraccounts ab, umso ein ubergeordnetes Social Network aufzubauen, in dem die Web 2.0 Accounts miteinander verknupft sind.

Abbildung 7.4: Ressourcensuche in LearnWeb2.0

Des Weiteren greift LearnWeb2.0 auf die Suche nach Ressourcen von InterWeb zu (Abbildung 7.4). Es kannRessourcen zu InterWeb senden, Gruppen abrufen, etc.Wird ein weiterer Web 2.0 Service zu InterWeb hinzugefugt, ist dieser automatisch, ohne weitere Anpassun-gen, auch in LearnWeb2.0 verfugbar.Die Anwendung LearnWeb2.0 fordert einfach die Daten von einem einzigen Webservice (InterWeb) an unddieser liefert sie dann in einer einheitlichen Form, in der sie weiter verarbeitet werden konnen. Wo dieseDaten her kommen, wird LearnWeb2.0 zwar mitgeteilt, es muss sich aber prinzipiell nicht darum kummern.

75

8 Beschreibung der Firefox Extension


In diesem Kapitel soll eine weitere Client-Anwendung vorgestellt werden, mit der auf InterWeb zugegriffenwird. Dabei handelt es sich um eine Extension fur den Webbrowser Firefox 3. Firefox Extensions erweiterndie Funktionalitat des Firefox Browsers. Man erkennt sie an ihrer Dateiendung .xpi. Dies sind ZIP-Dateien, indenen eine Dateistruktur aus JavaScript- und XUL-Dateien enthalten ist. Die XML User Interface Language(XUL) ist ein XML-Dialekt, mit dem Benutzeroberflachen entworfen werden konnen [Moz08]. Die Mozilla-Anwendungen Firefox und Thunderbird sind selbst auch in XUL geschrieben.Dieser Client dient hauptsachlich dem Upload von Medienobjekten zu InterWeb. Er integriert aber auch dieallgemeine Suchfunktion und kann zum Abrufen von Freunden genutzt werden. Dabei integriert sich ein Iconin die Statusleiste des Webbrowsers, uber das die Funktionen von InterWeb aufgerufen werden konnen. ImAnhang D befindet sich die JavaScript-Bibliothek, die fur den Zugriff auf InterWeb verwendet wird.

Abbildung 8.1: Icon der Firefox Extension

8.1 Autorisierung

Zur Autorisierung wird der Menupunkt ”Authorize“ ausgewahlt und damit der Autorisierungsprozess inGang gesetzt. Dabei offnet sich ein Browsertab, in dem der Benutzer die Firefox Extension fur den Zugriffauf InterWeb autorisieren muss. Hat er dies getan, schließt er den Browsertab. Damit werden die weiterenFunktionen der Firefox Extension freigeschaltet.Will der Benutzer seine Autorisierung zurucknehmen, klickt er im selben Menu auf ”Unauthorize“.

Abbildung 8.2: Autorisierung in der Firefox Extension

76


8.2 Suche

Will der Benutzer eine Suche durchfuhren, klickt er im Menu der Firefox Extension auf Search. Dadurchwird ein Suchformular geoffnet, uber das er seine Suche feingranular nach den Parametern von InterWebeinstellen kann. Wenn der Benutzer die Suche abschickt, fuhrt InterWeb diese fur ihn durch und gibt einenAtom-Feed zuruck, der in einem neuen Browsertab angezeigt wird.

Abbildung 8.3: Suche in der Firefox Extension

8.3 Upload

Zum Upload setzt die Firefox Extension Drag & Drop ein. Dabei werden Dateien, Textschnipsel, HTML-Schnipsel und URLs in beliebigen Anwendungen markiert und direkt auf das InterWeb-Icon in der Statusleistegezogen. Fahrt man ein solches Element mit der Maus uber das Icon, verfarbt es sich. Lasst man es nunfallen, offnet sich ein Formular, in dem Werte wie Titel, Beschreibung und Tags eingegeben werden konnen.Außerdem ist es moglich, eine Gruppe auszuwahlen, zu der die Ressource nach dem Upload hinzugefugtwerden soll. Es kann aber auch eine neue Gruppe erstellt werden.

Abbildung 8.4: Upload in der Firefox Extension

Durch dieses Feature mussen sich die Benutzer nicht mehr mit den Weboberflachen der einzelnen Web 2.0Services beschaftigen, sondern konnen ihre Ressourcen einfach per Drag & Drop zum passenden Servicesenden.

77

9 Zusammenfassung

9 Zusammenfassung

Zu Beginn dieser Arbeit wurden Grundlagen zum Web 2.0 und zum programmierbaren Web vorgestellt. ImAnschluss daran wurden die Autorisierungs- und Authentifizierungsverfahren verglichen, die von Web 2.0Diensten angeboten werden. Dabei hat sich herausgestellt, dass OAuth und Interrupted-Token-Request-Verfahren fur die Autorisierung sicherer und besser geeignet sind, als Login-basierte Verfahren. Anhandeines konzeptionellen Frameworks wurden dann zehn Web 2.0 Dienste und ihre APIs analysiert und diePlattform InterWeb vorgestellt, die die Funktionalitaten dieser Web 2.0 Dienste integriert. Danach wurdendie Client-Anwendungen LearnWeb2.0 und die InterWeb Firefox Extension beschrieben.Die wesentlichen Beitrage dieser Arbeit sind:

1. Ein konzeptionelles Framework, das zur Charakterisierung und Einordnung von Web 2.0 Diensten undihren APIs geeignet ist.

2. Eine API-Analyse von zehn Web 2.0 Diensten, bei der das konzeptionelle Framework verwendet wird.

3. Die Integrationsplattform InterWeb, die die Funktionalitaten dieser Web 2.0 Dienste integriert.

4. Eine Firefox Extension, die es Benutzern ermoglicht, mit wenigen Klicks (”Drag & Drop“-Prinzip)Daten zu veroffentlichen.

Das konzeptionelle Framework wurde konstruiert, um Web 2.0 Dienste zu charakterisieren. Es kann eingesetztwerden, um beliebige Web 2.0 Dienste und ihre APIs in einer strukturierten Form zu analysieren. Es gehtdabei uber die bisherigen Strukturierungsansatze, wie die von ProgrammableWeb.com, hinaus.In der API-Analyse wurde das konzeptionelle Framework dazu eingesetzt, um zehn Web 2.0 Dienste zuanalysieren. Die Analyse ergab, dass sich viele Services als REST oder REST-konform bezeichnen, obwohles sich um REST-RPC-Hybride Webservices handelt. In den wenigsten Fallen werden die HTTP-Methodenso verwendet, wie es von der HTTP-Spezifikation vorgesehen ist. Einzige Ausnahme in dieser Analyse sinddie APIs von GroupMe! und jenen Diensten, die eine API auf Basis der Google Data API einsetzen. Diemeisten Services implementieren Sequential-Token-Request- und/oder Interrupted-Token-Request-Verfahrenfur die Autorisierung durch den Benutzer. XML und JSON sind die Standardformate fur zuruckgelieferteReprasentationen.Auf Basis der Erkenntnisse der API-Analyse wurde die Plattform InterWeb implementiert. Die Plattformintegriert die Daten und Funktionalitaten von zehn Web 2.0 Diensten und bietet ihre Daten und Funktiona-litaten selbst als Webservice an. Dieser Webservice stellt somit eine einheitliche Schnittstelle zu den Web 2.0Diensten dar. Dabei werden unter anderem folgende Features bereitgestellt:

• Suche nach Ressourcen bei zehn verschiedenen Web 2.0 Diensten.

• Upload von Ressourcen verschiedenster Medientypen, wie Videos, Fotos, Bookmarks oder Textschnip-seln.

• Ressourcenmanagement zur Verwaltung der eigenen Web 2.0 Ressourcen.

• Aggregation der Social Networks der verschiedenen Dienste.

78

9 Zusammenfassung

Zusatzlich wurde eine Extension fur den Webbrowser Firefox entwickelt. Diese Extension greift auf denWebservice von InterWeb zu. Ihre Hauptfunktion ist der Upload von Ressourcen, die uber einen einfachen

”Drag & Drop“-Mechanismus vom Rechner des Benutzers oder aus dem Internet bei beliebigen Servicesveroffentlicht werden konnen.Die große Menge an APIs, die mittels eines konzeptionellen Frameworks strukturiert analysiert und in der In-tegrationsplattform InterWeb eingebunden wurden, sind ein Alleinstellungsmerkmal dieser Arbeit. InterWebkann als großes Mashup bezeichnet werden, wobei die meisten Mashups nur zwei bis drei APIs integrierenund nicht wie hier zehn APIs, mit der Option auf beliebig viele weitere.Die Plattform und die Extension ermoglichen die Beantwortung weiterer Forschungsfragen. Zum Beispielkann damit das Tagging-Verhalten uber die Grenzen einzelner Medientypen und Web 2.0 Dienste hinaus un-tersucht werden. Ferner kann etwa untersucht werden, welche Medientypen bei welcher Art von Suchanfragenbevorzugt ausgewahlt werden.Es wurde eine Plattform geschaffen, die dazu beitragt, dass das programmierbare Web realer wird. FurSuchanfragen gibt es nun eine einheitliche Schnittstelle: Anstatt die heterogenen APIs von zehn verschiedenenWeb 2.0 Diensten zu nutzen, genugt eine einzige Suchanfrage bei der Integrationsplattform InterWeb. Zudemmussen Freundesnetzwerke nicht neu erstellt und dupliziert werden. Hierbei gilt es, weitere Forschungsfragenim Bereich des User-Mappings zu klaren: Welche Verfahren sind am besten dazu geeignet zu ermitteln, obder Benutzer A bei Service 1 gleich dem Benutzer B bei Service 2 ist?LearnWeb2.0 benutzt InterWeb als Middleware um eLearning zu unterstutzen. Genauso ist es moglich, In-terWeb fur andere Anwendungszwecke zu verwenden. Dies konnte sogar so weit vorangetrieben werden, dassman InterWeb als eine Art Content Management System realisiert, das einfach an beliebige Anwendungsfalleangepasst werden kann.

79

A Bewertungsbogen zu Kapitel 4

A Bewertungsbogen zu Kapitel 4Service

API

Stand

Architektur-Stil 2 REST-konform 2 RPC 2 REST-RPC-Hybrid

Methodeninformation 2 HTTP-Methode 2 URI 2 Anfrageparameter

Technologie 2 REST-ahnlich 2 XML-RPC 2 SOAP

2 Sonstige:

Antwortformate 2 XML 2 JSON 2 Sonstige:

Anwendungsauthentifizierung

mehrere Anwendungen moglich 2 Ja 2 Nein

offiziell unterstutzte Bibliotheken 2 PHP 2 Java 2 .NET 2 Sonstige:

Feed-Interface

Stand

Antwortformate 2 RSS 2 Atom 2 Sonstige:

abrufbare Daten

Zugriff auf private Daten 2 Ja 2 Nein

Authentifizierung


Art des Verfahrens 2 Login-basiert 2 Token-basiert

Verfahren 2 Sequential-Token-Request 2 Interrupted-Token-Request

2 Login-Token-Exchange 2 Manual-Token-Input 2 OAuth

2 HTTP Basic Authentication 2 Sonstiges:

Parameter

Token speicherbar 2 Ja 2 Nein 2 -

Callback-URL dynamisch wahlbar 2 Ja 2 Nein 2 -

Datenzugriff

Hauptmedientyp

abrufbare Daten

Zugriffsbeschrankung

Filter bei der Suche

Argumente fur den Upload

80

B API Documentation

B API Documentation

Services-Terminology

In this documentation "Service" always means "Web 2.0 Service" (like Flickr, YouTube, etc.). When Inter-Web as a service is meant, we will use the word "InterWeb".

API Call

To make an API call send an HTTP Message to http://semweb.kbs.uni-hannover.de/~tristan/api/. Addthe path defined in the endpoint sections.The response format you wish will be added like the corresponding file format (ex. search.xml or search.json).The allowed response formats are declared in the "Overview".With every authenticated call you have to provide the parameters:• iw_consumer_key: Your Consumer Key.• iw_token: Users token.• iw_signature: The signature as calculated below.

Create Signature

A signature is used to verify the authentication of your application on InterWeb.The signature is a MD5 encrypted string that starts with the consumer secret, followed by an alphabeticallyordered list of request parameters.The request parameters contain the iw_consumer_key and iw_path (the path to the api endpoint after "api/")and if iw_path is not auth/request_token the iw_token of the user.Remember not to include the callback parameter (in case of the link to the authorization page) and the dataparameter (in case of media upload).

Example

Your ConsumerKey (iw_consumer_key) is 1234,your ConsumerSecret (iw_consumer_secret) is abcd,and the Token (iw_token) is foobar.You want to call the api on http://semweb.kbs.uni-hannover.de/~tristan/api/users/default/friends.xml

so the Path (iw_path) is users/default/friends

With:

iw_consumer_secret + "iw_consumer_key" + iw_consumer_key + "iw_path"+ iw_path + "iw_token" + iw_token

the signature string will be:

abcdiw_consumer_key1234iw_pathusers/default/friendsiw_tokenfoobar}

81

B API Documentation

Remember that the parameters are alphabetically ordered.

Overview

HTTP Response format

Endpoint Method Auth XML JSON Atom

search

Media Search

GET X X X

search/[QueryID]

Retrieve Standing Query

GET X X X

users/default/uploads

Media Upload

GET X X X

users

Register new User

POST X X X

users/[username]

Retrieve User Info

GET X X

users/[username]/uploads

Retrieve Users Uploads

POST X X X

users/[username]/friends

Retrieve Users Friends

GET X X X

users/[username]/resources

Retrieve Users Resources

GET X X X

users/[username]/resources

Filter Users Resources

GET X X X

users/[username]/groups

Retrieve Users Groups

GET X X

users/default/groups

Create Group

POST X X X

users/[username]/services

Retrieve authorization information by user for all Services

GET X X X

users/[username]/services/[ServiceID]

Retrieve authorization information by user for a specific Service

GET X X

users/[username]/services/[ServiceID]/auth

Authorize on Service

POST X

users/[username]/services/[ServiceID]/auth

Revoke Authorization on Service

DELETE X X X

services

Retrieve implemented Services

GET X X X

auth/request token

Authorization

GET X X X

auth/access token

Authorization

GET X X X

auth/authorize

Authorization

GET X

82

B API Documentation

Error-Codes

Code Message

Errors on Authentication

101 No consumer key given

102 No token given

103 No signature given

104 Invalid signature

105 No account for this token

106 Token is not authorized

107 User does not exist

108 Authentication on service failed

109 Service unknown

110 User already exist

Errors on Search

201 Query string not set

202 No media type chosen

203 Unknown media type

204 Invalid format of date from

205 Invalid format of date till

206 Standing query does not exist

Errors on Upload

301 No data given

302 No service for this file type

303 No service account for this file type

304 Upload to service failed

305 File type not recognized by service

306 Upload limit exceeded

307 Service currently unavailable

Various Errors

999 Undefined error

Authorization

To let your application act on users behalf, he has to authorize your application. To do this, follow thesesteps:

Step 1. Retrieve a Request Token

Send a request to the following path to retreive the request token.

• Path: auth/request_token• HTTP-Method: GET• Response format: xml, json• Description: Returns the Request Token.• Parameters: none

83

B API Documentation

Step 2. Link to Authorization Page

Provide the user a link to the following URL or redirect users browser to it:

http://semweb.kbs.uni-hannover.de/~tristan/api/auth/authorize

with the following parameters:• iw_token: the Request Token from the previous step• iw_consumer_key: Your Consumer Key• iw_signature: Signature as described in ”Create Signature“• callback: (optional) A callback URL the user will be redirected to, when he authorized your application.

Note: Do not include the callback URL into the signature.If an Callback URL is given, it will be called and the Access Token will be attached to the query string.Then you can skip Step 3.If no Callback URL is given you have to detect that the user authorized your application and go on withStep 3.

Step 3. Exchange Request Token with Access Token

Now you can exchange the request token with an Access Token. Save this token in your Application, it willbe used to sign users requests.

• Path: auth/access_token• HTTP-Method: GET• Response format: xml, json• Description: Returns the Access Token.• Parameters:

– request token: the Request Token from Step 1

Endpoints

Register User

With this endpoint you can register a new user to InterWeb.Please see ”User Info“, to check if the chosen username is free.Simply send an HTTP-POST request to the following path.This request must send iw_consumer_key and iw_signature containing username and password.

• Path: users• HTTP-Method: POST• Response format: xml, json• Description: Registers a new users and returns his AccessToken.• Parameters:

– username: users username– password: users password

84

B API Documentation

Media Search

Use this endpoint to search for media objects.If the request is authenticated a new standing query will be build.If the request is not authenticated the result will be the result of a saved standing query. If the standingquery not exists the result will be an empty set.In the response is a ID and a link included that leads to the corresponding standing query, you can use with

”Retrieve Standing Query“.Simply send an HTTP-GET request to the following path.

• Path: search• HTTP-Method: GET• Response format: xml, json, atom• Description: Search for media objects.• Parameters:

– q: the query string (required)– search in: where to search (possible values: text, tags) (default: text). If tags chosen, the

query string should be a space-separated list of tags.– media types: comma-separated list of media types to search for (possible values: photos,

videos, bookmarks, slideshows, audio, music) (required)– date from: min creation date of object (if supported by service) (format as mysql datetime:

’YYYY-MM-DD HH:MM:SS’)– date till: max creation date of object (if supported by service) (format as mysql datetime:

’YYYY-MM-DD HH:MM:SS’)– ranking: sets how the called service should rank the results (possible values: relevance, newest,

interestingness) (default: relevance)– number of results: number of results returned per service (default: 10)

Retrieve Standing Query

This endpoint is used to retrieve a standing query.Simply send an HTTP-GET request to the following path. [QueryID] is the ID returned by the ”MediaSearch“.

• Path: search/[QueryID]• HTTP-Method: GET• Response format: xml, json, atom• Description: Returns the standing query.• Parameters: none

Media Upload

Use this endpoint to upload files / strings to InterWeb to publish them to Web 2.0 services.Supported file types are:• photos: (JPG, PNG, BMP, GIF, TIFF)• audio: (MP3, OGG, WAV)

85

B API Documentation

• slideshows: (PPT, ODP (OpenOffice.org Presentation))• videos: (MPG, MP4, MOV, QT, 3GP, WMV, M4V, AVI)

You can also send strings (text snippets, URLs) to InterWeb.Simply send an HTTP-POST request to the following path.This request must be authenticated.

• Path: users/default/uploads• HTTP-Method: POST• Response format: xml, json• Description: Uploads a media object• Parameters:

– data: data to upload (required)– title: title for the object– description: description for the object– tags: a comma-separated list of tags, describing the object– is private: 0 if public, 1 if private (default: 0)– group: The ID or the URL of GroupMe!-Group, the resource will be added to. The calling

user must be the author of the group.

Create Group

This endpoint creates a new group at GroupMe! on behalf of the calling user.Simply send an HTTP-POST request to the following path.This request must be authenticated.

• Path: users/default/groups• HTTP-Method: POST• Response format: xml, json• Description: Creates a group at GroupMe!• Parameters:

– title: the title of the group (required)– description: the description of the group– tags: comma-separated list of tags for the group

User Info

This endpoint returns the username, if the user exists. An Error 107 otherwise.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantinformation for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]• HTTP-Method: GET• Response format: xml, json• Description: Returns the username, if user exists.• Parameters: none

86

B API Documentation

Retrieve Users Friends

This endpoint returns all friends of the user, retrieved by the connected Web 2.0 services.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/friends• HTTP-Method: GET• Response format: xml, json, atom• Description: Returns a list of all friends of a user.• Parameters: none

Retrieve Users Resources

This endpoint returns all resources of the user, retrieved by the connected Web 2.0 services.For filtering these resources see ”Filter Users Resources“.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/resources• HTTP-Method: GET• Response format: xml, json, atom• Description: Returns a list of all resources of a user.• Parameters: none

Filter Users Resources

This endpoint returns all resources of the user, retrieved by the connected Web 2.0 services, filtered by severalparameters.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/resources• HTTP-Method: GET• Response format: xml, json, atom• Description: Search for media objects of a specific user.• Parameters:

– q: the query string (required)– search in: where to search (possible values: text, tags) (default: text). If tags chosen, the

query string should be a space-separated list of tags.– media types: comma-separated list of media types to search for (possible values: photos,

videos, bookmarks, slideshows, audio, music) (required)– date from: min creation date of object (if supported by service) (format as mysql datetime:

’YYYY-MM-DD HH:MM:SS’)– date till: max creation date of object (if supported by service) (format as mysql datetime:

’YYYY-MM-DD HH:MM:SS’)

87

B API Documentation

– number of results: number of results returned per service (default: 10)

Retrieve Users Groups

This endpoint returns all groups the user has at GroupMe!.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/groups• HTTP-Method: GET• Response format: xml, json• Description: Returns a list of users groups.• Parameters: none

Retrieve Users Uploads

This endpoint returns all resources the user has uploaded via InterWeb.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/uploads• HTTP-Method: GET• Response format: xml, json, atom• Description: Returns all resources, that were uploaded by the user via InterWeb.• Parameters: none

Retrieve authorization information by user for all Services

This endpoint retrieves a list of all services connected to InterWeb, in addition to information about the aut-horization status for this user. If the authentication does not work, information is given how the authorizationprocess can be started.For further information about the authorization itself, see ”Authorize on Service“.Simply send an HTTP-GET request to the following path. [username] is the username of the user, you wantthe information for. You can also use ”default“ as username and do an authenticated call.

• Path: users/[username]/services• HTTP-Method: GET• Response format: xml, json• Description: Retrieves the list of implemented services, with information about the authorization

status of the calling user.• Parameters: none

88

B API Documentation

Retrieve authorization information by user for a specific Service

This endpoint returns authorization information about a specific service.For further information about the authorization with a service see: ”Authorize on Service“.Simply send an HTTP-GET request to the following path.[username] is the username of the user, you want the information for. You can also use ”default“ as usernameand do an authenticated call. [ServiceID] is the ID of the service. You can get this ID by calling the ServicesList or the Users Authorization Info endpoint.

• Path: users/[username]/services/[ServiceID]• HTTP-Method: GET• Response format: xml, json• Description: Retrieves information about the authorization status of a user for a specific service.• Parameters: none


This endpoint returns a list of the implemented services. In addition to all services it is specified how theauthorization with this service works. For further information about the authorization with a service see:

”Users Authorization Info“.Simply send an HTTP-GET request to the following path.

• Path: services• HTTP-Method: GET• Response format: xml, json, atom• Description: Retrieves the list of implemented services.• Parameters: none


Authorize on ServiceTo let a user authorize InterWeb on a Web 2.0 Service, you must provide him a form with a HTTP-POSTrequest to:

http://semweb.kbs.uni-hannover.de/~tristan/api/users/default/services/[ServiceID]/auth

Because the user has to interact with the service, you can not do an API call.When calling ”services“ as described in ”Services List“ you get a list of all implemented services. With everyservice is declared how the authorization works. This way you can decide dynamically which form you haveto show the user.With every form you have to send the parameters iw_consumer_key, iw_token and the signature iw_signature.There are two types of authorization depending on the service:• token: simply send the form to the declared URL.• login: with the parameters defined in the auth info, you have to send the form to the given URL.

In most cases these are username and password. You do not need to include these parameters to thesignature as you don’t know them unless the user has typed them into the form.

89

B API Documentation

Revoke Authorization on Service

With this endpoint you can remove the authorization of the user by the service.Simply send an HTTP-DELETE request to the following path, where [ServiceID] is the ID of the service.You can get this ID by calling the Services List or the Users Authorization Info endpoint.This request must be authenticated.

• Path: users/default/services/[ServiceID]/auth• HTTP-Method: DELETE• Response format: xml, json• Description: Removes all authorization information about the service.• Parameters: none

90

C Quellcode zur Beispielerweiterung


Autorisierung

<?class BibSonomy_ApiAuth implements ApiAuth {

private $type = ’login’;

private $requiredParameters = array(array(’name’ => ’username’, ’type’ => ’text’),array(’name’ => ’apikey’, ’type’ => ’password’)

);

public function __construct() {}

public function getType() {return $this->type;

}

public function getRequiredParameters() {return $this->requiredParameters;

}

public function auth($user, $params) {

$service_properties = $user->getProfile()->getServiceProperties();

$service_properties["bibsonomy.username"] = $params[’username’];$service_properties["bibsonomy.apikey"] = $params[’apikey’];

if ($this->check($service_properties)) {

$user->getProfile()->setServiceProperties($service_properties);$services = $user->getProfile()->getServices();$services[’BibSonomy’] = ’BibSonomy’;$user->getProfile()->setServices($services);$user->getProfile()->save();

} else {return array(’error’ => 108);

}

}

public function check($serviceProperties) {

if (isset($serviceProperties[’bibsonomy.username’])&& isset($serviceProperties[’bibsonomy.apikey’])) {

$bFactory = new BibSonomyFactory();$b = $bFactory->produce(

$serviceProperties[’bibsonomy.username’],$serviceProperties[’bibsonomy.apikey’]

);

91


try {$result = $b->getPublicPosts(’bookmark’, NULL, NULL, 0, 1);

} catch (Exception $e) {return false;

}

return true;}

return false;}

public function unauth($user, $params) {

$service_properties = $user->getProfile()->getServiceProperties();

unset($service_properties["bibsonomy.username"]);unset($service_properties["bibsonomy.apikey"]);

$user->getProfile()->setServiceProperties($service_properties);

$services = $user->getProfile()->getServices();

if (array_key_exists(’BibSonomy’, $services))unset($services[’BibSonomy’]);

$user->getProfile()->setServices($services);$user->getProfile()->save();

}

public function getUserId($serviceProperties) {

if (isset($serviceProperties[’bibsonomy.username’]))return $serviceProperties[’bibsonomy.username’];

elsereturn ’’;

}

}?>

Listing C.1: Autorisierungsklasse fur BibSonomy

Suche

<?class BibSonomy_ApiQuery implements ApiQuery {

private $userProfile;private $media_type;

public function __construct($media_type, sfGuardUserProfile $userProfile) {

$this->media_type = $media_type;$this->userProfile = $userProfile;

}

public function search(Query $query, $authenticated = false, $own = false) {

$bFactory = new BibSonomyFactory();

92


$b = $bFactory->produce($this->userProfile->getServiceProperty(’bibsonomy.username’), $this->userProfile->getServiceProperty(’bibsonomy.apikey’));

if (!$authenticated)return array();

$searchoptions = $this->generateSearchOptions($query, $own);

try {$results = $b->getPublicPosts(’bookmark’, $searchoptions[’tags’],

$searchoptions[’username’], 0, $searchoptions[’end’]);} catch (Exception $e) {

return array(’error’ => 999);}

return $this->parseResults($results);}

private function parseResults($api_results) {

$results = array();foreach($api_results as $api_result) {

$result = new QueryResult();

$result->setService(’BibSonomy’);$result->setServiceId($api_result->getBookmark()->getIntraHash());$result->setTitle($api_result->getBookmark()->getTitle());$result->setDescription($api_result->getDescription());$result->setType($this->media_type);$result->setUrl($api_result->getBookmark()->getURL());$result->setDate( strftime(’%Y-%m-%d %H:%M:%S’, $api_result->getPostingdate()));

array_push($results, $result);}return $results;

}

private function generateSearchOptions($query, $own) {

$searchoptions = array();

$searchoptions[’tags’] = $query->getTags();

if ($query->getNumberOfResults() == 0) {$searchoptions[’end’] = 500;

} else {$searchoptions[’end’] = $query->getNumberOfResults();

}

if ($own) {$searchoptions[’username’] = $this->userProfile->getServiceProperty(’bibsonomy.username’);

} else {$searchoptions[’username’] = NULL;

}

return $searchoptions;}

}?>

Listing C.2: Suchhandlerklasse fur BibSonomy

93


Upload

<?class BibSonomy_ApiUploader implements ApiUploader {

private $userProfile;

public function __construct(sfGuardUserProfile $userProfile) {$this->userProfile = $userProfile;

}

public function upload($params) {$service_params = array(

’url’ => $params[’data’],’title’ => urlencode($params[’title’]),’description’ => urlencode($params[’description’]),’tags’ => $params[’tags’]);

$bFactory = new BibSonomyFactory();$this->b = $bFactory->produce($this->userProfile->getServiceProperty(’bibsonomy.username’),

$this->userProfile->getServiceProperty(’bibsonomy.apikey’));

$this->b->createPost($service_params[’url’], $service_params[’title’], $service_params[’description’], $service_params[’tags’]);

return $this->parseResult(null, $params);}

private function parseResult($api_result, $params) {

if ($this->b->getStatus() == 1){$resource = new iwResource();$resource->setUserId($this->userProfile->getUserId());$resource->setService(’BibSonomy’);$resource->setTitle($params[’title’]);$resource->setDescription($params[’description’]);$resource->setTags($params[’tags’]);$resource->setType($params[’media_type’]);$resource->setUrl($params[’data’]);$resource->save();return $resource;

}else {

return array(’error’ => 999);}

}}?>

Listing C.3: Uploadhandlerklasse fur BibSonomy

94

D Bibliotheken fur InterWeb


PHP-Bibliothek

<?class InterWeb {

private $consumer_key;private $consumer_secret;private $token;private $interwebApiURL = "http://semweb.kbs.uni-hannover.de/~tristan/api/";private $interwebURL = "http://semweb.kbs.uni-hannover.de/~tristan/";

public function __construct($consumer_key, $consumer_secret, $token = null) {$this->consumer_key = $consumer_key;$this->consumer_secret = $consumer_secret;$this->token = $token;

}

public function getConsumerKey() {return $this->consumer_key;

}

public function getToken() {return $this->token;

}

public function getInterWebAPIUrl() {return $this->interwebApiURL;

}

public function delete($path, $params = array(), $authenticated = false, $format = "json") {

$url = $this->buildGetUrl($path, $params, $authenticated, $format);

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "DELETE");curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 30);curl_setopt($ch, CURLOPT_TIMEOUT, 30);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$response = curl_exec($ch);curl_close ($ch);

return $response;}

public function get($path, $params = array(), $authenticated = false, $format = "json") {

$url = $this->buildGetUrl($path, $params, $authenticated, $format);$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 30);

95


curl_setopt($ch, CURLOPT_TIMEOUT, 30);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$response = curl_exec($ch);curl_close ($ch);

return $response;}

public function post($path, $params = array(), $has_file = false, $authenticated = false,$format = "json") {

if ($authenticated) {$params[’iw_token’] = $this->token;

}

$params[’iw_consumer_key’] = $this->consumer_key;

$params[’iw_signature’] = $this->buildSignature($path, $params);

$url = $this->interwebApiURL . $path . "." . $format;

$ch = curl_init();

if ($has_file) {$file = $params[’data’];unset($params[’data’]);curl_setopt($ch,CURLOPT_BINARYTRANSFER,1);curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);curl_setopt($ch,CURLOPT_INFILESIZE,filesize($file));$fp=fopen($file,’rb’);curl_setopt($ch,CURLOPT_INFILE,$fp);$params[’data’]=’@’.$file;

}curl_setopt($ch, CURLOPT_URL, $url);curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 30);curl_setopt($ch, CURLOPT_TIMEOUT, 30);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);curl_setopt($ch, CURLOPT_POST, 1);curl_setopt($ch, CURLOPT_POSTFIELDS, $params);

$response = curl_exec($ch);

$error = curl_error($ch);curl_close ($ch);return $response;

}

public function buildGetUrl($path, $params = array(), $authenticated = false, $format = "json"){

if ($authenticated) {$params[’iw_token’] = $this->token;

}

$params[’iw_consumer_key’] = $this->consumer_key;$params[’iw_signature’] = $this->buildSignature($path, $params);

$url = $this->interwebApiURL . $path . "." . $format;$url .= "?";

foreach ($params as $key => $value) {$url .= $key . "=" . $value . "&";

}return $url;

96


}

public function buildSignature($path, $params = array()) {$params[’iw_path’] = $path;ksort($params);

$sig = $this->consumer_secret;foreach ($params as $key => $value) {

if ($key != "data")$sig .= $key . $value;

}return md5($sig);

}

public function getRequestToken() {$response = $this->get("auth/request_token");return json_decode($response, true);

}

public function getAuthorizeURL($token) {$params[’iw_token’] = $token;$params[’iw_consumer_key’] = $this->consumer_key;$params[’iw_signature’] = $this->buildSignature("auth/authorize", $params);$params[’callback’] = urlencode(’http://’. $_SERVER[’SERVER_NAME’] . $_SERVER[’REQUEST_URI’])

;

$url = $this->interwebApiURL . "auth/authorize";

$url .= "?";

foreach($params as $key => $value) {$url .= $key . "=" . $value . "&";

}

return $url;}

public function getAccessToken($token) {$params[’iw_token’] = $token;$response = $this->get("auth/access_token", $params);return json_decode($response, true);

}

}?>

97


JavaScript-Bibliothek

function InterWebApiClient(consumer_key, consumer_secret) {this.consumer_key = consumer_key;this.consumer_secret = consumer_secret;this.token = null;this.interweb_url = "http://semweb.kbs.uni-hannover.de/~tristan/";this.interweb_api_url = "http://semweb.kbs.uni-hannover.de/~tristan/api/";

this.get = function(path, params, authenticated) {

var request = new XMLHttpRequest();var url = this.buildUrl(path, params, authenticated);

request.open("GET", url, false);request.setRequestHeader("Content-Type",

"application/x-www-form-urlencoded");request.send(null);

return eval("(" + request.responseText + ")");};

this.post = function(path, params, multipart, authenticated) {

if (authenticated) {params.iw_token = this.token;

}

params.iw_consumer_key = this.consumer_key;params.iw_signature = this.getSignature(path, params);

var boundaryString = "---------------------------26751be118";var boundary = ’--’ + boundaryString;var out = "";

if (multipart) {out += boundary + ’\r\n’;

for (k in params) {if (k != "data") {

var parameter = k;var value = params[k];out += ’Content-Disposition: form-data; name="’ + parameter + ’"’ + ’\r\n\r\n’;out += value + ’\r\n’;out += boundary + ’\r\n’;

}}

parameter = "data";value = params[parameter];out += ’Content-Disposition: form-data; name="data"; filename="’ + value.fileName + ’"\r\n

’;out += ’Content-Type: ’ + value.contentType + ’\r\n\r\n’;

// prefix stringvar prefixStringInputStream = Components.classes["@mozilla.org/io/string-input-stream;1"]

.createInstance(Components.interfaces.nsIStringInputStream);prefixStringInputStream.setData(out, out.length);

// binaryvar storageStream = Components.classes["@mozilla.org/storagestream;1"]

.createInstance(Components.interfaces.nsIStorageStream);storageStream.init(4096, value.data.length, null);

98

E Beiliegende CD und Installationshinweise

E Beiliegende CD und Installationshinweise

Auf der am hinteren Einband dieser Arbeit befestigten CD befinden sich folgende Inhalte:

• Diese Arbeit als druckfertiges PDF (600dpi)

• Diese Arbeit als PDF zur Bildschirmbetrachtung (72dpi)

• Die LaTeX-Quellen zu dieser Arbeit

• Die Integrationsplattform InterWeb (inkl. Datenbankschema fur die Installation)

• Die InterWeb Firefox Extension (inkl. Quellcode)

Installationshinweise fur InterWeb

Fur die Installation von InterWeb muss ein Webserver zur Verfugung stehen, der PHP (mindestens in derVersion 5.2) unterstutzt und uber eine Anbindung an eine MySQL-Datenbank verfugt. Dabei ist darauf zuachten, dass in der Konfiguration des Webservers die HTTP-Methoden DELETE und PUT erlaubt sind.Meistens sieht die Standardkonfiguration nur die Verwendung von GET und POST vor.Außerdem muss in PHP das Modul mcrypt aktiviert sein, da es zur Verschlusselung von Benutzeraccount-informationen verwendet wird.Dem auf der CD bereitgestellten InterWeb ist das Symfony Framework in der Version 1.2.3 beigelegt. Aufden Internetseiten von Symfony1 befinden sich detaillierte Installationsanleitungen, in denen beschrieben ist,wie es auf dem neuesten Stand gehalten werden kann.Zur Installation von InterWeb werden die Dateien aus dem Paket auf der CD per FTP auf den Webservergeladen. Zu beachten ist daruber hinaus, dass das Webroot-Verzeichnis des Webservers auf das Verzeichnisweb/ weisen muss. Dies bewirkt, dass die anderen Verzeichnisse, die zum Symfony Framework gehoren, nichtvon außen zugreifbar sind.In der Datei config/databases.yml mussen die Zugangsdaten zur MySQL-Datenbank vermerkt werden. Aufder CD befindet sich ebenfalls eine MySQL-Schemadatei, die mit einem MySQL-Client, wie zum BeispielPHPMyAdmin2, in die MySQL-Datenbank importiert werden muss.Optional konnen auch die Command Line Tools des Symfony Frameworks installiert werden, um damit dasModell und das Datenbankschema zu installieren. Dies ist beispielsweise notwendig, wenn keine MySQL-DBverwendet wird. Hierzu sei an dieser Stelle auf die ausfuhrliche Dokumentation von Symfony3 verwiesen.

1http://www.symfony-project.org/installation2http://www.phpmyadmin.net/3http://www.symfony-project.org/book/1 2/

101

Literaturverzeichnis


[AFH+07] Abel, Fabian, Mischa Frank, Nicola Henze, Daniel Krause, Daniel Plappert undPatrick Siehndel: GroupMe! – Where Semantic Web meets Web 2.0. In: Int. Semantic WebConference (ISWC 2007), November 2007.

[Alb07] Alby, Tom: Web 2.0. Konzepte, Anwendungen, Technologien. Hanser Verlag, Munchen, 2007.

[AMNZ09] Abel, Fabian, Ivana Marenzi, Wolfgang Nejdl und Sergej Zerr: Sharing Distribu-ted Resources in LearnWeb2.0. Technischer Bericht, L3S Research Center, Leibniz UniversityHannover, 2009.

[App09] Apple Inc.: Making a Podcast - iTunes RSS Tags, 2009. Verfugbar unter: http://www.apple.com/itunes/whatson/podcasts/specs.html#rss.

[BBC+98] Bosak, Jon, Tim Bray, Dan Connolly, Eve Maler, C. M. Sperberg-McQueen, Lau-

ren Wood und James Clark: Guide to the W3C XML Specification DTD, Version 2.1, 1998.Verfugbar unter: http://www.w3.org/XML/1998/06/xmlspec-report-v21.htm.

[BCHL09] Bos, Bert, Tantek Celik, Ian Hickson und Hakon Wium Lie: Cascading Style SheetsLevel 2 Revision 1 (CSS 2.1) Specification, 2009. Verfugbar unter: http://www.w3.org/TR/2009/CR-CSS2-20090423.

[Boa08] Board, DCMI Usage: DCMI Metadata Terms, 2008. Verfugbar unter: http://dublincore.org/documents/2008/01/14/dcmi-terms/.

[BPSM98] Bray, Tim, Jean Paoli und C. M. Sperberg-McQueen: Extensible Markup Language(XML) 1.0. W3C Recommendation 10-February-1998, 1998. Verfugbar unter: http://www.

w3.org/TR/1998/REC-xml-19980210.html.

[BPSM+08] Bray, Tim, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler und Francois Yer-

geau: Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C Recommendation 26 No-vember 2008, 2008. Verfugbar unter: http://www.w3.org/TR/2008/REC-xml-20081126/.

[CC08] Carmagnola, Francesca und Federica Cena: User identification for cross-system perso-nalisation. Information Sciences. Informatics and Computer Science Intelligent Systems Appli-cations, 2008.

[CCHZ08] Carl, Denny, Jorn Clausen, Marco Hassler und Anatol Zund: Mashups programmie-ren. O’Reilly, 1., Aufl. Auflage, 2008.

[CKOZ09] Coi, Juri Luca De, Philipp Karger, Daniel Olmedilla und Sergej Zerr: Using NaturalLanguage Policies for Privacy Control in Social Platforms. In: Workshop on Trust and Privacyon the Social and Semantic Web (SPOT), 2009.

[Cro82] Crocker, David H.: RFC 822 - Standard for the Format of ARPA Internet Text Messages,1982. Verfugbar unter: http://tools.ietf.org/html/rfc822.

102

http://www.apple.com/itunes/whatson/podcasts/specs.html#rss

http://www.apple.com/itunes/whatson/podcasts/specs.html#rss

http://www.w3.org/XML/1998/06/xmlspec-report-v21.htm

http://www.w3.org/TR/2009/CR-CSS2-20090423

http://www.w3.org/TR/2009/CR-CSS2-20090423

http://dublincore.org/documents/2008/01/14/dcmi-terms/

http://dublincore.org/documents/2008/01/14/dcmi-terms/

http://www.w3.org/TR/1998/REC-xml-19980210.html

http://www.w3.org/TR/1998/REC-xml-19980210.html

http://www.w3.org/TR/2008/REC-xml-20081126/

http://tools.ietf.org/html/rfc822


[Cro06] Crockford, Douglas: The application/json Media Type for JavaScript Object Notation(JSON), 2006. Verfugbar unter: http://www.ietf.org/rfc/rfc4627.txt.

[Dat08] DataPortability Communications Action Group: The DataPortability Project. Connect.Control. Share. Remix., 2008. Verfugbar unter: http://www.dataportability.org/.

[Del09] Delicious: Delicious Tools, 2009. Verfugbar unter: http://delicious.com/help/tools.

[Fac09a] Facebook: Facebook - Statistics, 2009. Verfugbar unter: http://www.facebook.com/press/info.php?statistics.

[Fac09b] Facebook: Facebook Developers - API, 2009. Verfugbar unter: http://wiki.developers.

facebook.com/index.php/API.

[FGM+99] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach undT. Berners-Lee: RFC 2616 - Hypertext Transfer Protocol, 1999. Verfugbar unter: http:

//www.w3.org/Protocols/rfc2616/rfc2616.html.

[Fie00] Fielding, Roy: Architectural Styles and the Design of Network-based Software Architectures.Doktorarbeit, University of California, Irvine, 2000. Verfugbar unter: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

[Fli09] Flickr: Flickr Services - API Documentation, 2009. Verfugbar unter: http://www.flickr.com/services/api/.

[FW04] Fallside, David C. und Priscilla Walmsley: XML Schema Part 0: Primer Second Edition,2004. Verfugbar unter: http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.

[Gam07] Gamperl, Johannes: AJAX. Grundlagen, Frameworks, APIs. Galileo Press, Bonn, 2. AuflageAuflage, 2007. Verfugbar unter: http://amazon.de/o/ASIN/3898428575/.

[Gar05] Garrett, Jesse James: Ajax: A New Approach to Web Applications. 2005. Verfugbar unter:http://adaptivepath.com/ideas/essays/archives/000385.php.

[Goo09a] Google: Blogger Data API - Developer’s Guide: Protocol, 2009. Verfugbar unter:http://code.google.com/intl/de-DE/apis/blogger/docs/2.0/developers_guide_

protocol.html.

[Goo09b] Google: YouTube Developer’s Guide: Data API Protocol, 2009. Verfugbar unter: http://

code.google.com/intl/de/apis/youtube/2.0/developers_guide_protocol.html.

[Gro09] GroupMe! Team: Overview - GroupMe! APIs, 2009. Verfugbar unter: http://groupme.org/GroupMe/api.

[HMCC08] Henderson, Cal, Mike Malone, Leah Culver und Richard Crowley: oEmbed: specifi-cation, 2008. Verfugbar unter: http://www.oembed.com/.

[Ipe09] Ipernity: Ipernity API documentation, 2009. Verfugbar unter: http://www.ipernity.com/help/api.

[Joh06] Johnson, Dave: RSS and Atom in Action: Web 2.0 Building Blocks: Building Applicationswith Blog Technologies. Manning, 2006.

[Kan07] Kantel, Jorg: RSS und Atom - kurz & gut. O’Reilly, 2007.

103

http://www.ietf.org/rfc/rfc4627.txt

http://www.dataportability.org/

http://delicious.com/help/tools

http://www.facebook.com/press/info.php?statistics

http://www.facebook.com/press/info.php?statistics

http://wiki.developers.facebook.com/index.php/API

http://wiki.developers.facebook.com/index.php/API

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.flickr.com/services/api/

http://www.flickr.com/services/api/

http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/

http://amazon.de/o/ASIN/3898428575/

http://adaptivepath.com/ideas/essays/archives/000385.php

http://code.google.com/intl/de-DE/apis/blogger/docs/2.0/developers_guide_protocol.html

http://code.google.com/intl/de-DE/apis/blogger/docs/2.0/developers_guide_protocol.html

http://code.google.com/intl/de/apis/youtube/2.0/developers_guide_protocol.html

http://code.google.com/intl/de/apis/youtube/2.0/developers_guide_protocol.html

http://groupme.org/GroupMe/api

http://groupme.org/GroupMe/api

http://www.oembed.com/

http://www.ipernity.com/help/api

http://www.ipernity.com/help/api


[Kay07] Kay, Michael: XSL Transformations (XSLT) Version 2.0. W3C Recommendation 23 January2007, 2007. Verfugbar unter: http://www.w3.org/TR/2007/REC-xslt20-20070123/.

[KCNS02] Kline, G., Clearswift Corporation, C. Newman und Sun Microsystems: RFC 3339- Date and Time on the Internet: Timestamps, 2002. Verfugbar unter: http://tools.ietf.org/html/rfc3339.

[Kno09] Knowledge and Data Engineering Group of the University of Kassel: BibSonomy- API URL Schema, 2009. Verfugbar unter: http://www.bibsonomy.org/help/doc/api.html.

[Las09] Last.fm: Last.fm Web Services, 2009. Verfugbar unter: http://www.lastfm.de/api/intro.

[LJD01] Laurent, Simon St, Joe Johnston und Edd Dumbill: Programming Web Applications withXML-RPC. O’Reilly, 2001.

[ML07] Mitra, Nilo und Yves Lafon: SOAP Version 1.2 Part 0: Primer (Second Edition).W3C Recommendation 27 April 2007, 2007. Verfugbar unter: http://www.w3.org/TR/2007/REC-soap12-part0-20070427/.

[MO08] Morsy, Hussein und Tanja Otto: Ruby on Rails 2: Das Entwickler-Handbuch. Galileo Press,2008.

[Moz08] Mozilla: mozilla developer center. XUL, 2008. Verfugbar unter: https://developer.

mozilla.org/En/XUL.

[NS05] Nottingham, M. und R. Sayre: RFC 4287 - The Atom Syndication Format, 2005. Verfugbarunter: http://tools.ietf.org/html/rfc4287.

[OAu07] OAuth Core Workgroup: OAuth Core 1.0, 2007. Verfugbar unter: http://oauth.net/

core/1.0/.

[O’R05] O’Reilly, Tim: What Is Web 2.0. 2005. Verfugbar unter: http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

[Pro09] ProgrammableWeb.com: ProgrammableWeb. Web Services Directory, 2009. Verfugbar unter:http://www.programmableweb.com/apis/directory.

[RR07] Richardson, Leonard und Sam Ruby: Web Services mit REST. O’Reilly, 2007.

[Sli09] SlideShare: SlideShare API Version 2.0 Documentation, 2009. Verfugbar unter: http://www.slideshare.net/developers/documentation.

[STK02] Snell, James, Doug Tidwell und Pavel Kulchenko: Programming Web Services withSoap. O’Reilly, 1 Auflage, 2002.

[TEN09] TENCompetence: About TENCompetence, 2009. Verfugbar unter: http://www.

tencompetence.org/.

[Wen07] Wenz, Christian: JavaScript und Ajax. Galileo Press, 2007.

[Wil99] Wilde, Erik: World Wide Web. Technische Grundlagen. Springer-Verlag, Berlin, 1 Auflage,1999.

[Win99] Winer, Dave: XML-RPC Specification, 1999. Verfugbar unter: http://www.xmlrpc.com/

spec.

104

http://www.w3.org/TR/2007/REC-xslt20-20070123/



http://www.bibsonomy.org/help/doc/api.html

http://www.lastfm.de/api/intro

http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

https://developer.mozilla.org/En/XUL

https://developer.mozilla.org/En/XUL


http://oauth.net/core/1.0/

http://oauth.net/core/1.0/

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

http://www.programmableweb.com/apis/directory

http://www.slideshare.net/developers/documentation

http://www.slideshare.net/developers/documentation

http://www.tencompetence.org/

http://www.tencompetence.org/

http://www.xmlrpc.com/spec

http://www.xmlrpc.com/spec


[Win03] Winer, Dave: RSS 2.0 Specification, 2003. Verfugbar unter: http://cyber.law.harvard.edu/rss/rss.html.

[WW98] Wolf, Misha und Charles Wicksteed: Date and Time Formats, 1998. Verfugbar unter:http://www.w3.org/TR/1998/NOTE-datetime-19980827.

105

http://cyber.law.harvard.edu/rss/rss.html

http://cyber.law.harvard.edu/rss/rss.html

http://www.w3.org/TR/1998/NOTE-datetime-19980827

Abbildungsverzeichnis

Abbildungsverzeichnis

3.1 Autorisierung nach einem Login-basierten Verfahren . . . . . . . . . . . . . . . . . . . . . . . 233.2 Autorisierung nach dem Sequential-Token-Request-Verfahren . . . . . . . . . . . . . . . . . . 243.3 Autorisierung nach dem Interrupted-Token-Request-Verfahren . . . . . . . . . . . . . . . . . . 253.4 Autorisierung nach dem Login-Token-Exchange-Verfahren . . . . . . . . . . . . . . . . . . . . 253.5 Autorisierung nach dem Manual-Token-Input-Verfahren . . . . . . . . . . . . . . . . . . . . . 263.6 OAuth Authentifizierungsablauf (aus [OAu07]) . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Ubersicht uber das konzeptionelle Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Antwortformate der bei http://programmableweb.com gelisteten APIs (uberpruft am 21.04.2009) 57

6.1 Positionierung von InterWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2 Zugriff von einem Client auf InterWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.3 Zugriff von InterWeb auf die Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4 ApiAuth-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.5 ApiQuery-Interface, Query-Klasse und QueryResult-Klasse . . . . . . . . . . . . . . . . . . . 696.6 ApiFriendGetter-Interface und FriendResult-Klasse . . . . . . . . . . . . . . . . . . . . . . . . 706.7 ApiUploader-Interface und Resource-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1 Autorisierung in LearnWeb2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2 Eigene Ressourcen in LearnWeb2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.3 Liste der Freunde in LearnWeb2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.4 Ressourcensuche in LearnWeb2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1 Icon der Firefox Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.2 Autorisierung in der Firefox Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.3 Suche in der Firefox Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.4 Upload in der Firefox Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

106

Tabellenverzeichnis

Tabellenverzeichnis

5.1 Architektur-Stile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 Verwendung der Autorisierungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3 Antwortformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5 Verwendung der HTTP-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Endpunkte von InterWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

107

Listings

Listings

2.1 HTTP-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 HTTP-Antwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Beispiel fur eine XML-RPC-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Beispiel fur eine XML-RPC-Antwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Beispiel: XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Beispiel: JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7 Beispiel: RSS 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8 Beispiel: RSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.9 Beispiel: Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1 Facebook-FQL-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1 Konstruktion des Signatur-Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2 Vollstandiger Signatur-String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3 Fertige Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.4 XML-Antwort auf eine Suchanfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.5 XML-Antwort mit den implementierten Services . . . . . . . . . . . . . . . . . . . . . . . . . 646.6 XML-Antwort mit den Freunden eines Benutzers . . . . . . . . . . . . . . . . . . . . . . . . . 656.7 XML-Antwort mit den Gruppen eines Benutzers . . . . . . . . . . . . . . . . . . . . . . . . . 656.8 XML-Antwort auf einen Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.9 XML-Antwort mit den Uploads eines Benutzers . . . . . . . . . . . . . . . . . . . . . . . . . . 666.10 XML-Antwort im Fehlerfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.11 Konfiguration der implementierten Services (app.yml) . . . . . . . . . . . . . . . . . . . . . . 686.12 Konfiguration der Medientypen (app.yml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.13 Abschließendes Hinzufugen zu den implementierten Services . . . . . . . . . . . . . . . . . . . 72C.1 Autorisierungsklasse fur BibSonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91C.2 Suchhandlerklasse fur BibSonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92C.3 Uploadhandlerklasse fur BibSonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

108

Danksagung

Ich danke Herrn Fabian Abel und Herrn Sergej Zerr,die mich bei meiner Masterarbeit

hervorragend betreut und unterstutzt haben.

Erklarung

Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbststandig und ohne fremde Hilfe verfasstund keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe.

Tristan Wehrmaker Hannover, 30. April 2009

Interoperabilität im Web 2.0: Evaluierung und...

Documents

Transcript of Interoperabilität im Web 2.0: Evaluierung und...