Dial2Do : API Experience

790 views

Published on

Some slides for the Developer API Wars event in Dublin, Ireland March 5th 2009

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

  • Be the first to like this

No Downloads
Views
Total views
790
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Dial2Do is focused on enabling drivers to do things while they drive. The service was launched to public in August 2008.
  • Dial2Do : API Experience

    1. 1. API Experience Sean O Sullivan, CTO [email_address] one number to get things done, hands-free
    2. 5. Dial One Number to … Currently 40+ services Interactive, Two-Way service (not just voice to text) Integrates with existing web applications “ sandy” “ Evernote” “ Mosio” “ RTM” “ text” jaiku “ jajah” “ twitter” “ NYT” “ Huff Post” “ tumblr” “ Blogger”
    3. 6. One number, many services
    4. 7. Technical Overview
    5. 8. APIs Lots of API usage in our projects Mobile and Telephony (SMS, on-device APIs, Ribbit …) Classic Web APIs (Google, Facebook, twitter, ping.fm, Jajah…) Also provide our own APIs (not public yet)
    6. 9. Good news Good Examples Broadly speaking, many APIs Facebook API Last.fm Google Are well-documented Are well-structured Have associated documentation and code samples
    7. 10. Issues Security Each service tends to have a different approach to authentication OpenID, OAuth, Token-based (by user or by service), or worst case username/password Often multiple forms of security supported (Google, Yahoo) Architecture and Design Dependencies on third parties - outages outside your control Is twitter down for everyone or just me? :-) Defensive design and coding (async, failure cases) Other Some services not well documented (Bebo)
    8. 11. Authentication Token based, per service Usernames and Passwords don’t need to be stored User control to revoke individual services Your service looks/feels better Oauth or OpenID based Standard with some widespread adoption Google, Yahoo, others… Good documentation, good tools Token based, per user Usernames and Passwords don’t need to be stored Token is at user account level Revoke the token, revoke all services Username / Password Least desirable - YOU have to store username/password
    9. 12. Authorisation OpenID Has not as yet seen wide adoption - but will most likely get there (URLs, more complex to grasp for end user) More features than OAuth Cool Off Period Have to protect against brute force auth attacks Need cool-off periods after multiple auth fails e.g. dictionary attack on twitter OAuth We are a Consumer but not yet a provider
    10. 13. Sean O Sullivan, CTO [email_address] one number to get things done, hands-free

    ×