Dial2Do : API Experience

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Dial2Do is focused on enabling drivers to do things while they drive. The service was launched to public in August 2008.

    Favorites, Groups & Events

    Dial2Do : API Experience - Presentation Transcript

    1. API Experience Sean O Sullivan, CTO [email_address] one number to get things done, hands-free
    2.  
    3.  
    4.  
    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”
    6. One number, many services
    7. Technical Overview
    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)
    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
    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)
    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
    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
    13. Sean O Sullivan, CTO [email_address] one number to get things done, hands-free

    + sos100sos100, 8 months ago

    custom

    454 views, 0 favs, 0 embeds more stats

    Some slides for the Developer API Wars event in Dub more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 454
      • 454 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 8
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories