I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem

by Sidu Ponnappa on May 31, 2011

2,909 views

The Ruby ecosystem is pretty awesome when it comes to developing or...

The Ruby ecosystem is pretty awesome when it comes to developing or
consuming HTTP APIs. On the publishing front, the Rails framework is
an attractive option because it supports publishing what are popularly
(but inaccurately) referred to as 'RESTful' APIs quickly and
effortlessly. On the consumer side, the Ruby ecosystem provides
several very fluent and powerful libraries that make it easy to
consume HTTP based APIs.

Since a significant proportion of projects today require that APIs be
both published and consumed, many of them wind up choosing Ruby as a
platform for the reasons mentioned above. This talk is targeted at
folks that are currently on such projects, or anticipate being on such
projects in the future.

We will cover:
Consuming HTTP APIs:
1) The basics of making HTTP calls with Ruby
2) The strengths and weaknesses of Ruby's Net::HTTP across 1.8, 1.9
and JRuby (possibly Rubinius if we have the time to do research)
3) Popular HTTP libraries that either make it easier to do HTTP by
providing better APIs, make it faster by using libCurl or both
4) Different approaches to deserializing popular encoding formats such
as XML and JSON and the pitfalls thereof

Producing HTTP APIs using Rails:
1) The basics of REST
2) What Rails gives you out of the box - content-type negotiation,
deserialization etc. and the limitations thereof
3) What Rails fails to give you out of the box - hypermedia controls etc.
4) What Rails does wrong - wrong PUT semantics, no support for PATCH,
error handling results in responses that violate the clients Accepts
header constraints etc.
4) How one can achieve Level 2 on the Richardson Maturity Model of
REST using Rails
5) Writing tests for all of this

At the end of this, our audience will understand how you can both
consume and produce HTTP APIs in the Ruby ecosystem. They will also
have a clear idea of what the limitations of such systems are and what
the can do to work around the limitations.

Less

9 Embeds 1,645

http://blog.c42.in	1464
http://lanyrd.com	85
http://coderwall.com	29
http://feeds.feedburner.com	23
http://blog.bangaloreruby.org	23
url_unknown	12
http://posterous.com	7
http://speakerrate.com	1
http://webcache.googleusercontent.com	1

More...

Statistics

Favorites: 3
Downloads: 0
Comments: 0
Embed Views: 1,645
Views on SlideShare: 1,264
Total Views: 2,909

I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem — Presentation Transcript

I can haz HTTPConsuming and producing HTTP APIs in theRuby ecosystem

sidu ponnappa

kaiwren

@ponnappa

niranjan paranjape

achamian

@niranjan_p

Engineeringhttp://github.com/c42

Open Source (gem install) wrest(gem install) pox_paginate

Not about HTTP libs not per se...

More about...

REST

caching

serialisation & deserialisation

authentication

stuff like that...

Producer / Consumer

Producer

digression

RESTful?

Leonard Richardson

L0: Plain Old Xml

L1: ResourcesL0: Plain Old Xml

L2: HTTP Verbs L1: ResourcesL0: Plain Old Xml

L3: Hypermedia L2: HTTP Verbs L1: ResourcesL0: Plain Old Xml

reasonable compliance?

L2 is achievable with minimal effort in Rails

getting back to the point

Don’t mix machine stuff with human stuff

APIs are for machines

mixing the two causes trouble

basically, doing this causes troubledef index respond_to do |format| e format.html format.json { render :json => Project.all.to_json } endend

because, people like usable apps

separate API controllers from website controllers

or beyond even that...

your app only exposes APIs your website is a separate applicationthat consumes these APIs; think NewTwitter

don’t design exclusively for ActiveResource it isn’t a standard

HTTP status codes

rails has nice defaults 201 for creates 401 for auth violations 405 for L2 violations 406 for Content-Type violations 422 for invalid data 500 for server faults 200 for everything else

let rails help you

what they missed

404

409

assert on status codes gem install rspec-http response.should be_im_a_teapot

Authentication

OAuth 2 is nice

be an OAuth provider consistency makes life easier

https://

Caching

go beyond Rails’ local caches

the Cache-Control header is your friend

Versioning

successful APIs change

good versioning is criticalpublish clear roadmaps and deprecate sensibly

Content Types

don’t tunnelapplication/x-www-form-urlencoded

Accept headers

“http://localhost:3000/user.xml”

rails respects it you should use it

Important stuff that we’ve never done

Throttlinghttps://github.com/dambalah/api-throttling (thanks @godfoca)

Metering

Consumer

rails API vs. everything else

ActiveResource

60:40

the rest of the time you monkeypatch but that isn’t so easy, so be careful

ActiveResource works best inside a walled garden (IMHO)

Producer maturity

some APIs are weird

everyone’s standardizing on REST but it’s what they call REST

suffice to say, one size doesn’t fit all except for OAuth 2, which everyone’s adopting

building a clean domain model for the API is key

OAuth 2 is ridiculously easy to write a client for #justSaying https://github.com/kaiwren/wrest/tree/master/ examples/facebook_auth

authorisation on the otherhand still has no standard implementation

What should a good HTTP client do for you?

this one needs bullets• Verbs - should support GET, POST, PUT & DELETE.• If it supports PATCH & OPTIONS, epic.• Transparent deserialization of XML and JSON, with the option to easily add more• HTTP caching (RFC 2616)• Keep-alive connections (because negotiating SSL can get expensive)• Thread safety• Transparent compression/decompression using Accept-Encoding• A fluent, easy to use API

most importantly...

verbs

serializationI rather like ActiveSupport

caching RFC 2616

thread safety

fluent apiis it easy to work with uris, because you’ll do a fair bit of that when building domains

is it easy to build a domain model using it?

logging/debugging

Shared stuff

serialization/deserialization

libxmlActiveSupport::XmlMini.backend = Nokogiri

BuilderPure Ruby XML serializer. Pretty Fast. Just does String concats.

gotcha

no DOM for Builderso no guarantee that you get valid XML

testingthis can be tricky

Conclusion

respect HTTP

respect REST constraints

spend less time messing with plumbing

focus on building a clean domain model

Photo creditsDavid Blackwell, Elephant in Room: http://www.flickr.com/photos/mobilestreetlife

Funny picture?cat with mausambi hat

42 Sidu Ponnappa Niranjan Paranjapehttp://twitter.com/ponnappa http://twitter.com/niranjan_phttps://github.com/kaiwren https://github.com/achamian

I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem

by Sidu Ponnappa on May 31, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 1,645

Statistics

I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem — Presentation Transcript