Open Data Services
Architectural Choices and Considerations
Dominiek ter Heide
May, 2008

Common Usages
Developer Center
Platform Setup
Call Routing
Data Structure
Format

Data Service Goals
stimulate an explosion of new data/content
repurpose our data off-site and increase
activity
potentially generate revenue from services

Separate?
Tied in with Service Separated Platform

Common Usages
The fruits of Data Services

Common Usages
Web embedable widgets
PC applications
Graphing applications

Web Widgets
Flash HTML

PC Applications
Desktop Dashboard

Graphing Apps
Relationships

Graphing Apps
Trends

Developer Center
A place for geeks to gather.

A place to
provide tutorials and examples
allow people to document (wiki)
provide usage and key administration
provide licensing information

Last.fm Resources/Support
audioscrobbler.net

Flickr Resources/Support
flickr.com/services

Twitter Resources/Support
twitter.com/help/api

Tumblr Resources/Support
tumblr.com/api

Platform Setup
How to structure your universe.

Platform Setup
URL of great importance
Profit / Non-profit considerations
Platform As A Service?

the URI
mental models / syntax
media to use
data structure
protocol domain version path format
http://ws.audioscrobbler.com/1.0/user/dx00/recenttracks.xml

URIs for API Calls
http://ws.audioscrobbler.com/1.0/user/dx00/recenttracks.xml
http://api.flickr.com/services/rest/?method=flickr.photos.search
http://twitter.com/statuses/friends_timeline/dominiek.json
http://dominiek.tumblr.com/api/write

Licensing
For service
For data
Choose a data license early

Licences
service data
flickr non-commercial user specified
last.fm non-commercial non-commercial CC
twitter none none
tumblr none none

Call Routing
How to locate our stuff.

Loose / Tight Integration
How much do third parties need to know
about your system?
How easy is it to use your data services?

Integration
standardized customized
Loose
rss html microformats
restful
json rest Tight
xml
rdf xmlrpc rpc
xml
soap serialization
corba
ease of html
integration

RESTful
GET /get_user.xml?username=dominiek
HTTP standard? Yes
Status codes? Yes
Variety of response formats? Yes
Using correct method calls? Almost
Identifying URI for resource No

REST
DELETE /users/dominiek.xml
HTTP standard? Yes
Status codes? Yes
Variety of response formats? Yes
Using correct method calls? Yes
Identifying URI for resource Yes

API Keys
provide usage tracking
take away ad hoc integration
ideally in request headers

Authentication
different from the User Interface
OAuth for user data?

Data Structure
What are we even talking about?

Structuring Goals
Talk about the same Domain
Understandability for other Developers
Understandability for other Architectures

Standardize Structure
Your Standards Open Standards
+
last.fm’s XML XSPF
or...

Standardize Structure
Your Standards extend Open Standards
Youtube’s API feed
yes!

Content vs Communication

URI’s in Content Data
No knowledge about URL structure required
Ability support external Entities
RDF and Semantic Web Ready

Format
In what language do we speak?

Formatting Goals
facilitate implementation variety
performance

Desired Formats
XML for tight server-side integration
JSON for easy web integration (widgets)

Optional Formats
HTML Human readable debug output
Serializations like PHP and YAML
RDF for advanced integration

Links
http://www.idealliance.org/proceedings/xtech05/
papers/02-07-04/
http://www.w3.org/Protocols/rfc2616/rfc2616-
sec10.html
http://arbor.ee.ntu.edu.tw/~wisely/download/
REST_Rails_OSDC_2007.pdf
http://oauth.org
lastfm, twitter, tumblr and flickr - .com