Application-Driven Virtualization: Architectural Considerations
Open API Architectural Choices Considerations
-
Upload
dominiek-ter-heide -
Category
Business
-
view
3.885 -
download
6
description
Transcript of Open API Architectural Choices Considerations
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