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.

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

2. Common Usages
Developer Center
Platform Setup
Call Routing
Data Structure
Format

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. Separate?
Tied in with Service Separated Platform

5. Common Usages
The fruits of Data Services

6. Common Usages
Web embedable widgets
PC applications
Graphing applications

7. Web Widgets
Flash HTML

8. PC Applications
Desktop Dashboard

9. Graphing Apps
Relationships

10. Graphing Apps
Trends

11. Developer Center
A place for geeks to gather.

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

13. Last.fm Resources/Support
audioscrobbler.net

14. Flickr Resources/Support
flickr.com/services

15. Twitter Resources/Support
twitter.com/help/api

16. Tumblr Resources/Support
tumblr.com/api

17. Platform Setup
How to structure your universe.

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

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. 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. Licensing
For service
For data
Choose a data license early

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

23. Call Routing
How to locate our stuff.

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. Integration
standardized customized
Loose
rss html microformats
restful
json rest Tight
xml
rdf xmlrpc rpc
xml
soap serialization
corba
ease of html
integration

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. 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. API Keys
provide usage tracking
take away ad hoc integration
ideally in request headers

29. Authentication
different from the User Interface
OAuth for user data?

30. Data Structure
What are we even talking about?

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

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

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

34. Content vs Communication

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

36. Format
In what language do we speak?

37. Formatting Goals
facilitate implementation variety
performance

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

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

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