Building an API with Rails

Moderated by:
Josh Owens (Four Bean Soup)
Panelists:
Joe Ferris (thoughtbot, inc), Jeremy Kemper (37signals), Marcel Molina (Twitter), Rick Olson (GitHub), Derek Willis (The New York Times)
General
Location: Ballroom I
Average rating: **...
(2.39, 139 ratings)

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
Photo of Josh Owens

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.

Photo of Joe Ferris

Joe Ferris

thoughtbot, inc

Joe works for ThoughtBot and has worked extensively on the Hoptoad API.

Photo of Jeremy Kemper

Jeremy Kemper

37signals

Jeremy works at 37signals and has worked on most APIs offered by their web services.

Photo of Marcel Molina

Marcel Molina

Twitter

Marcel is an API developer @twitter. He has previous worked for 37signals.

Photo of Rick Olson

Rick Olson

GitHub

Rick is a Ruby developer at @github. He’s also developed several APIs for @entp.

Photo of Derek Willis

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

Derek Croft
06/17/2010 10:00am EDT

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.

Rafael Magana
06/15/2010 10:24pm EDT

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.

Jason Meinzer
06/11/2010 3:02pm EDT

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.

Jason Gilman
06/11/2010 8:47am EDT

Agree with others on lack of substance. I didn’t learn much at this session.

Jay Sanders
06/10/2010 11:22pm EDT

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!

Seamus Abshere
06/10/2010 5:18pm EDT

either more code or more time for audience questions

Picture of Rabble Evan Henshaw-Plath
Rabble Evan Henshaw-Plath
06/09/2010 3:18pm EDT

Reasonably good for a panel.

Keith Hunniford
06/09/2010 2:33pm EDT

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.

Picture of Ben Vandgrift
Ben Vandgrift
06/08/2010 4:17pm EDT

very ad hoc, not much energy. was hoping for something .. meatier.

Picture of Michael Gee
Michael Gee
06/08/2010 1:54pm EDT

They seemed to be solving problems most developers don’t have. I would have like to see more example code.

Vince Hoang
06/08/2010 11:45am EDT

Enjoyed the stories, but felt unrehearsed and ran a bit late.

Picture of Wes Morgan
Wes Morgan
06/08/2010 11:39am EDT

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

co-presented by Ruby Central, Inc. O'Reilly
  • Engine Yard
  • Heroku
  • 8th Light
  • Blue Box Group
  • InfoEther
  • JetBrains
  • New Relic
  • Open Hosting
  • Rhomobile
  • WyeWorks
  • Linux Pro Magazine
  • Chargify

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine at yromaine@oreilly.com.

Download the RailsConf Sponsor/Exhibitor Prospectus

Media Partner Opportunities

For information on trade opportunities with O'Reilly conferences or contact mediapartners@ oreilly.com

Program Ideas

Send us your suggestions for speakers, topics, and activities to rails-idea@oreilly.com.

Press and Media

For media-related inquiries, contact Maureen Jennings at maureen@oreilly.com.

RailsConf Newsletter

To stay abreast of conference news please sign up for the RailsConf newsletter (login required)

Contact Us

View a complete list of RailsConf 2010 contacts.