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.

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:

10. Mistakes I’ve Made

11. Mistakes I’ve Made
Lessons I’ve Learned.

12. Minimum Viable Product

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

72. GetExceptional - Backtraces

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

79. Standardize object output

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