REST in ( a mobile ) peace @ WHYMCA 05-21-2011
Upcoming SlideShare
Loading in...5
×
 

REST in ( a mobile ) peace @ WHYMCA 05-21-2011

on

  • 3,270 views

RESTful architectures and the advantage for HTTP consumers.

RESTful architectures and the advantage for HTTP consumers.

Focused on what matters to the mobile world: performances & scalability.

Statistics

Views

Total Views
3,270
Views on SlideShare
3,211
Embed Views
59

Actions

Likes
3
Downloads
34
Comments
1

4 Embeds 59

http://www.whymca.org 32
http://www.odino.org 23
http://twitter.com 3
http://odino.org 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

REST in ( a mobile ) peace @ WHYMCA 05-21-2011 REST in ( a mobile ) peace @ WHYMCA 05-21-2011 Presentation Transcript

  • REST in (a mobile) peace May, 21st 2011Alessandro Nadalin
  • AgendaRest in a nutshellREST antipatternREST for the mobile world How HTTP cache fault-tolerance, downtime-availability ESI Atom + Hypermedia controls Why performances evolution cost adaptability
  • Sorry for the ugly slide. There will be others. Really sorry.
  • A nutshellin (a mobile) peace
  • Lets go back!
  • 2000Fieldings dissertation:REpresentationalStateTransferhttp://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
  • REST in a nutshell:
  • REST in a nutshell:1. Client <> Server
  • REST in a nutshell: 2. Stateless
  • easy to scale
  • Recover and failover paradise
  • What about the user session?
  • Must die
  • REST in a nutshell: 3. Cacheable
  • REST in a nutshell: When dealing with safe methods, the response should be able to tell the client, or whatever stands behind the request, how to cache it.
  • REST in a nutshell:4. Layered system
  • REST in a nutshell: 5. Uniform interface
  • Uniform interface hierarchic resource identification Verbs to perform operations manipulation through representation HATEOAS
  • Richardson maturity model hierarchic resource identification Verbs to perform operations manipulation through representation HATEOAS Really well explained by Fowler: http://martinfowler. com/articles/richardsonMaturityModel.html#level0
  • Richardson maturity model mess hierarchic resource identification Verbs to perform operations HATEOAS
  • Richardson maturity model 0. mess hierarchic resource identification Verbs to perform operations HATEOAS
  • 0Using HTTP
  • Withoutgiving a f***
  • Richardson maturity model 1. 0. mess hierarchic resource identification Verbs to perform operations HATEOAS
  • 1 mytastyproduct.com/usersmytastyproduct.com/users/1/licenses/4
  • Richardson maturity model 1. 0. mess hierarchic resource identification 2. Verbs to perform operations HATEOAS
  • 2
  • Richardson maturity model 1. 0. mess hierarchic resource identification 2. Verbs to perform operations 3. HATEOAS
  • 3. GODhttp://www.slideshare.net/trilancer/why-hateoas-1547275
  • Hyperlinks
  • Hypermedia formats http://amundsen.com/hypermedia/
  • Single entry point
  • Uniform interface is interesting.Everyone seem to have its own RESTful "service".But no one seem to entirely implement a uniform interface.
  • Uniform interface is interesting.Everyone seem to have its own RESTful "service".But no one seem to entirely implement a uniform interface. That means... ...?
  • NoRESTful stuff
  • But dont be too religious.REST gets raped everyday,get over it.
  • ( a few ) ANTIPATTERNS in (a mobile) peace
  • 1URIs
  • "REST is about cool URI design"http://apple.com/users/1/licenses/4.json
  • "REST is about cool URI design"http://apple.com/users/1/licenses/4.json
  • http://apple.com/site/en_US/showUsers.jsp?uid=1&license=4 is OK too
  • but
  • "cool URIs help youthink in term of resources" - David Zuelke
  • and, by the way
  • a URI should neverlocate different resources
  • a URI should neverlocate different resourceswhile a resource could belocated by different URIs
  • 2URIs (bis)
  • REST follows a URI schema
  • REST follows a URI schema GET /users POST /users PUT /users/{id} DELETE /users/{id} ...
  • REST follows a URI schema GET /users POST /users PUT /users/{id} DELETE /users/{id} ...
  • URI templates suck, some say
  • what if you change your URL?
  • Yeah,client isbroken
  • RESTful clients should be driven by services hypermedia controlsRoy Fielding : http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  • 3Formats
  • REST =XML
  • REST =XML
  • a representation varies based on the format
  • Can be:application/xmlapplication/jsonaudio/mp4image/png
  • Can be: application/xml application/json audio/mp4 image/pngbut also:text/dnsvideo/vnd.motorola.videotext/uri-list
  • dear JSON, by the way
  • JSON is evil
  • { "date": "2011-01-01", "stock": "100", "price": "12"}
  • The business evolves
  • { "date": "2011-01-01", "stock": "100", "price": [ {"currency": "EUR", "amount": "12"}, {"currency": "USD", "amount": "10"} ]} Credits: http://twitter.com/#!/odracci
  • Yeah,client isbroken
  • Everything is a tradeoff
  • 4POST is cool
  • said SOAP 1.1
  • said SOAP 1.1
  • loosing meaningful verbs at the protocol level
  • loosing meaningful verbs at the protocol level nothing cacheable by default
  • loosing meaningful verbs at the protocol level nothing cacheable by default what about bookmarking?
  • 5500 is your friend
  • said SOAP ( again )
  • GET /users/300Host: www.example.com
  • GET /users/300 Host: www.example.comHTTP/1.1 500 Internal Server ErrorEtag: 1234X-Powered-By: php/5.3...The record cannot be found
  • GET /users/300 Host: www.example.comHTTP/1.1 500 Internal Server ErrorEtag: 1234X-Powered-By: php/5.3...The record cannot be found
  • The HTTP protocol is awesome,and lets you return meaningful anduniversally-understood status codes
  • 404 Not Found
  • 404 Not FoundOMG Link is broken?
  • 202 Accepted
  • 202 AcceptedYou get an immediate OK, and the operation will hopefully complete
  • 412 Precondition Failed
  • 412 Precondition Failed Want money?.. Got money?
  • The serious s**t in (a mobile) peace
  • How do Iimplement thisgoodness?
  • 1.caching & scalability
  • HTTPyour long-time friend
  • Types of cache Local Shared/proxy Shared/reverse proxy
  • Types of cache Local Shared/proxy Shared/reverse proxy
  • Types of cache Local Shared/proxy Shared/reverse proxy
  • Types of cache Local Shared/proxyShared/reverse proxy
  • on the server side
  • Proxy Reverse proxy http://www.codeproject.com/KB/aspnet/ExploringCaching.aspx
  • There is something cool aboutcaching softwares.
  • Free as free beer
  • ...but the server should take advantage of them( the boring part were you need to write code )
  • and here are a few ways to do so,using
  • and here are a few ways to do so,using expiration
  • and here are a few ways to do so,using expiration validation
  • and here are a few ways to do so,using expiration validation invalidation
  • and here are a few ways to do so,using expiration validation we will se why invalidation
  • Expiration
  • GET / HTTP/1.1Host: www.example.comExpires: 0
  • GET / HTTP/1.1Host: www.example.comExpires: 0
  • GET / HTTP/1.1Host: www.example.comExpires: Tue, 15 Nov 1994 01:00 GMT
  • GET / HTTP/1.1Host: www.example.comCache-Control: max-age=60, public
  • GET / HTTP/1.1Host: www.example.comCache-Control: max-age=60, public
  • GET / HTTP/1.1Host: www.example.comCache-Control: max-age=60, public Cacheable for 60 seconds
  • GET / HTTP/1.1Host: www.example.comCache-Control: max-age=60, publicCacheable by both local and shared caches
  • GET / HTTP/1.1Host: www.example.comCache-Control: stale-if-error=600, stale-while-revalidate=600
  • GET / HTTP/1.1Host: www.example.comCache-Control: stale-if-error=600, stale-while-revalidate=600 fault-tolerant
  • GET / HTTP/1.1Host: www.example.comCache-Control: stale-if-error=600, stale-while-revalidate=600 available during downtime
  • GET / HTTP/1.1Host: www.example.comCache-Control: stale-if-error=600, stale-while-revalidate=600 available during revalidation
  • Validation
  • GET / HTTP/1.1Host: www.example.comEtag: 1234
  • GET / HTTP/1.1 Host: www.example.com Etag: 1234an identifier for your response
  • Conditional requests GET / HTTP/1.1 Host: www.example.com If-None-Match: 1234the browsers asks you if it has been modified
  • Relax
  • Calculating an Etag is cheaper than generating a full MVC response
  • HTTP/1.1 304 Not Modified
  • GET / HTTP/1.1Host: www.example.comLast-Modified: Tue, 15 Jan 2011 12:00:00 GMT
  • GET / HTTP/1.1Host: www.example.comLast-Modified: Tue, 15 Jan 2011 12:00:00 GMT tell the client about the latest change
  • Conditional requestsGET / HTTP/1.1Host: www.example.comIf-Modified-Since: Tue, 15 Jan 2011 12:00:00 GMT the client asks you if it has been modified since the last time
  • Relax
  • Calculating a date is cheaper than retrieving an entire object
  • HTTP/1.1 304 Not Modified
  • Invalidation
  • The web is not meant for invalidating data.Server should not be able to keep clients state, otherwise they wont scale well.Thats why long-polling and endless connections havent had big success dealing with caching.
  • but hey, you say
  • HTTPs cache fails when dealing with really dynamic pages,because consumers will always have to hit the origin server,although a part of the page would be cacheable ( header and footer, for example )
  • Nope Nope
  • ESI was built for that http://www.w3.org/TR/esi-lang
  • Edge Side Includes A de facto standard for bla bla bla...
  • Edge Side Includes A de facto standard for bla bla bla... Server side includes ( not SSI! ) usually handled by the architectures ESI processor. http://www.w3.org/TR/esi-lang http://www.w3.org/TR/edge-arch
  • <esi:include src="http://whymca.org/talks/1" />
  • <esi:include src="http://whymca.org/talks/1" />
  • <esi:include src="http://whymca.org/talks/1" />
  • This is a response
  • 15 seconds cache30 minutes cache
  • and hey, Varnish is a reverse proxy implementing what you need of the ESI specification take 2, pay for 1
  • So what does HTTP cache is meant to solve?
  • Less work
  • http://www.flickr.com/photos/snakphotography/5004775320/sizes/o/in/photostream/ because the hard work is delegated to the browser/proxy
  • evolve
  • because cache is abstracted from the application
  • loose coupling
  • because caching is bound to the protocol, HTTP, notto your implementation ( Sf, RoR, Django )
  • 2.adaptability & durability
  • Hypermedia another long-time friend
  • Linksoutrageously semplifying
  • <img src="..." /><a href="..." /><link rel="payment" ... />
  • <img src="..." /><a href="..." /><link rel="payment" ... />
  • <img src="..." /><a href="..." /><link rel="payment" ... />
  • Atomis your friendhttp://www.xml.com/lpt/a/1434
  • <link rel="payment" href="/checkout" type="text/html" ... />
  • <link rel="payment" href="/checkout" type="text/html" ... />
  • <link rel="payment" href="/checkout" type="text/html" ... />
  • <link rel="payment" href="/checkout" type="text/html" ... />
  • POST /usersHost: www.example.com
  • POST /users Host: www.example.comHTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /users/1
  • POST /users Host: www.example.comHTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /users/1
  • POST /usersHost: www.example.com
  • POST /users Host: www.example.comHTTP/1.1 301 Moved permanentlyHost: www.example.comLocation: /users
  • POST /usersHost: www.example.com
  • POST /users Host: www.example.comHTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /newusersdatabase/1
  • POST /users Host: www.example.comHTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /newusersdatabase/1
  • POST /users Host: www.example.com Helps refactoring legacy stuff indeed :)HTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /newusersdatabase/1
  • consumers of your API are able to follow the changes of your design
  • Clients are too important to breakem
  • and here comes a controversial part...
  • Like it or not, XML is a friend of the non BC-breaking evolutionhttp://www.slideshare.net/Wombert/xml-versus-the-new-kids-on-the-block-phpbnl11-20110129 http://www.odino.org/320/long-live-xml-too-sorry-for-json-fanboyz
  • BTW<xml...> <product...> <price>25</price> </product></xml>
  • BTW<xml...> <product...> <price currency="EUR">25</price> <price currency="USD">23</price> </product></xml>
  • As said, everything is a tradeoff
  • Choose the media type for your needs
  • No need to be religious. Ever.
  • Why being in (a mobile) peace?
  • everything seems cool
  • everything seems cool but why REST?
  • ProsPerformances
  • ProsScalability
  • http://articles.sfgate.com/2011-02-20/opinion/28613184_1_news-network-cable-and-satellite-website http://tech.groups.yahoo.com/group/rest-discuss/message/17370 +2.500% traffic
  • Pros Durability
  • "REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directlyopposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. " Roy Fielding
  • Put a bit of RESTeverywhere
  • Rules of good design
  • amazon.it
  • Alessandro Nadalin
  • Alessandro Nadalin odino.org
  • Alessandro Nadalin odino.org @_odino_
  • Alessandro Nadalin odino.org @_odino_
  • ThanksAlessandro Nadalin odino.org @_odino_
  • Credits http://www.flickr.com/photos/larachris/16564077/sizes/o/in/photostream/ http://www.flickr.com/photos/ashatenbroeke/4367373081/sizes/z/in/photostream/ http://www.flickr.com/photos/yourdon/3140270189/sizes/l/in/photostream/ http://www.flickr.com/photos/jox1989/4964706072/sizes/l/in/photostream/ http://www.flickr.com/photos/brainfg/168506259/sizes/o/in/photostream/ http://www.flickr.com/photos/norte_it/3897091546/sizes/o/in/photostream/ http://www.zdnet.com/blog/service-oriented/soap-versus-rest-a-matter-of-style/3568http://www.flickr.com/photos/turtlemom_nancy/2046347762/sizes/l/in/photostream/ http://www.flickr.com/photos/juanpg/3333385784/sizes/z/in/photostream/ http://www.flickr.com/photos/congvo/301678287/sizes/l/in/photostream/ http://www.flickr.com/photos/ihasb33r/2573196546/sizes/z/in/photostream/ http://www.flickr.com/photos/martin_heigan/4544138976/sizes/o/in/photostream/ http://www.flickr.com/photos/cknara/4195099999/sizes/o/in/photostream/ http://www.flickr.com/photos/1080p/3076529265/sizes/l/in/photostream/ http://www.flickr.com/photos/adamrice/280300202/sizes/l/in/photostream/ http://www.flickr.com/photos/tomer_a/541411897/sizes/o/in/photostream/ http://www.flickr.com/photos/subpra/4514008262/sizes/l/in/photostream/ http://www.flickr.com/photos/lippincott/2539720043/sizes/l/in/photostream/ http://www.flickr.com/photos/rawryder/5086090931/sizes/l/in/photostream/ http://www.flickr.com/photos/robboudon/5312731161/sizes/l/in/photostream/ http://www.flickr.com/photos/bc-burnslibrary/4158243488/sizes/o/in/photostream/http://www.flickr.com/photos/13606325@N08/2416993706/sizes/o/in/photostream/ http://www.flickr.com/photos/neothezion/5135841069/sizes/l/in/photostream/ http://www.flickr.com/photos/planetschwa/2494067809/ http://www.flickr.com/photos/thomasthomas/258931782/ http://www.flickr.com/photos/rustyboxcars/2629631562/sizes/l/in/photostream/ http://www.flickr.com/photos/ell-r-brown/4138727474/sizes/l/in/photostream/ http://www.flickr.com/photos/noah123/5082076630/sizes/z/in/photostream/ http://www.flickr.com/photos/jungle_boy/220181177/sizes/l/in/photostream/ http://www.flickr.com/photos/prettydaisies/872539081/sizes/l/in/photostream/ http://www.flickr.com/photos/kaptainkobold/76256150/sizes/o/in/photostream/ http://www.flickr.com/photos/uomoincravatta/1438372865/sizes/z/in/photostream/