Open Data ServicesArchitectural Choices and Considerations

Dominiek ter HeideMay, 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 WidgetsFlash HTML

PC Applications

Desktop Dashboard

Graphing AppsRelationships

Graphing AppsTrends

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

http://ws.audioscrobbler.com/1.0/user/dx00/recenttracks.xml

syntaxmedia to use mental models /data structure

protocol domain version path format

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

Licencesservice 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

xmlrdf

xml

standardized customized

restrpc

restful

ease of integration

json

rss

html

html microformats

Loose

Tight

corba

xmlrpc

soap serialization

RESTfulGET /get_user.xml?username=dominiek

HTTP standard?Status codes?

Using correct method calls?

YesYes

AlmostNoIdentifying URI for resource

Variety of response formats? Yes

RESTDELETE /users/dominiek.xml

HTTP standard?Status codes?

Using correct method calls?

YesYes

Identifying URI for resource

Variety of response formats? YesYesYes

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