REST in peace: a handbook of software waste @ Jazoon 2011 06-22-2011

SPEAKER‘S COMPANY

LOGO

REST in peaceA handbook of software waste

Alessandro Nadalin

DNSEE

430

SPEAKER‘S COMPANY

LOGO

2

AGENDA

> Vol. 1: REST in a nutshell

– Tenets

– Antipatterns

> WWW: a tremendous architecture

– Stateless

– Layered

– Cacheable

– Fault-tolerant

– Failure-prone

> Vol. 2: To the rescue

– HTTP cache

– ESI

– HATEOAS

> Vol. 3: REST is not a panacea

– SOAP

– Limited horizon

– Agile development

SPEAKER‘S COMPANY

LOGO

Sorry for the ugly slide.

There will be others.Really sorry.

SPEAKER‘S COMPANY

LOGO

REST in a nutshell:

1. Client <> Server

SPEAKER‘S COMPANY

LOGO

REST in a nutshell:

2. Stateless

SPEAKER‘S COMPANY

LOGO

3. Cacheable

REST in a nutshell:

SPEAKER‘S COMPANY

LOGO

REST in a nutshell:

4. Layered system

SPEAKER‘S COMPANY

LOGO

REST in a nutshell:

5. Uniform interface

SPEAKER‘S COMPANY

LOGO

9

And obviously nobody had a clue

SPEAKER‘S COMPANY

LOGO

10

ANTIPATTERNS

SPEAKER‘S COMPANY

LOGO

1URIs

SPEAKER‘S COMPANY

LOGO

"REST is about

cool URI design"

http://apple.com/users/1/licenses/4.json

SPEAKER‘S COMPANY

LOGO

"REST is about

cool URI design"

http://apple.com/users/1/licenses/4.json

SPEAKER‘S COMPANY

LOGO

http://apple.com/site/en_US/showUsers.jsp?uid=1&license=4

is OK too

SPEAKER‘S COMPANY

LOGO

but

SPEAKER‘S COMPANY

LOGO

cool URIs help youthink in term of resources

David Zuelke

SPEAKER‘S COMPANY

LOGO

2URIs (bis)

SPEAKER‘S COMPANY

LOGO

GET /users POST /users PUT /users/{id} DELETE /users/{id} ...

REST follows a URI schema

SPEAKER‘S COMPANY

LOGO

GET /users POST /users PUT /users/{id} DELETE /users/{id} ...

REST follows a URI schema

SPEAKER‘S COMPANY

LOGO

what if you change yourURL?

SPEAKER‘S COMPANY

LOGO

Yeah, client is broken

SPEAKER‘S COMPANY

LOGO

RESTful clients shouldbe driven by service'shypermedia controls

Roy Fielding : http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

SPEAKER‘S COMPANY

LOGO

HATEOAS

SPEAKER‘S COMPANY

LOGO

3POST is cool

SPEAKER‘S COMPANY

LOGO

said SOAP

SPEAKER‘S COMPANY

LOGO

said SOAP

SPEAKER‘S COMPANY

LOGO

loosing meaningful verbs at the protocol level

SPEAKER‘S COMPANY

LOGO


nothing cacheable by default

SPEAKER‘S COMPANY

LOGO


nothing cacheable by default

what about bookmarking?

SPEAKER‘S COMPANY

LOGO

30

Have a break

SPEAKER‘S COMPANY

LOGO

31

The WWW

SPEAKER‘S COMPANY

LOGO

32

the largest data-exchange network on the planet

SPEAKER‘S COMPANY

LOGO

33

And meanwhile, at Facebook...

12TB of new data every day(1 year ago)

500 million users

SPEAKER‘S COMPANY

LOGO

34

via HTTP, baby!

SPEAKER‘S COMPANY

LOGO

HTTP in a nutshell:

1. Client <> Server

SPEAKER‘S COMPANY

LOGO

HTTP in a nutshell:

2. Stateless

SPEAKER‘S COMPANY

LOGO

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

3. widespread cache spec

HTTP in a nutshell:

SPEAKER‘S COMPANY

LOGO

HTTP in a nutshell:

4. Layered systemOrigin server

Reverse proxy

Great chinese (fire)wall

Company proxy

Lao Tze Song office's laptop

SPEAKER‘S COMPANY

LOGO

HTTP in a nutshell:

5. it is the uniform interfacebetween clients and servers

SPEAKER‘S COMPANY

LOGO

40

HTTP bleeds REST

SPEAKER‘S COMPANY

LOGO

Vol.2Implementing all this goodness

SPEAKER‘S COMPANY

LOGO

1.

caching & scalability

SPEAKER‘S COMPANY

LOGO

Caching withExpiration

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comExpires: 0

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comExpires: 0

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comExpires: Tue, 31 Jan 2011 01:00 GMT

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comCache-Control: max-age=60, public

SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO


Cacheable for 60 seconds

SPEAKER‘S COMPANY

LOGO

GET / HTTP/1.1Host: www.example.comCache-Control: max-age=60, public

Cacheable by both local and shared caches

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comCache-Control: stale-if-error=600, stale-while-revalidate=600

SPEAKER‘S COMPANY

LOGO


fault-tolerant

SPEAKER‘S COMPANY

LOGO


available during downtime

SPEAKER‘S COMPANY

LOGO


available during revalidation

SPEAKER‘S COMPANY

LOGO

Caching withValidation

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comEtag: 1234

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 200 OKHost: www.example.comEtag: 1234

an identifier for your response

SPEAKER‘S COMPANY

LOGO

GET / HTTP/1.1Host: www.example.comIf-None-Match: 1234

the browsers asks you if it has been modified

Conditional requests

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 304 Not Modified

SPEAKER‘S COMPANY

LOGO

Calculating an Etag is cheaper than generating a full MVC response

SPEAKER‘S COMPANY

LOGO

but hey, you say

SPEAKER‘S COMPANY

LOGO

HTTP's 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 )

SPEAKER‘S COMPANY

LOGO

Nope

Nope

SPEAKER‘S COMPANY

LOGO

ESI was built for thathttp://www.w3.org/TR/esi-lang

SPEAKER‘S COMPANY

LOGO

Edge Side Includes

Server side includes ( not SSI! ) usually handled by the architecture's ESI processor.

http://www.w3.org/TR/esi-langhttp://www.w3.org/TR/edge-arch

SPEAKER‘S COMPANY

LOGO

<esi:include src="http://jazoon.com/talks/1" />

SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO

15 seconds cache

1 day cache

SPEAKER‘S COMPANY

LOGO

<esi:include src='tweets.html' />

<esi:include src='footer.html' />

SPEAKER‘S COMPANY

LOGO

and hey, Varnish is a reverse proxy implementing what you need of the ESI specification

take 2, pay for 1

SPEAKER‘S COMPANY

LOGO

So what does HTTP cache is meant to solve?

SPEAKER‘S COMPANY

LOGO

Less work

SPEAKER‘S COMPANY

LOGO

because the hard work is delegated to the browser/proxy

http://www.flickr.com/photos/snakphotography/5004775320/sizes/o/in/photostream/

SPEAKER‘S COMPANY

LOGO

evolve

SPEAKER‘S COMPANY

LOGO

because cache is abstracted from the application

SPEAKER‘S COMPANY

LOGO

loose coupling

SPEAKER‘S COMPANY

LOGO

because caching is bound to the protocol, HTTP, not to your implementation ( Sf, RoR, Django )

SPEAKER‘S COMPANY

LOGO

2.

adaptability & durability

SPEAKER‘S COMPANY

LOGO

Hypermediaanother long-time friend

SPEAKER‘S COMPANY

LOGO

Linksoutrageously semplifying

SPEAKER‘S COMPANY

LOGO

<link rel="payment" href="/checkout" type="text/html" ... />

SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO


SPEAKER‘S COMPANY

LOGO

HTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /users/1

POST /usersHost: www.example.com

SPEAKER‘S COMPANY

LOGO

HTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /users/1


SPEAKER‘S COMPANY

LOGO

HTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /new-users-db/1


SPEAKER‘S COMPANY

LOGO

HTTP/1.1 201 CreatedHost: www.example.comEtag: 1234X-Powered-By: php/5.3Location: /new-users-db/1


SPEAKER‘S COMPANY

LOGO

consumers of your API are able to followthe changes of your design

SPEAKER‘S COMPANY

LOGO

everything seems cool

But why REST?

SPEAKER‘S COMPANY

LOGO

Pros

Performances

SPEAKER‘S COMPANY

LOGO

Pros

Scalability

SPEAKER‘S COMPANY

LOGO

SPEAKER‘S COMPANY

LOGO

Pros

Durability

SPEAKER‘S COMPANY

LOGO

"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 directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. "

Roy Fielding

SPEAKER‘S COMPANY

LOGO

Put a bit of REST

everywhere

SPEAKER‘S COMPANY

LOGO

Rules of good design

SPEAKER‘S COMPANY

LOGO

Use natives=

Eliminate waste

SPEAKER‘S COMPANY

LOGO

The wheel!

HTTP - 1991~1997

REST - 2000

SPEAKER‘S COMPANY

LOGO

Vol.3REST is not a panacea

SPEAKER‘S COMPANY

LOGO

SOAPNo need to re-invent the wheel: if you need to do SOAP integration, SOAP

is the way.

If you have a completely functional SOAP service, no - apparent - need to rewrite it RESTful from scratch.

SPEAKER‘S COMPANY

LOGO

AGILE

The last responsible moment conflicts with REST.

But quality enhance agility: REST is quality.

SPEAKER‘S COMPANY

LOGO

LIMITED HORIZON

My blog won't ever be RESTful.

But incremental design, bare it in mind.

SPEAKER‘S COMPANY

LOGO

Alessandro Nadalin odino.orgDNSEE @_odino_Rome github.com/odino

SPEAKER‘S COMPANY

LOGO

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

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

Technology

REST in peace: a handbook of software waste @ Jazoon 2011 06-22-2011