Open API Architectural Choices Considerations

4,273 views
4,127 views

Published on

Building API's for a web 2.0 / web 3.0 aspiring service is very different than providing a tight integrated RPC service for some corporate client. It requires completely different ways of thinking and embracing new standards. I've composed a quick slideshow of all the architectural choices and considerations I've come across.

Published in: Business, Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,273
On SlideShare
0
From Embeds
0
Number of Embeds
85
Actions
Shares
0
Downloads
178
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Open API Architectural Choices Considerations

  1. 1. Open Data Services Architectural Choices and Considerations Dominiek ter Heide May, 2008
  2. 2. Common Usages Developer Center Platform Setup Call Routing Data Structure Format
  3. 3. Data Service Goals stimulate an explosion of new data/content repurpose our data off-site and increase activity potentially generate revenue from services
  4. 4. Separate? Tied in with Service Separated Platform
  5. 5. Common Usages The fruits of Data Services
  6. 6. Common Usages Web embedable widgets PC applications Graphing applications
  7. 7. Web Widgets Flash HTML
  8. 8. PC Applications Desktop Dashboard
  9. 9. Graphing Apps Relationships
  10. 10. Graphing Apps Trends
  11. 11. Developer Center A place for geeks to gather.
  12. 12. A place to provide tutorials and examples allow people to document (wiki) provide usage and key administration provide licensing information
  13. 13. Last.fm Resources/Support audioscrobbler.net
  14. 14. Flickr Resources/Support flickr.com/services
  15. 15. Twitter Resources/Support twitter.com/help/api
  16. 16. Tumblr Resources/Support tumblr.com/api
  17. 17. Platform Setup How to structure your universe.
  18. 18. Platform Setup URL of great importance Profit / Non-profit considerations Platform As A Service?
  19. 19. 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
  20. 20. 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
  21. 21. Licensing For service For data Choose a data license early
  22. 22. Licences service data flickr non-commercial user specified last.fm non-commercial non-commercial CC twitter none none tumblr none none
  23. 23. Call Routing How to locate our stuff.
  24. 24. Loose / Tight Integration How much do third parties need to know about your system? How easy is it to use your data services?
  25. 25. Integration standardized customized Loose rss html microformats restful json rest Tight xml rdf xmlrpc rpc xml soap serialization corba ease of html integration
  26. 26. 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
  27. 27. 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
  28. 28. API Keys provide usage tracking take away ad hoc integration ideally in request headers
  29. 29. Authentication different from the User Interface OAuth for user data?
  30. 30. Data Structure What are we even talking about?
  31. 31. Structuring Goals Talk about the same Domain Understandability for other Developers Understandability for other Architectures
  32. 32. Standardize Structure Your Standards Open Standards + last.fm’s XML XSPF or...
  33. 33. Standardize Structure Your Standards extend Open Standards Youtube’s API feed yes!
  34. 34. Content vs Communication
  35. 35. URI’s in Content Data No knowledge about URL structure required Ability support external Entities RDF and Semantic Web Ready
  36. 36. Format In what language do we speak?
  37. 37. Formatting Goals facilitate implementation variety performance
  38. 38. Desired Formats XML for tight server-side integration JSON for easy web integration (widgets)
  39. 39. Optional Formats HTML Human readable debug output Serializations like PHP and YAML RDF for advanced integration
  40. 40. 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

×