Your SlideShare is downloading. ×
0
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Dial2Do API
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Dial2Do API

772

Published on

PDF of Presentation at Developer API War and Facebook Garage event in Dublin March 5th 2009

PDF of Presentation at Developer API War and Facebook Garage event in Dublin 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
772
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. API Experience one number to get things done, hands-free Sean O Sullivan, CTO sos@dial2do.com
  2. Dial One Number to … “jajah” “twitter” “sandy” jaiku Currently 40+ services “Evernote” “Blogger” “Mosio” Interactive, Two-Way service (not“RTM” to text) just voice “NYT” Integrates with existing web “tumblr” applications “Huff Post” “text”
  3. One number, many services
  4. Technical Overview
  5. 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…) Other telecom APIs (Parlay, Parlay-X) Also provide our own Dial2Do APIs (not public yet)
  6. Good news Broadly speaking, many APIs Are well-documented Are well-structured Have associated documentation and code samples Good Examples Facebook API Last.fm Google
  7. 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. Authentication Better Standard with some widespread adoption Oauth or OpenID Google, Yahoo, others… based Good documentation, good tools Token based, per Usernames and Passwords don’t need to be stored service User control to revoke individual services Your service looks/feels better Token based, per Usernames and Passwords don’t need to be stored user Token is at user account level Revoke the token, revoke all services Username / Least desirable - YOU have to store username/password Password
  9. 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. one number to get things done, hands-free Sean O Sullivan, CTO sos@dial2do.com

×