Building an API with Rails
Building an API is tough and we want to discuss some of the decisions made by the Twitter, Github, 37signals, NY Times, and ThoughtBot while building and growing their APIs. Each panelist brings a wide variety of knowledge and problem sets they’ve solved. Here are some of the topics we will try to cover:
- Authentication (Http auth, tokens, OAuth)
- Response Format Support (JSON, XML, yaml)
- Versioning vs Non-versioning
- Scaling and Code Separation
- Security concerns
- Developer communication strategies and importance
- Documentation tools
Josh Owens
Four Bean Soup
Josh is the founder of Four Bean Soup. Josh has been honing his Rails skills over the past 5 years, and is a Rails Core Contributor. You can follow his adventures in coding on his RailsFreak blog.
A notable achievement for Josh; he lead his development team to win the 2007 Rails Rumble competition for the development of TastyPlanner.
Josh is a Podcaster and Producer of WebPulp TV. Josh spends most days striving to write beautiful, elegant Ruby code and leading his projects to succes.
Joe Ferris
thoughtbot, inc
Joe works for ThoughtBot and has worked extensively on the Hoptoad API.
Jeremy Kemper
37signals
Jeremy works at 37signals and has worked on most APIs offered by their web services.
Marcel Molina
Marcel is an API developer @twitter. He has previous worked for 37signals.
Rick Olson
GitHub
Rick is a Ruby developer at @github. He’s also developed several APIs for @entp.
Derek Willis
The New York Times
Derek works @nytimes and has worked on various APIs there, including the Open Congress API.
Comments on this page are now closed.
Comments
The panel format doesn’t work very well. Each member of this panel could have easily given a very interesting talk on their own, but the chemistry between the panelists was nonexistent and there wasn’t time for any substantial discussion about each topic covered.
After this session I started to feeling myself like if I’d have been fooled, there was several sessions like this one, without substance. It was a great opportunity, the panel was impressive, but, as most of the panels of this RailsConf they weren’t prepared for the session. it’s a shame. Quality of RailsConf is less every time.
This panel would probably have been a lot better if there had been a host, and if the panelists had prepared some brief remarks. In general, panels should have a host who can keep the conversation moving and tell people to speak up when they are mumbling into the microphone.
Agree with others on lack of substance. I didn’t learn much at this session.
Great panel, poor session. Less talk, more action. Great players in the api business, but it either needed to be twice as long or half the speakers. There was room for education, but very little was communicated. I liked the interplay, definitely had personality!
either more code or more time for audience questions
Reasonably good for a panel.
Seems like a missed opportunity. APIs are definitely an area of interest, but this abstract collection of opinions failed to be enlightening, informative nor interesting. Making panels work is hard. This just didn’t work out.
very ad hoc, not much energy. was hoping for something .. meatier.
They seemed to be solving problems most developers don’t have. I would have like to see more example code.
Enjoyed the stories, but felt unrehearsed and ran a bit late.
anecdote popcorn; would have been better w/ fewer people and more code; I wanted to see examples of best practices of implementing APIs in Rails; most of the anecdotes were obvious, or one panelist would suggest one thing and another one would disagree with it; not many principles communicated; bad panel