intro_rest.srt - google-video-captions - Captions for Videos on Google's YouTube channels

Source path: svn/ trunk/ captions/ en/ intro_rest.srt

‹r19

r43

1
00:00:10,901 --> 00:00:12,400
Gregorio: Hi.
I'm Joe Gregorio,

2
00:00:12,400 --> 00:00:14,501
and I work in Developer
Relations at Google.

3
00:00:14,501 --> 00:00:16,367
This talk is on REST
and, in the talk,

4
00:00:16,367 --> 00:00:19,100
I presume you're familiar with
the Atom Publishing Protocol.

5
00:00:19,100 --> 00:00:21,367
If you're not,
you can watch my other video

6
00:00:21,367 --> 00:00:23,367
"An Introduction to
the Atom Publishing Protocol,"

7
00:00:23,367 --> 00:00:25,033
and then come back
and watch this one.

8
00:00:25,033 --> 00:00:26,834
So let's begin.

9
00:00:26,834 --> 00:00:28,467
You may have heard
the term REST,

10
00:00:28,467 --> 00:00:29,767
and a lot of protocols
these days

11
00:00:29,767 --> 00:00:32,467
are advertising
themselves as REST.

12
00:00:32,467 --> 00:00:34,434
REST comes
from Roy Fielding's thesis

13
00:00:34,434 --> 00:00:36,934
and stands for
Representational State Transfer.

14
00:00:36,934 --> 00:00:38,901
It's an architectural style.

15
00:00:38,901 --> 00:00:41,868
Now, an architectural style
is an abstraction

16
00:00:41,868 --> 00:00:43,601
as opposed
to a concrete thing.

17
00:00:43,601 --> 00:00:45,667
For example, this Shaker house

18
00:00:45,667 --> 00:00:48,767
is different from
the Shaker architectural style.

19
00:00:48,767 --> 00:00:50,601
The architectural style
of Shaker

20
00:00:50,601 --> 00:00:53,100
defines the attributes
or characteristics

21
00:00:53,100 --> 00:00:56,868
you would see in a house
built in that style.

22
00:00:56,868 --> 00:00:59,300
In the same way,
the REST architectural style

23
00:00:59,300 --> 00:01:01,434
is a set of architectural
constraints

24
00:01:01,434 --> 00:01:05,100
you would see in a protocol
built in that style.

25
00:01:05,100 --> 00:01:07,901
HTTP is one such protocol.

26
00:01:07,901 --> 00:01:09,133
And, for the remainder
of this talk,

27
00:01:09,133 --> 00:01:11,434
we're just going
to talk about HTTP.

28
00:01:11,434 --> 00:01:12,567
And I'll refer back

29
00:01:12,567 --> 00:01:14,067
to the architectural constraints
of REST

30
00:01:14,067 --> 00:01:16,200
as we work through
that example.

31
00:01:16,200 --> 00:01:20,634
Now, it's simply not possible
to cover every aspect HTTP,

32
00:01:20,634 --> 00:01:22,601
so at the end
of this presentation

33
00:01:22,601 --> 00:01:23,767
there will be
a further reading list,

34
00:01:23,767 --> 00:01:25,634
if you'd like to learn more.

35
00:01:25,634 --> 00:01:28,367
So why should you care
about REST?

36
00:01:28,367 --> 00:01:31,801
Well, it's the architecture
of the Web as it works today.

37
00:01:31,801 --> 00:01:33,534
And if you're going to be
building applications

38
00:01:33,534 --> 00:01:35,834
on the Web,
shouldn't you be working

39
00:01:35,834 --> 00:01:38,567
with the architecture
instead of against it?

40
00:01:38,567 --> 00:01:41,133
And, hopefully, as you see us
go through this video,

41
00:01:41,133 --> 00:01:43,167
there will be
many opportunities

42
00:01:43,167 --> 00:01:44,767
for increasing
the performance

43
00:01:44,767 --> 00:01:47,033
and scalability
of your application,

44
00:01:47,033 --> 00:01:49,167
and solve some traditionally
tricky problems

45
00:01:49,167 --> 00:01:50,868
by working with HTTP

46
00:01:50,868 --> 00:01:53,467
and taking full advantage
of its capabilities.

47
00:01:53,467 --> 00:01:55,100
Let's get some
of the basics down,

48
00:01:55,100 --> 00:01:58,100
some nomenclature
in the operation of HTTP.

49
00:01:58,100 --> 00:01:59,200
At its simplest,

50
00:01:59,200 --> 00:02:02,667
HTTP is a request
response protocol.

51
00:02:02,667 --> 00:02:05,100
You browser makes a request
to the server,

52
00:02:05,100 --> 00:02:07,334
the Web server
gives you a response.

53
00:02:07,334 --> 00:02:09,601
The beauty of the Web is
that it appears very simple,

54
00:02:09,601 --> 00:02:13,200
as if your browser is talking
directly to the server.

55
00:02:13,200 --> 00:02:14,934
So, let's look in detail

56
00:02:14,934 --> 00:02:17,734
at a specific request
and response.

57
00:02:17,734 --> 00:02:19,400
Here is a GET request

58
00:02:19,400 --> 00:02:25,300
to the URL
http://example.org/news

59
00:02:25,300 --> 00:02:27,200
and here's what
the response looks like.

60
00:02:27,200 --> 00:02:28,934
It's a 200 response

61
00:02:28,934 --> 00:02:31,434
and what you're seeing here
are the headers

62
00:02:31,434 --> 00:02:33,934
and a little bit
of the response body.

63
00:02:33,934 --> 00:02:36,767
The request is to a resource
identified by a URI,

64
00:02:36,767 --> 00:02:42,167
in this case like I said,
http://example.org/news.

65
00:02:42,167 --> 00:02:45,367
Resources or addressability
is very important.

66
00:02:45,367 --> 00:02:48,400
The request is to a resource
identified by a URI.

67
00:02:48,400 --> 00:02:53,234
In this case,
http://example.org/news.

68
00:02:53,234 --> 00:02:56,567
The URI is broken down
into two pieces.

69
00:02:56,567 --> 00:02:59,634
The path goes
into the request line,

70
00:02:59,634 --> 00:03:04,734
and you can see the host
shows up in the host header.

71
00:03:04,734 --> 00:03:06,100
There is a method

72
00:03:06,100 --> 00:03:08,734
and that's the action
to perform on the resource.

73
00:03:08,734 --> 00:03:10,667
There are actually
several different methods

74
00:03:10,667 --> 00:03:11,901
that can be used,

75
00:03:11,901 --> 00:03:15,567
GET, PUT, DELETE, HEAD,
and POST among others,

76
00:03:15,567 --> 00:03:16,734
and each of those methods

77
00:03:16,734 --> 00:03:19,300
has particular characteristics
about them.

78
00:03:19,300 --> 00:03:23,534
For example, GET is safe,
idempotent, and cacheable.

79
00:03:23,534 --> 00:03:25,267
Cacheable means
the response can be cached

80
00:03:25,267 --> 00:03:27,367
by an intermediary
along the way,

81
00:03:27,367 --> 00:03:31,200
idempotent means the request
can be done multiple times,

82
00:03:31,200 --> 00:03:33,801
and safe means
there are no side effects

83
00:03:33,801 --> 00:03:35,834
from performing that action.

84
00:03:35,834 --> 00:03:38,534
So PUT is also idempotent,

85
00:03:38,534 --> 00:03:40,834
but not safe,
and not cacheable.

86
00:03:40,834 --> 00:03:43,434
Same with DELETE,
it is idempotent.

87
00:03:43,434 --> 00:03:45,968
HEAD is safe and idempotent.

88
00:03:45,968 --> 00:03:48,601
POST has none
of those characteristics.

89
00:03:48,601 --> 00:03:50,534
Also returned
in that response

90
00:03:50,534 --> 00:03:53,200
was the representation
of that resource,

91
00:03:53,200 --> 00:03:55,067
what lives at that URI.

92
00:03:55,067 --> 00:03:56,801
The representation
is the body

93
00:03:56,801 --> 00:03:59,634
and, in this case,
it was an HTML document.

94
00:03:59,634 --> 00:04:02,667
HTML is a form
of hypertext,

95
00:04:02,667 --> 00:04:05,033
which means it has links
to other resources.

96
00:04:05,033 --> 00:04:07,467
Here is a traditional link
that you would click on

97
00:04:07,467 --> 00:04:09,701
to go to another page,

98
00:04:09,701 --> 00:04:11,367
but there's more
than one kind of link.

99
00:04:11,367 --> 00:04:12,901
Here is a link
to a CSS document

100
00:04:12,901 --> 00:04:16,200
that the browser will call
and include to style the page.

101
00:04:16,200 --> 00:04:17,868
There's also
other kinds of links.

102
00:04:17,868 --> 00:04:20,434
Here's one
to a JavaScript document

103
00:04:20,434 --> 00:04:21,934
that will get pulled in.

104
00:04:21,934 --> 00:04:24,334
This is a particularly important
kind of hypertext

105
00:04:24,334 --> 00:04:25,801
or document
that's pulled in.

106
00:04:25,801 --> 00:04:27,434
This is called Code on Demand,

107
00:04:27,434 --> 00:04:29,634
the ability to load code
into the browser

108
00:04:29,634 --> 00:04:32,267
and execute it
on the client.

109
00:04:32,267 --> 00:04:34,767
The response headers
show control data,

110
00:04:34,767 --> 00:04:36,801
such as this header
which controls how long

111
00:04:36,801 --> 00:04:39,467
the response can be cached.

112
00:04:39,467 --> 00:04:40,701
So now that we've looked

113
00:04:40,701 --> 00:04:43,567
at simple HTTP request
and response,

114
00:04:43,567 --> 00:04:45,934
let's go back and look
at some of the characteristics

115
00:04:45,934 --> 00:04:48,634
that a RESTful protocol
is supposed to have.

116
00:04:48,634 --> 00:04:50,901
Application state
and functionality

117
00:04:50,901 --> 00:04:52,868
are directed into resources.

118
00:04:52,868 --> 00:04:55,567
Those resources are
uniquely addressable

119
00:04:55,567 --> 00:04:59,100
using a universal syntax
for use in hypermedia links.

120
00:04:59,100 --> 00:05:01,968
All resources share
a uniform interface

121
00:05:01,968 --> 00:05:03,133
for transferring the state

122
00:05:03,133 --> 00:05:04,567
between the client
and the server

123
00:05:04,567 --> 00:05:08,868
consisting of a constraint set
of well-defined operations,

124
00:05:08,868 --> 00:05:11,133
a constraint set
of content types

125
00:05:11,133 --> 00:05:13,167
optionally supporting
Code on Demand,

126
00:05:13,167 --> 00:05:15,734
and a protocol
which is client-server,

127
00:05:15,734 --> 00:05:19,167
stateless, layered,
and cacheable.

128
00:05:19,167 --> 00:05:20,234
Now that we've
already talked about

129
00:05:20,234 --> 00:05:22,467
many of these aspects
with HTTP,

130
00:05:22,467 --> 00:05:25,534
we can see that
we already have resources

131
00:05:25,534 --> 00:05:27,501
that are identified by URIs,

132
00:05:27,501 --> 00:05:30,334
and those resources have
a uniform interface

133
00:05:30,334 --> 00:05:32,601
understanding
a limited set of methods

134
00:05:32,601 --> 00:05:35,868
such as GET, PUT, POST,
HEAD, and DELETE,

135
00:05:35,868 --> 00:05:38,400
and that the representations
are self-identified,

136
00:05:38,400 --> 00:05:39,801
a constraint set
of content types

137
00:05:39,801 --> 00:05:42,033
that might not
only be hypertext,

138
00:05:42,033 --> 00:05:44,167
but could also include
Code on Demand

139
00:05:44,167 --> 00:05:47,400
such as the example
we saw with JavaScript.

140
00:05:47,400 --> 00:05:51,367
And we've even seen that HTTP
is a client-server protocol.

141
00:05:51,367 --> 00:05:52,868
To discuss the remainder
of the characteristics

142
00:05:52,868 --> 00:05:54,234
of the protocol,

143
00:05:54,234 --> 00:05:55,767
we need to look
at the underlying structure

144
00:05:55,767 --> 00:05:57,234
of the Web.

145
00:05:57,234 --> 00:05:59,701
We originally started out
with a simplified example

146
00:05:59,701 --> 00:06:01,968
of how the Web appears
to a client.

147
00:06:01,968 --> 00:06:03,868
Let's switch to using
the right names

148
00:06:03,868 --> 00:06:05,701
for each of those pieces.

149
00:06:05,701 --> 00:06:08,767
They're the user agent
and the origin server.

150
00:06:08,767 --> 00:06:11,901
The reality is
that the connections

151
00:06:11,901 --> 00:06:14,334
between these pieces could be
a lot more complicated.

152
00:06:14,334 --> 00:06:17,601
There can be many intermediaries
between you and the server

153
00:06:17,601 --> 00:06:19,067
you're connecting to.

154
00:06:19,067 --> 00:06:22,334
By intermediaries,
we mean HTTP intermediaries,

155
00:06:22,334 --> 00:06:24,767
which doesn't include devices
at lower levels

156
00:06:24,767 --> 00:06:27,934
such as routers, modems,
and access points.

157
00:06:27,934 --> 00:06:29,801
Those intermediaries are

158
00:06:29,801 --> 00:06:31,501
the layered part
of the protocol,

159
00:06:31,501 --> 00:06:34,033
and that layering allows
intermediaries to be added

160
00:06:34,033 --> 00:06:36,634
at various points
in the request response path

161
00:06:36,634 --> 00:06:39,334
without changing the interfaces
between components

162
00:06:39,334 --> 00:06:41,367
where they can do things
to passing messages,

163
00:06:41,367 --> 00:06:44,868
such as translation or improving
performance with caching.

164
00:06:44,868 --> 00:06:48,200
Intermediaries include
proxies and gateways.

165
00:06:48,200 --> 00:06:49,567
Proxies are chosen
by the client,

166
00:06:49,567 --> 00:06:52,667
while gateways are chosen
by the origin server.

167
00:06:52,667 --> 00:06:55,601
Despite the slide showing
only one proxy and one gateway,

168
00:06:55,601 --> 00:06:58,167
realize there may be
several proxies and gateways

169
00:06:58,167 --> 00:07:01,167
between your user agent
and origin server,

170
00:07:01,167 --> 00:07:03,200
or there may
actually be none.

171
00:07:03,200 --> 00:07:05,567
Finally, every actor
in the chain,

172
00:07:05,567 --> 00:07:07,667
from the user agent
through the proxies

173
00:07:07,667 --> 00:07:09,701
and the gateways
to the origin server,

174
00:07:09,701 --> 00:07:11,934
may have a cache
associated with them.

175
00:07:11,934 --> 00:07:14,033
If an intermediary
does caching

176
00:07:14,033 --> 00:07:16,934
and a response indicates
that the response can be cached,

177
00:07:16,934 --> 00:07:18,634
in this case for an hour,

178
00:07:18,634 --> 00:07:20,434
then if a new request
for that resource

179
00:07:20,434 --> 00:07:22,267
comes within an hour,

180
00:07:22,267 --> 00:07:24,934
then the cached response
will be returned.

181
00:07:24,934 --> 00:07:27,400
These caches finish out
the major characteristics

182
00:07:27,400 --> 00:07:29,133
of our REST protocol.

183
00:07:29,133 --> 00:07:32,000
Now, we said this architecture
had benefits.

184
00:07:32,000 --> 00:07:33,334
What are some of those?

185
00:07:33,334 --> 00:07:35,701
Let's first look at some
of the performance benefits,

186
00:07:35,701 --> 00:07:37,834
which include efficiency,
scalability,

187
00:07:37,834 --> 00:07:40,334
and user perceived
performance.

188
00:07:40,334 --> 00:07:41,667
For efficiency,

189
00:07:41,667 --> 00:07:44,067
all of those caches
help along the way.

190
00:07:44,067 --> 00:07:46,334
Your request may not have
to reach all the way back

191
00:07:46,334 --> 00:07:47,501
to the origin server

192
00:07:47,501 --> 00:07:50,634
or, in the case
of a local user agent cache,

193
00:07:50,634 --> 00:07:52,901
you may never even hit
the network at all.

194
00:07:52,901 --> 00:07:55,567
Control data allows
the signaling of compression,

195
00:07:55,567 --> 00:07:57,834
so a response can be GZIPPED
before being sent

196
00:07:57,834 --> 00:08:00,234
to the user agents
that can handle them.

197
00:08:00,234 --> 00:08:02,467
Scalability comes
from many areas.

198
00:08:02,467 --> 00:08:04,367
The use of gateways allows you
to distribute traffic

199
00:08:04,367 --> 00:08:06,434
among a large set
of origin servers

200
00:08:06,434 --> 00:08:09,100
based on method,
URI, content type,

201
00:08:09,100 --> 00:08:12,200
or any of the other headers
coming in from the request.

202
00:08:12,200 --> 00:08:13,934
Caching helps
scalability also

203
00:08:13,934 --> 00:08:15,801
as it reduces
the actual number of requests

204
00:08:15,801 --> 00:08:18,534
that make it all the way
back to the origin server.

205
00:08:18,534 --> 00:08:20,467
And statelessness allows
a request to be routed

206
00:08:20,467 --> 00:08:22,267
through different
gateways and proxies,

207
00:08:22,267 --> 00:08:23,834
thus avoiding
introducing bottlenecks

208
00:08:23,834 --> 00:08:28,067
and allowing more intermediaries
to be added as needed.

209
00:08:28,067 --> 00:08:30,501
Finally, User Perceived
Performance is increased

210
00:08:30,501 --> 00:08:32,667
by having a reduced set
of known media types

211
00:08:32,667 --> 00:08:36,133
that allows browsers to handle
known types much faster.

212
00:08:36,133 --> 00:08:38,601
For example, partial rendering
of HTML documents

213
00:08:38,601 --> 00:08:40,300
as they download.

214
00:08:40,300 --> 00:08:42,667
Also, Code on Demand
allows computations

215
00:08:42,667 --> 00:08:44,167
to be moved closer
to the client

216
00:08:44,167 --> 00:08:45,434
or closer to the server,

217
00:08:45,434 --> 00:08:48,000
depending on where the work
can be done fastest.

218
00:08:48,000 --> 00:08:51,133
For example, having JavaScript
to do form validation

219
00:08:51,133 --> 00:08:54,234
before a request is even made
to the origin server

220
00:08:54,234 --> 00:08:55,801
is obviously faster

221
00:08:55,801 --> 00:08:58,133
than round-tripping
the form values to the server

222
00:08:58,133 --> 00:09:01,300
and having the server return
any validation errors.

223
00:09:01,300 --> 00:09:04,200
Similarly, caching helps here
as it requests may not need

224
00:09:04,200 --> 00:09:06,501
to go completely back
to the origin server.

225
00:09:06,501 --> 00:09:09,100
Also, since GET
is idempotent and safe,

226
00:09:09,100 --> 00:09:12,067
a user agent could pre-fetch
results before they're needed,

227
00:09:12,067 --> 00:09:15,234
thus increasing
user perceived performance.

228
00:09:15,234 --> 00:09:17,634
Lots of other benefits
we won't cover,

229
00:09:17,634 --> 00:09:20,367
but these are outlined
in Roy's thesis.

230
00:09:20,367 --> 00:09:22,367
But all these benefits
aren't free.

231
00:09:22,367 --> 00:09:24,300
You actually have to structure
your application

232
00:09:24,300 --> 00:09:26,601
or service
to take advantage of them.

233
00:09:26,601 --> 00:09:29,200
If you do, then you will get
the benefits.

234
00:09:29,200 --> 00:09:31,601
And if you don't,
you won't get them.

235
00:09:31,601 --> 00:09:34,567
To see how structuring helps,
let's look at two protocols:

236
00:09:34,567 --> 00:09:37,400
XML-RPC and
the Atom Publishing Protocol.

237
00:09:52,234 --> 00:09:56,968
So this is what
an XML-RPC request looks like,

238
00:09:56,968 --> 00:10:01,601
and here's
an example response.

239
00:10:01,601 --> 00:10:04,834
All of the requests
in XML-RPC are posts.

240
00:10:04,834 --> 00:10:08,033
So what do the intermediaries
see of this request response?

241
00:10:08,033 --> 00:10:09,667
Is it safe?
No.

242
00:10:09,667 --> 00:10:11,133
Is it idempotent?
No.

243
00:10:11,133 --> 00:10:12,868
Or is it cacheable?
No.

244
00:10:12,868 --> 00:10:16,367
If they are, the intermediaries
would never know that.

245
00:10:16,367 --> 00:10:18,634
All the requests go
to the same URI,

246
00:10:18,634 --> 00:10:20,968
which means that if you're going
to distribute many such calls

247
00:10:20,968 --> 00:10:22,901
among a group
of origin servers,

248
00:10:22,901 --> 00:10:24,434
you would have to look
inside the body

249
00:10:24,434 --> 00:10:25,934
for the method name.

250
00:10:25,934 --> 00:10:29,067
This gives the least amount
of information to the Web,

251
00:10:29,067 --> 00:10:31,334
and thus it doesn't get any help
from intermediaries

252
00:10:31,334 --> 00:10:33,801
and doesn't scale
with off the shelf parts.

253
00:10:33,801 --> 00:10:37,167
So let's take a look
at the Atom Publishing Protocol.

254
00:10:37,167 --> 00:10:39,934
So for authoring to begin
in the Atom Publishing Protocol,

255
00:10:39,934 --> 00:10:42,634
a client needs to discover
the capabilities and locations

256
00:10:42,634 --> 00:10:44,267
of the available collections.

257
00:10:44,267 --> 00:10:45,868
Service documents are designed

258
00:10:45,868 --> 00:10:48,667
to support
this discovery service.

259
00:10:48,667 --> 00:10:52,467
To retrieve a service document,
we send a GET to its URI.

260
00:10:52,467 --> 00:10:56,601
GET is safe, idempotent,
cacheable, and zipable.

261
00:10:56,601 --> 00:10:58,767
The response type
is self-identifying.

262
00:10:58,767 --> 00:11:00,868
As you can see,
there's a content type header

263
00:11:00,868 --> 00:11:03,801
of application
Atom Service plus XML

264
00:11:03,801 --> 00:11:07,334
that self-identifies what
the content is specifically,

265
00:11:07,334 --> 00:11:10,334
and the response itself
is hypertexted.

266
00:11:10,334 --> 00:11:12,734
It contains URIs
for each of the collections.

267
00:11:12,734 --> 00:11:14,968
That's what's highlighted,
in this slide here,

268
00:11:14,968 --> 00:11:17,767
is the relative URI
for the collection.

269
00:11:17,767 --> 00:11:19,267
Once we have
a collection URI,

270
00:11:19,267 --> 00:11:22,067
we can post an entry
to create a new member,

271
00:11:22,067 --> 00:11:25,501
and then GET, PUT, or DELETE
the members at their own URIs.

272
00:11:25,501 --> 00:11:29,934
So here's an example of a GET
to a collection document.

273
00:11:29,934 --> 00:11:35,467
Again, this is safe, idempotent,
cacheable, and zipable.

274
00:11:35,467 --> 00:11:38,868
The response is also
self-identifying here

275
00:11:38,868 --> 00:11:40,734
as you have
another content type,

276
00:11:40,734 --> 00:11:42,901
application/atom+xml.

277
00:11:42,901 --> 00:11:46,934
And again, the response
is hypertext.

278
00:11:46,934 --> 00:11:49,334
Lastly,
the edit URI identifies

279
00:11:49,334 --> 00:11:51,434
where the entry
can actually be modified.

280
00:11:51,434 --> 00:11:54,501
That URI, you can do a GET to,
to retrieve it,

281
00:11:54,501 --> 00:11:57,067
you can send a PUT
to update the resource,

282
00:11:57,067 --> 00:11:58,667
or you can send a DELETE
to remove it

283
00:11:58,667 --> 00:11:59,934
from the collection.

284
00:11:59,934 --> 00:12:02,167
So as you can see,
the Atom Publishing Protocol

285
00:12:02,167 --> 00:12:05,901
is designed with RESTful
characteristics in mind

286
00:12:05,901 --> 00:12:07,467
and gets many advantages

287
00:12:07,467 --> 00:12:10,067
from intermediaries
and the network itself

288
00:12:10,067 --> 00:12:12,968
as those messages
transfer back and forth.

289
00:12:12,968 --> 00:12:15,033
So, let's look at some
of the other idioms

290
00:12:15,033 --> 00:12:18,000
that you can use in building
your RESTful protocol

291
00:12:18,000 --> 00:12:19,701
to get some
of the advantages.

292
00:12:19,701 --> 00:12:22,734
For example,
long-lived images.

293
00:12:22,734 --> 00:12:24,601
If you have large images

294
00:12:24,601 --> 00:12:26,000
that need to be transferred
back and forth

295
00:12:26,000 --> 00:12:29,734
as part of your Web page,
what you should do is

296
00:12:29,734 --> 00:12:32,334
set the cache for those images
to be very long.

297
00:12:32,334 --> 00:12:33,868
If you need to update
those images,

298
00:12:33,868 --> 00:12:35,868
upload a new image
to a new URI

299
00:12:35,868 --> 00:12:39,767
and change the HTML to point
to that new URI.

300
00:12:39,767 --> 00:12:43,868
Here's an example
where I have big-image.png.

301
00:12:43,868 --> 00:12:45,634
And,
if we retrieve that image,

302
00:12:45,634 --> 00:12:47,133
you'll see that
the cache control header

303
00:12:47,133 --> 00:12:49,133
has been set
to a very long time.

304
00:12:49,133 --> 00:12:51,434
In this case, 30 days.

305
00:12:51,434 --> 00:12:54,400
If we made a mistake, or we'd
like to update that image,

306
00:12:54,400 --> 00:12:58,634
what I need to do is upload
a new image, big-image-2,

307
00:12:58,634 --> 00:13:01,300
set the cache control
for that to be very long,

308
00:13:01,300 --> 00:13:03,400
and then update the HTML.

309
00:13:03,400 --> 00:13:06,133
The idea here is
that you keep the HTML

310
00:13:06,133 --> 00:13:07,834
with the short
cache lifetime,

311
00:13:07,834 --> 00:13:11,200
and thus you
can update that easily.

312
00:13:11,200 --> 00:13:12,567
So there you go,

313
00:13:12,567 --> 00:13:16,200
a high level view of REST
and how it relates to HTTP.

314
00:13:16,200 --> 00:13:17,467
Here's the list
of further reading

315
00:13:17,467 --> 00:13:19,000
that I had promised you.

316
00:13:19,000 --> 00:13:23,467
"RFC 2616" actually outlines
what HTTP is.

317
00:13:23,467 --> 00:13:27,968
"RFC 3986" outlines
the URI standard.

318
00:13:27,968 --> 00:13:29,734
You can read
Roy Fielding's thesis,

319
00:13:29,734 --> 00:13:31,367
"Architectural Styles
and the Design

320
00:13:31,367 --> 00:13:33,767
of Network-based
Software Architectures."

321
00:13:33,767 --> 00:13:35,701
And there's also
this "Caching Tutorial"

322
00:13:35,701 --> 00:13:38,133
by Mark Nottingham
which covers in detail

323
00:13:38,133 --> 00:13:39,834
many of the things
we just talked about.

324
00:13:39,834 --> 00:13:41,767
Thanks and have fun.