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

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

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

"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

"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} ...

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

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

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

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/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: 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 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

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

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" />

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

Atomis your friendhttp://www.xml.com/lpt/a/1434

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 301 Moved permanentlyHost: www.example.comLocation: /users

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_

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/

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

by Alessandro Nadalin

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 58

Statistics

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

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