Social dev camp_2011
Download as KEY, PDF•1 like•613 views
The document provides advice on building APIs based on the author's experience building WIB APIs. Some key points include: - Use Ruby on Rails for its RESTful design, ease of development, and ability to scale horizontally. - Implement OAuth2 for authentication and authorization for its simplicity. - Return errors and limit data in standardized JSON formats for consistency. - Abstract the API into layers and keep it DRY to improve scalability and extensibility. - Prioritize documentation, testing, monitoring, and following standards used by other successful APIs.
Social dev camp_2011
- 1. Craig Ulliott likes building things
- 2. About me
- 3. About me • Needs to know how everything works
- 4. About me • Needs to know how everything works • Likes things that scale
- 5. About me • Needs to know how everything works • Likes things that scale • Think’s almost everything is inefficient
- 6. About me • Needs to know how everything works • Likes things that scale • Think’s almost everything is inefficient • Hates people
- 7. About me • Needs to know how everything works • Likes things that scale • Think’s almost everything is inefficient • Hates people • Just kidding
- 8. About me • Needs to know how everything works • Likes things that scale • Think’s almost everything is inefficient • Hates people • Just kidding • But people are the cause of all the worlds inefficiencies
- 9. About me • Needs to know how everything works • Likes things that scale • Think’s almost everything is inefficient • Hates people • Just kidding • But people are the cause of all the worlds inefficiencies What I do and have done:
- 11. Mistakes I’ve Made Lessons I’ve Learned.
- 13. Minimum Viable Product • Short sprints (release code regularly)
- 14. Minimum Viable Product • Short sprints (release code regularly) • Spend an hour thinking about why you’re building something, before you spend a week thinking about how.
- 15. Minimum Viable Product • Short sprints (release code regularly) • Spend an hour thinking about why you’re building something, before you spend a week thinking about how. • Your developing a business not a website
- 16. Surround yourself with business people
- 17. Surround yourself with business people • If you have a good idea, a strong technical co- founder and a business co-founder - you will get money / incubated / successful
- 18. Surround yourself with business people • If you have a good idea, a strong technical co- founder and a business co-founder - you will get money / incubated / successful • I get asked every 3 days if I know any developers - why are you guys not meeting each other!
- 19. Bootstrap if you can
- 20. Bootstrap if you can • BUSINESSES that work when they are small are easier to scale
- 21. Bootstrap if you can • BUSINESSES that work when they are small are easier to scale • The first step to becoming an Entrepreneur is not quitting your job
- 22. Bootstrap if you can • BUSINESSES that work when they are small are easier to scale • The first step to becoming an Entrepreneur is not quitting your job • You wont be pragmatic if your worried about rent / children / debt / x / y / z
- 23. Bootstrap if you can • BUSINESSES that work when they are small are easier to scale • The first step to becoming an Entrepreneur is not quitting your job • You wont be pragmatic if your worried about rent / children / debt / x / y / z • Its also a great lesson in finances
- 24. Don’t be afraid to share your idea • “But someone might steal it.” • The hardest thing you will do is going to be getting someone genuinely interested in your idea. • People that could actually execute your idea are too busy with their own ideas. • It’s a lot cheaper for someone to take a bet (put all the risk) on you, than try and do it themselves.
- 25. Fail quickly and fail often
- 26. Fail quickly and fail often one in seven businesses make it...
- 27. Fail quickly and fail often one in seven businesses make it... ...so start seven businesses!
- 28. WIB APIs in 2009
- 29. Some problem’s • WIB was completely dependent on lots of different social networks • They break and change stuff • Our code becomes complicated (entropy) • WIB had a small team • And lots of stuff to do • WIB had a lot of members • half a billion db rows & 7000+ queries a second
- 30. What is abstraction a web application is like an onion
- 31. The Solution: “Network Abstraction Layer” • Wrapped Facebook, Myspace, Bebo, Hi5, Friendster and Orkut • Normalized the I/O • Absorbed changes where they happen • Handled breakages • Data sharing across the whole network - Facebook user can see a MySpace user
- 32. and it’s really extensible • We can add functionality and data without breaking the other networks • We can add other networks very easily
- 33. It’s also nice and scalable (for a team) • An API has a defined protocol, so developers on our team could work side by side on the different networks. • As long as I/O stays the same, they can work independently
- 34. And it scales well technically • Dividing an application into layers makes it much easier to scale. • Mainly because the independent layers can be scaled (or re-written) independently, without breaking other components.
- 35. WIB APIs in 2011
- 36. WIB APIs in 2011
- 37. WIB Today Where I’ve Been . com The website does not connect directly to the database Facebook Twitter WIB oAuth 2 REST API Foursquare And others... Database Database Database
- 38. Advantages of a single API • Saves Time (money) and it’s Extensible (future proof) • Teams can work on their own platforms • Website, iPhone, Android, Facebook App et.al. • Federate out content (or build developer network)
- 39. How to build an API (an opinionated approach)
- 40. how to build stuff in general
- 41. how to build stuff in general • Developers cost
- 42. how to build stuff in general • Developers cost • Servers cost
- 43. Use Ruby on Rails
- 44. Use Ruby on Rails • It allows you to build reliable, powerful, readable code
- 45. Use Ruby on Rails • It allows you to build reliable, powerful, readable code • With RoR you can build a business in a week and host it for free
- 46. Use Ruby on Rails • It allows you to build reliable, powerful, readable code • With RoR you can build a business in a week and host it for free Even monkeys use tools!
- 47. Why Ruby on Rails is good for an API
- 48. Why Ruby on Rails is good for an API Especially if you’re a startup
- 49. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box
- 50. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box • Normalized data
- 51. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box • Normalized data • Encourages powerful abstraction
- 52. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box • Normalized data • Encourages powerful abstraction • It’s easy and quick to develop
- 53. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box • Normalized data • Encourages powerful abstraction • It’s easy and quick to develop • Its easy to write tests
- 54. Why Ruby on Rails is good for an API Especially if you’re a startup • RESTful out of the box • Normalized data • Encourages powerful abstraction • It’s easy and quick to develop • Its easy to write tests • Scales horizontally (until you’ve already “made it”) - the bottleneck will be your DB
- 55. RESTful web service • REST is how the web already works (makes it a pretty well known standard) • URL’s are self explanatory (easy to work with) • Closely matches the underlying data/objects • Makes it easy to build in a DRY way • Developers can get started very quickly
- 56. HTTP methods • POST : Create something new • GET : Retrieve something that already exists • PUT : Update something that already exists • DELETE : Remove something that already exists
- 57. Authorization and Authentication • Authentication • Who is this • Authorization • Can the Authenticated entity access this resource
- 58. oAuth1 vs oAuth2 • oAuth 2 is slightly less secure • But it makes everyone’s lives SO much easier • Build a “trusted” clients paradigm for internal use - login, register, reset password etc
- 59. HTTP Request Authentication Web server Framework Authentication It makes things really easy for developers Authorization lots of libraries and examples exist API Controller
- 60. Access Tokens • Different tokens for user+client and client • Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567
- 61. Access Tokens • Different tokens for user+client and client • Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 client_id = 12345
- 62. Access Tokens • Different tokens for user+client and client • Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 user_id = 1234576
- 63. Access Tokens • Different tokens for user+client and client • Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567 hash(client_secret+user_id)
- 64. Access Tokens • Different tokens for user+client and client • Store useful info in them, allows you to calculate on the fly instead of store in the db c1234-g7rCEVB867rbe4B-1234567
- 65. SSL iPhone WiFi laptop running squid internet • Require it, otherwise developers will expose all sort of stuff (like keys) • Important if you want to be taken seriously by developer community
- 66. SSL iPhone WiFi laptop running squid internet looking at all the traffic is easy • Require it, otherwise developers will expose all sort of stuff (like keys) • Important if you want to be taken seriously by developer community
- 67. Standardized Errors • Assume success=true • Always send back errors in the same way, so client libraries can be smart { "error": { "type": "ObjectException", "message": "Object does not exist" } }
- 68. Limit how much data gets send back • Mobile developers care a lot about this • allow customizations: fields=name,gender
- 69. DRY Definitions
- 70. HTTP Request Logging Errors: Web server • GetExceptional $20 a month (whats your time worth?) Performance: Framework • New Relic API Requests • Something simple near the top of your stack Logging (remember, storage is cheap) API Controller
- 71. GetExceptional
- 73. New Relic
- 74. New Relic
- 75. Roll your own
- 76. Roll your own
- 77. JSON • It’s smaller than XML • Developers write bad xml parsers, that rely on the order of the XML nodes • Facebook use it, and they set the standard - you want your API to be sexy don’t you?
- 78. Returning Data • Standarized - objects - arrays of objects - nested objects
- 80. DRY Documentation never goes out of date • Build it off the - models - connections - methods
- 81. Testing • Write tests on your API • Even if you hate tests • It’s easy • You can generate most of them just like the documentation
- 82. Tie it all together • A good API is a series of simple layers • Keep it DRY • Use the data structure for more dynamic code • Standards are your friend • There are plenty of examples out there - Facebook, Foursquare, Twitter etc
- 83. Thanks • Hope this was useful
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: \n
- #49: \n
- #50: \n
- #51: \n
- #52: \n
- #53: \n
- #54: \n
- #55: \n
- #56: \n
- #57: \n
- #58: \n
- #59: \n
- #60: \n
- #61: \n
- #62: \n
- #63: \n
- #64: \n
- #65: \n
- #66: \n
- #67: \n
- #68: \n
- #69: \n
- #70: \n
- #71: \n
- #72: \n
- #73: \n
- #74: \n
- #75: \n
- #76: \n
- #77: \n
- #78: \n
- #79: \n
- #80: \n
- #81: \n
- #82: \n
- #83: \n
- #84: \n