iSyndica - Building an API
•Als PPTX, PDF herunterladen•
0 gefällt mir•328 views
The document discusses guidelines for building good APIs, including keeping API calls atomic, documenting the API well, and using code generation. It also covers common API security types like developer keys and OAuth, noting the document's focus is on building a good API for iSyndica that is secure and works well across platforms. The document encourages having fun in the process and acknowledges there is no single perfect API design.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Mehr von e27
Mehr von e27 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
iSyndica - Building an API
- 1. iSyndica Building an API Hackerspace.sg, April 20th 2010
- 2. Good API Design It’s a great asset. Or a liability.
- 3. What makes an API ‘Good’? It just works.
- 4. Three Key Guidelines Labels/ GetLabel?id=1 GetLabelRoots GetLabelChildren?id=1 Keep it atomic.
- 5. Three Key Guidelines GreatExamples eBay Facebook Flickr Google Data Twitter Document well.
- 6. Three Key Guidelines .NET: T4 Ruby:Rgen Python: Cog, Cheetah Java: XDoclet Code generation is your friend.
- 7. API Security Types Developer Key Username/Password Digest Token
- 8. Our Choice
- 10. Have Fun There’s no “Perfect API”.
Hinweis der Redaktion
- 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.