iSyndica - Building an API


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • An API can be a great asset or a liabilityGood API’s capture trafficOf-boarding cost can be prohibitiveBad API’s can be a huge drain in terms of supportOnce an API is published and in production, it becomes hard to change.
  • Ease of useEasy to learnEasy to add functionalityGets the job done
  • API's need to be Stateless - Every request needs to contain all of the information necessary to service the request. Every API should be atomic - It does one logical operation and one alone and doesn't rely on any sequential calls.API’s should abstract the implementation detailUse self explanatory name.Avoid ambiguous overloading
  • Documentation – It’s a necessary evil, there are too many API’s out there that don’t have enough usable documentation.Be consistent with naming conventions throughout the API.Modularize your code and try to think in terms of interfaces and not implementation types
  • Attempt to incorporate the patterns already existing in the development platform of your choice.Try to reduce “boiler plate” code. Cut & Paste is very error prone. Use Code generation where ever possible.Our 80/20: write code 20% of the time.
  • Developer Key – Unique developer identifier sent as part of every call. Not so secure.Username / Password – Username & Password sent as part of every call. Not so secure unless using HTTPS which is 90% slower than HTTPDigest – Using an security algorithm to stamp a call with a digest for authentication. Fairly secure and easy to implement.Token – Using an identification token
  • OAuth is token based authentication mechanisms that standardizes secure API authorization for desktops & web applicationsOAuth stake holdersProviders – Software applications that provide a service on the web i.e. API enabled websites/web-services. For eq. Facebook, Flickr etcUsers – Users of a service, average joe’s who own an account with the providersConsumers –3rd party Software applications that proxy for the users with the providers. For eqFacebook Mobile, iSyndica VDSAdvantagesOnly the provider sees your username / passwordThe token is easily tracked by the provider and as a user you can limit/revoke the permissionUse of a secret key makes phishing the token useless.DisadvantagesComplex implementation
  • No cleartext username and password ever stored, Username & Password are sent over HTTPS – Slow but secureOauth Loop is instantaneous, No need for the user to go through complexOAuth loops
  • API design isn’t easy but incredibly funAdds incredible valueA group effortThere is no “Perfect API” that fits all the requirement.
  • API design isn’t easy but incredibly funAdds incredible valueA group effortThere is no “Perfect API” that fits all the requirement.
  • iSyndica - Building an API

    1. 1. iSyndica<br />Building an API<br />, April 20th 2010<br />
    2. 2. Good API Design<br />It’s a great asset.<br />Or a liability.<br />
    3. 3. What makes an API ‘Good’?<br />It just works.<br />
    4. 4. Three Key Guidelines<br />Labels/<br />GetLabel?id=1<br />GetLabelRoots<br />GetLabelChildren?id=1<br />Keep it atomic.<br />
    5. 5. Three Key Guidelines<br />GreatExamples<br />eBay<br />Facebook<br />Flickr<br />Google Data<br />Twitter<br />Document well.<br />
    6. 6. Three Key Guidelines<br />.NET: T4<br />Ruby:Rgen<br />Python: Cog, Cheetah<br />Java: XDoclet<br />Code generation is your friend.<br />
    7. 7. API Security Types<br />Developer Key<br />Username/Password<br />Digest<br />Token<br />
    8. 8. Our Choice<br />
    9. 9. Mobile OAuth?<br />
    10. 10. Have Fun<br />There’s no “Perfect API”.<br />
    11. 11. Thanks!<br /><br /><br />