Open API Architectural Choices Considerations

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 oﬀ-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 ﬂickr.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 Proﬁt / Non-proﬁt 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.ﬂickr.com/services/rest/?method=ﬂickr.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 ﬂickr non-commercial user speciﬁed last.fm non-commercial non-commercial CC twitter none none tumblr none none

Call Routing How to locate our stuﬀ.

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 diﬀerent 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 ﬂickr - .com

http://dominiek.com	89
http://synaptify.com	10
http://www.slideshare.net	8
http://localhost:3000	1
http://dominiek.kakuteru.com	1
http://synaptify.local	1

Open API Architectural Choices Considerations

by Dominiek ter Heide on May 29, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 110

Statistics

Open API Architectural Choices Considerations — Presentation Transcript