Follow leybzon on Twitter

Thursday, April 24, 2008

API Design notes from Web 2.0 Expo

Twitter API Experience

It is ALL around REST these days. Even Google abandoned more complicated API in favor of RESTfull

For Twitter API more that 80% of overall traffic these days

Twitter manages developer community over Google Group

400 applications added by hand to the directory from e-mail, tons more are around and not the catalog

XML, JSON, and many other formats supported

Grow API organically (started with 2 methods and no documentation), from the conversation with developers "I can do X if you do Y"

Documentation is really important – at least reverse engineer. Doc should describe at least: How do I start? Is API crawlable? How to dive into the API?

Support developers 24 hrs is important – be present! If not listening, developers will go forward.

Delegate to other developers who are active within the community. Do not forget to socially reward them.

Scaling from API prospective. XML, JSON are not designed for scale by itself. Do it early is a big win. Dedicate part of server farm for API – do not mix destination and API on the same servers

Security issues. API is where bad-behaving users will go first. Audit. Monitor. Expect what can be leaked.

What twitter did wrong?

  • Did not start with
  • Did not version the API
  • Did not make life easy (or easier) for Flash developers
  • Did not automate (statistics, admin use, app galleries)
  • Many more

New in twitter API

  • Rudimentary geolocation support
  • More consistency between methods
  • Parity between user-side and API side

Misc Observations

It is unclear how to make API into business. It is a trade-off between value from dev community and users. Mashery pretends to monetize on API. QOS is an option.

OAuth [] is absolutely where authorization goes on API. More complex on production and consumer site.

Jabber/XMPP – most clients pull constantly. A lot of overhead can be saved this way. But overhead and lack of libraries slow down the effort.

Web->API->SOA Model provides: separation of concerns, direction to move towards

Faces of APIs: XML, spreadsheets, static virtual maps, static URLs, SOAP, JSON, serialized PHP, JavaScript callbacks, etc

The only way to transfer date/time data – UNIX timestamp

New API directions:

  • Amazon S3/(with billing associated with it and authentication)
  • OAuth – emerging standard for 3-d party in client-server relationship. Create a situation to provision on behalf of other users.

No comments: