RESTful architectures and the advantage for HTTP consumers. Focused on what matters to the mobile world: performances & scalability.

1. REST
in (a mobile) peace
May, 21st 2011
Alessandro Nadalin

2. Agenda
Rest in a nutshell
REST antipattern
REST for the mobile world
How
HTTP cache
fault-tolerance, downtime-availability
ESI
Atom + Hypermedia controls
Why
performances
evolution cost
adaptability

3. Sorry for the ugly slide.
There will be others.
Really sorry.

4. A nutshell
in (a mobile) peace

5. Let's go back!

6. 2000
Fielding's dissertation:
REpresentational
State
Transfer
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

7. REST in a nutshell:

8. REST in a nutshell:
1. Client <> Server

9. REST in a nutshell:
2. Stateless

10. easy to
scale

11. Recover and
failover
paradise

12. What about
the user
session?

13. Must
die

14. REST in a nutshell:
3. Cacheable

15. 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.

16. REST in a nutshell:
4. Layered system

17. REST in a nutshell:
5. Uniform
interface

18. Uniform interface
hierarchic resource identification
Verbs to perform operations
manipulation through representation
HATEOAS

19. 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

20. Richardson maturity model
mess
hierarchic resource identification
Verbs to perform operations
HATEOAS

21. Richardson maturity model
0. mess
hierarchic resource identification
Verbs to perform operations
HATEOAS

22. 0
Using HTTP

23. Without
giving a f***

24. Richardson maturity model
1. 0. mess
hierarchic resource identification
Verbs to perform operations
HATEOAS

25. 1
mytastyproduct.com/users
mytastyproduct.com/users/1/licenses/4

26. Richardson maturity model
1. 0. mess
hierarchic resource identification
2. Verbs to perform operations
HATEOAS

27. 2

28. Richardson maturity model
1. 0. mess
hierarchic resource identification
2. Verbs to perform operations
3. HATEOAS

29. 3.
GOD
http://www.slideshare.net/trilancer/why-hateoas-1547275

30. Hyperlinks

31. Hypermedia formats
http://amundsen.com/hypermedia/

32. Single entry point

33. Uniform interface is interesting.
Everyone seem to have its own RESTful "service".
But no one seem to entirely implement a uniform interface.

34. Uniform interface is interesting.
Everyone seem to have its own RESTful "service".
But no one seem to entirely implement a uniform interface.
That means... ...?

35. No
RESTful
stuff

36. But don't be too religious.
REST gets raped everyday,
get over it.

37. ( a few ) ANTIPATTERNS
in (a mobile) peace

38. 1
URIs

39. "REST is about
cool URI design"
http://apple.com/users/1/licenses/4.json

40. "REST is about
cool URI design"
http://apple.com/users/1/licenses/4.json

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

42. but

43. "cool URIs help you
think in term of resources"
- David Zuelke

44. and, by the way

45. a URI should never
locate different resources

46. a URI should never
locate different resources
while a resource could be
located by different URIs

47. 2
URIs (bis)

48. REST follows a URI schema

49. REST follows a URI schema
GET /users
POST /users
PUT /users/{id}
DELETE /users/{id}
...

50. REST follows a URI schema
GET /users
POST /users
PUT /users/{id}
DELETE /users/{id}
...

51. URI templates suck, some say

52. what if you change your
URL?

53. Yeah,
client is
broken

54. RESTful clients should
be driven by service's
hypermedia controls
Roy Fielding : http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

55. 3
Formats

56. REST
=
XML

57. REST
=
XML

58. a representation varies
based on the format

59. Can be:
application/xml
application/json
audio/mp4
image/png

60. Can be:
application/xml
application/json
audio/mp4
image/png
but also:
text/dns
video/vnd.motorola.video
text/uri-list

61. dear JSON, by the way

62. JSON is evil

63. {
"date": "2011-01-01",
"stock": "100",
"price": "12"
}

64. The business evolves

65. {
"date": "2011-01-01",
"stock": "100",
"price": [
{"currency": "EUR", "amount": "12"},
{"currency": "USD", "amount": "10"}
]
}
Credits: http://twitter.com/#!/odracci

66. Yeah,
client is
broken

67. Everything is a tradeoff

68. 4
POST is cool

69. said SOAP 1.1

70. said SOAP 1.1

71. loosing meaningful verbs at the protocol level

72. loosing meaningful verbs at the protocol level
nothing cacheable by default

73. loosing meaningful verbs at the protocol level
nothing cacheable by default
what about bookmarking?

74. 5
500 is your friend

75. said SOAP
( again )

76. GET /users/300
Host: www.example.com

77. GET /users/300
Host: www.example.com
HTTP/1.1 500 Internal Server Error
Etag: 1234
X-Powered-By: php/5.3
...
The record cannot be found

78. GET /users/300
Host: www.example.com
HTTP/1.1 500 Internal Server Error
Etag: 1234
X-Powered-By: php/5.3
...
The record cannot be found

79. The HTTP protocol is awesome,
and lets you return meaningful and
universally-understood status codes

80. 404 Not Found

81. 404 Not Found
OMG Link is broken?

82. 202 Accepted

83. 202 Accepted
You get an immediate OK, and the operation will hopefully complete

84. 412 Precondition Failed

85. 412 Precondition Failed
Want money?.. Got money?

86. The serious s**t
in (a mobile) peace

87. How do I
implement
this
goodness?

88. 1.
caching & scalability

89. HTTP
your long-time friend

90. Types of cache
Local
Shared/proxy
Shared/reverse proxy

91. Types of cache
Local
Shared/proxy
Shared/reverse proxy

93. Types of cache
Local
Shared/proxy
Shared/reverse proxy

95. Types of cache
Local
Shared/proxy
Shared/reverse proxy

97. on the server side

98. Proxy Reverse proxy
http://www.codeproject.com/KB/aspnet/ExploringCaching.aspx

99. There is something cool about
caching softwares.

100. Free as free beer

101. ...but the server should
take advantage of them
( the boring part were you need to write code )

102. and here are a few ways to do so,
using

103. and here are a few ways to do so,
using
expiration

104. and here are a few ways to do so,
using
expiration
validation

105. and here are a few ways to do so,
using
expiration
validation
invalidation

106. and here are a few ways to do so,
using
expiration
validation
we will se why
invalidation

107. Expiration

108. GET / HTTP/1.1
Host: www.example.com
Expires: 0

109. GET / HTTP/1.1
Host: www.example.com
Expires: 0

110. GET / HTTP/1.1
Host: www.example.com
Expires: Tue, 15 Nov 1994 01:00 GMT

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

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

113. GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=60, public
Cacheable for 60 seconds

114. GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=60, public
Cacheable by both local and shared caches

115. GET / HTTP/1.1
Host: www.example.com
Cache-Control: stale-if-error=600, stale-while-revalidate=600

116. GET / HTTP/1.1
Host: www.example.com
Cache-Control: stale-if-error=600, stale-while-revalidate=600
fault-tolerant

117. GET / HTTP/1.1
Host: www.example.com
Cache-Control: stale-if-error=600, stale-while-revalidate=600
available during downtime

118. GET / HTTP/1.1
Host: www.example.com
Cache-Control: stale-if-error=600, stale-while-revalidate=600
available during revalidation

119. Validation

120. GET / HTTP/1.1
Host: www.example.com
Etag: 1234

121. GET / HTTP/1.1
Host: www.example.com
Etag: 1234
an identifier for your response

122. Conditional requests
GET / HTTP/1.1
Host: www.example.com
If-None-Match: 1234
the browsers asks you if it has been modified

123. Relax

124. Calculating an Etag is cheaper than generating a full MVC response

125. HTTP/1.1 304 Not Modified

126. GET / HTTP/1.1
Host: www.example.com
Last-Modified: Tue, 15 Jan 2011 12:00:00 GMT

127. GET / HTTP/1.1
Host: www.example.com
Last-Modified: Tue, 15 Jan 2011 12:00:00 GMT
tell the client about the latest change

128. Conditional requests
GET / HTTP/1.1
Host: www.example.com
If-Modified-Since: Tue, 15 Jan 2011 12:00:00 GMT
the client asks you if it has been modified since the last time

129. Relax

130. Calculating a date is cheaper than retrieving an entire object

131. HTTP/1.1 304 Not Modified

132. Invalidation

133. The web is not meant for invalidating data.
Server should not be able to keep clients' state, otherwise they
wont scale well.
That's why long-polling and endless connections haven't had
big success dealing with caching.

134. but hey, you say

135. 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 )

136. Nope
Nope

137. ESI was built for that
http://www.w3.org/TR/esi-lang

138. Edge Side Includes
A de facto standard for bla bla bla...

139. Edge Side Includes
A de facto standard for bla bla bla...
Server side includes ( not SSI! ) usually handled by the
architecture's ESI processor.
http://www.w3.org/TR/esi-lang
http://www.w3.org/TR/edge-arch

140. <esi:include src="http://whymca.org/talks/1" />

141. <esi:include src="http://whymca.org/talks/1" />

142. <esi:include src="http://whymca.org/talks/1" />

143. This is a response

144. 15 seconds cache
30 minutes cache

145. and hey, Varnish is a reverse proxy implementing what you
need of the ESI specification
take 2, pay for 1

146. So what does HTTP cache is meant to solve?

147. Less work

148. http://www.flickr.com/photos/snakphotography/5004775320/sizes/o/in/photostream/
because the hard work is delegated to the browser/proxy

149. evolve

150. because cache is abstracted from the application

151. loose coupling

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

153. 2.
adaptability & durability

154. Hypermedia
another long-time friend

155. Links
outrageously semplifying

156. <img src="..." />
<a href="..." />
<link rel="payment" ... />

157. <img src="..." />
<a href="..." />
<link rel="payment" ... />

158. <img src="..." />
<a href="..." />
<link rel="payment" ... />

159. Atomis your friend
http://www.xml.com/lpt/a/1434

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

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

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

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

164. POST /users
Host: www.example.com

165. POST /users
Host: www.example.com
HTTP/1.1 201 Created
Host: www.example.com
Etag: 1234
X-Powered-By: php/5.3
Location: /users/1

166. POST /users
Host: www.example.com
HTTP/1.1 201 Created
Host: www.example.com
Etag: 1234
X-Powered-By: php/5.3
Location: /users/1

167. POST /users
Host: www.example.com

168. POST /users
Host: www.example.com
HTTP/1.1 301 Moved permanently
Host: www.example.com
Location: /users

169. POST /users
Host: www.example.com

170. POST /users
Host: www.example.com
HTTP/1.1 201 Created
Host: www.example.com
Etag: 1234
X-Powered-By: php/5.3
Location: /newusersdatabase/1

171. POST /users
Host: www.example.com
HTTP/1.1 201 Created
Host: www.example.com
Etag: 1234
X-Powered-By: php/5.3
Location: /newusersdatabase/1

172. POST /users
Host: www.example.com
Helps refactoring legacy stuff indeed :)
HTTP/1.1 201 Created
Host: www.example.com
Etag: 1234
X-Powered-By: php/5.3
Location: /newusersdatabase/1

173. consumers of your API are able to follow
the changes of your design

174. Clients are too important
to break'em

175. and here comes a controversial part...

176. Like it or not,
XML is a friend of the
non BC-breaking evolution
http://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

177. BTW
<xml...>
<product...>
<price>25</price>
</product>
</xml>

178. BTW
<xml...>
<product...>
<price currency="EUR">25</price>
<price currency="USD">23</price>
</product>
</xml>

179. As said, everything is a tradeoff

180. Choose the media type
for your needs

181. No need to be religious. Ever.

182. Why being
in (a mobile) peace?

183. everything seems cool

184. everything seems cool
but
why REST?

185. Pros
Performances

187. Pros
Scalability

188. 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

189. Pros
Durability

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

191. Put a bit of
REST
everywhere

192. Rules of good
design

193. amazon.it

195. Alessandro Nadalin

196. Alessandro Nadalin
odino.org

197. Alessandro Nadalin
odino.org
@_odino_

198. Alessandro Nadalin
odino.org
@_odino_

199. Thanks
Alessandro Nadalin
odino.org
@_odino_

200. 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/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/