Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
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....
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 ...
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”
“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/...
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.•   Tran...
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://git...
I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem
I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem
I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem
I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem
I can haz HTTP - Consuming and producing HTTP APIs in the Ruby ecosystem
Prochain SlideShare
Chargement dans…5
×

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

5 718 vues

Publié le

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.

Publié dans : Technologie
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website! http://bit.ly/resumpro
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

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

  1. 1. I can haz HTTPConsuming and producing HTTP APIs in theRuby ecosystem
  2. 2. sidu ponnappa
  3. 3. kaiwren
  4. 4. @ponnappa
  5. 5. niranjan paranjape
  6. 6. achamian
  7. 7. @niranjan_p
  8. 8. Engineeringhttp://github.com/c42
  9. 9. Open Source (gem install) wrest(gem install) pox_paginate
  10. 10. Not about HTTP libs not per se...
  11. 11. More about...
  12. 12. REST
  13. 13. caching
  14. 14. serialisation & deserialisation
  15. 15. authentication
  16. 16. stuff like that...
  17. 17. Producer / Consumer
  18. 18. Producer
  19. 19. digression
  20. 20. RESTful?
  21. 21. Leonard Richardson
  22. 22. L0: Plain Old Xml
  23. 23. L1: ResourcesL0: Plain Old Xml
  24. 24. L2: HTTP Verbs L1: ResourcesL0: Plain Old Xml
  25. 25. L3: Hypermedia L2: HTTP Verbs L1: ResourcesL0: Plain Old Xml
  26. 26. reasonable compliance?
  27. 27. L2 is achievable with minimal effort in Rails
  28. 28. getting back to the point
  29. 29. Don’t mix machine stuff with human stuff
  30. 30. APIs are for machines
  31. 31. mixing the two causes trouble
  32. 32. basically, doing this causes troubledef index respond_to do |format| e format.html format.json { render :json => Project.all.to_json } endend
  33. 33. because, people like usable apps
  34. 34. separate API controllers from website controllers
  35. 35. or beyond even that...
  36. 36. your app only exposes APIs your website is a separate applicationthat consumes these APIs; think NewTwitter
  37. 37. don’t design exclusively for ActiveResource it isn’t a standard
  38. 38. HTTP status codes
  39. 39. 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
  40. 40. let rails help you
  41. 41. what they missed
  42. 42. 404
  43. 43. 409
  44. 44. assert on status codes gem install rspec-http response.should be_im_a_teapot
  45. 45. Authentication
  46. 46. OAuth 2 is nice
  47. 47. be an OAuth provider consistency makes life easier
  48. 48. https://
  49. 49. Caching
  50. 50. go beyond Rails’ local caches
  51. 51. the Cache-Control header is your friend
  52. 52. Versioning
  53. 53. successful APIs change
  54. 54. good versioning is criticalpublish clear roadmaps and deprecate sensibly
  55. 55. Content Types
  56. 56. don’t tunnelapplication/x-www-form-urlencoded
  57. 57. Accept headers
  58. 58. “http://localhost:3000/user.xml”
  59. 59. “http://localhost:3000/user.xml”
  60. 60. rails respects it you should use it
  61. 61. Important stuff that we’ve never done
  62. 62. Throttlinghttps://github.com/dambalah/api-throttling (thanks @godfoca)
  63. 63. Metering
  64. 64. Consumer
  65. 65. rails API vs. everything else
  66. 66. ActiveResource
  67. 67. 60:40
  68. 68. the rest of the time you monkeypatch but that isn’t so easy, so be careful
  69. 69. ActiveResource works best inside a walled garden (IMHO)
  70. 70. Producer maturity
  71. 71. some APIs are weird
  72. 72. everyone’s standardizing on REST but it’s what they call REST
  73. 73. suffice to say, one size doesn’t fit all except for OAuth 2, which everyone’s adopting
  74. 74. building a clean domain model for the API is key
  75. 75. OAuth 2 is ridiculously easy to write a client for #justSaying https://github.com/kaiwren/wrest/tree/master/ examples/facebook_auth
  76. 76. authorisation on the otherhand still has no standard implementation
  77. 77. What should a good HTTP client do for you?
  78. 78. 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
  79. 79. most importantly...
  80. 80. verbs
  81. 81. serializationI rather like ActiveSupport
  82. 82. caching RFC 2616
  83. 83. thread safety
  84. 84. fluent apiis it easy to work with uris, because you’ll do a fair bit of that when building domains
  85. 85. is it easy to build a domain model using it?
  86. 86. logging/debugging
  87. 87. Shared stuff
  88. 88. serialization/deserialization
  89. 89. libxmlActiveSupport::XmlMini.backend = Nokogiri
  90. 90. BuilderPure Ruby XML serializer. Pretty Fast. Just does String concats.
  91. 91. gotcha
  92. 92. no DOM for Builderso no guarantee that you get valid XML
  93. 93. testingthis can be tricky
  94. 94. Conclusion
  95. 95. respect HTTP
  96. 96. respect REST constraints
  97. 97. spend less time messing with plumbing
  98. 98. focus on building a clean domain model
  99. 99. Photo creditsDavid Blackwell, Elephant in Room: http://www.flickr.com/photos/mobilestreetlife
  100. 100. Funny picture?cat with mausambi hat
  101. 101. 42 Sidu Ponnappa Niranjan Paranjapehttp://twitter.com/ponnappa http://twitter.com/niranjan_phttps://github.com/kaiwren https://github.com/achamian

×