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 api.twitter.com
- 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 [http://oauth.net/] 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.
Comments