Skip to main content

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 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.
Labels:

Comments

Post a Comment

Popular posts from this blog

Facebook Friends Connect

Is a way to extend external sites to provide: FB identity FB friends (relationship) Feed to FB   Demo app at http://www.somethingtoputhere.com/therunaround User experience: login: js login method requiresession(): detects state of usr-FB relationship, log-in into FB if needed. If user has not authorised app - present app auth dialog. If already has session - just go init JS, require session   access FB data: - FBML on external site - use JS FBML parser and replace in browser DOM with FB data - JS based API to get FB data, REST API on the server site. Sessions work accross any API - only small subset of FBML us supported at the moment   adding social content: - use access API   Connections: app developers can suggest connections (using e-mail hash) user get connect request on FB Move content from external sites to FB app can register feed template (3 types of stories) call JS "showfeeddialog" to request user to confirm data sharing on FB. privacy protection: app ca
Post a Comment
Read more

Posting to FaceBook feed using Graph API

Graph API was announced at F8 with a promise to dramatically simplify the FB API. I checked the read access over the new interface during the presentations and to my big surprise it worked flawlessly and from the first time. When I tried https://graph.facebook.com/facebook , JSON-formatted info about the FaceBook page was returned (as expected). Then I tried OAuth 2.0 way of accessing the API to post a message to the feed. And to my even bigger surprise it worked too! Here is what you need to do to access Graph API over OAuth: 1. Create a FB app, store app properties to a file: $appkey = '7925873fbfb5347e571744515a9d2804' ; $appsecret = 'THE SECRET' ; $canvas = 'http://apps.facebook.com/graphapi/' ; 2. Create a page that will prompt user the access permission (I am prompting for the publish_stream and offline_access permissions at the same time) //http://apps.facebook.com/graphapi/ require 'settings.php' ; $url = "https://graph.face
14 comments
Read more

Ripple Baby Steps

Ripple and XPR What is Ripple for people in business and finance? Ripple is a currency exchange and payment settlement platform built using blockchain technology. Unlike Ethereum that is a more universal distributed application platform, Ripple solves a more narrow set of problems such as sending payments (similar to Bitcoin), currency remittance, payments for invoices, as well as number of other use cases related to payment in different currencies between parties that may or may not trust each other. Ripple is fast, scalable, and provides number of functions needed to support different payment scenarios. XPR is a native Ripple currency with a fixed and limited supply coins. 100 Billion XPR cryptocoins are in circulation today and the same number will be in circulation tomorrow.  What is Ripple for a software engineer?  For a software developer, Ripple is distributed ledger platform accessible trough API. There are number of libraries to accommodate different developers&#
Post a Comment
Read more