Jacob Burkhart jacobo

Title:

The fine Art of balancing Malt and Hops in an API.

Audience:

Novice to Experienced Web Developers, Novice to Moderate Homebrewers

Abstract:

Title:

Making Ales and APIs: Good Ideas, Bad Ideas, Miscellaneous Ideas

Audience:

Novice to Experienced Web Developers, Novice to Moderate Homebrewers

Abstract:

Title:

The fine Art of balancing Malt and Hops in an API.

Audience:

Novice to Experienced Web Developers, Novice to Moderate Homebrewers

Abstract:

Building an API can be hard, but thanks to my mistakes: YOU TOO can write a sensible easy to maintain HTTP/JSON API for your product.

I don't have all the answers, but I've spent the last 9 months writing 2 interconnected APIs. We've re-written some parts, thrown some away, and turned others into open source libraries. I've been thankful for some decisions, and cursed for others.

Altogether we've learned a lot.

Let's review the process we took, and how I would do it differently next time.

README-driven development is great. But what about a development-driven README? What if your README included coded snippets automatically pulled from your code? I've done it both ways, and I have an opinion!

Let's have a philosophical argument about it. Then I'll show you how I've implemented it in my case. And then we can argue implementation!

	require File.dirname(__FILE__) + '/../test_helper'

	class IdGeneratorTest < ActiveSupport::TestCase
	self.use_transactional_fixtures = false

	def test_colliding_ids
	#run 5 simulatneous process each generating 10 ids
	#then check for collisions in the cumulative output ids

	pids_and_results = []

	1.8.7 gem-release [master]$ bundle
	Using gem-release (0.1.3) from source at .
	Using metaclass (0.0.1)
	Using mocha (0.10.5)
	Using test_declarative (0.0.5)
	Using bundler (1.0.21)
	Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
	1.8.7 gem-release [master]$ bundle exec ruby -Ilib test/gemspec_test.rb
	Loaded suite test/gemspec_test
	Started

	You know JSON and REST
	You know Sinatra and Rack and RestClient
	But do you really know... how to build an API?

	Let's get to the Meat.
	How to build and test your API server and client at the same time.

	Your server should run your client tests.
	Your client test should run against your real server.
	Your client should ship with a fake that makes tests against it easy for integrators.

	1 min:

	~Painless Javascript
	koting hatduklgg
	with wind tunnel

	~tenderlove.dup jremsikjr

	~iwanttolearnruby.com
	(collecting resources for learning ruby)

	It's all well and good to learn about the principles of REST. And It's interesting to read about HATEOAS. And It's great to be able to look a the example of APIS like Twitter, Twilio and Amazon. But what happens you actually try to go and implement something. Where does it get tricky.

	You might guess that you have to compromise a few principle for the sake of pragmatism. But what else?

	I've spent the last nine months working on the Engine Yard Platform Services API. I can at least tell you about the hard parts for me. Where do you start, is a big one. How do you test, is another. The answers may surprise you.