My favorites | Sign in
Project Home Wiki Source
Checkout   Browse   Changes    
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
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.

Change log

r22 by naomi.bilodeau on Jan 30, 2009   Diff
[No log message]
Go to: 
Project members, sign in to write a code review

Older revisions

r19 by naomi.bilodeau on Jan 25, 2009   Diff
[No log message]
r17 by naomi.bilodeau on Jan 24, 2009   Diff
[No log message]
r6 by naomi.bilodeau on Jan 23, 2009   Diff
[No log message]
All revisions of this file

File info

Size: 24203 bytes, 1568 lines

File properties

url
http://www.youtube.com/watch?v=YCcAE2SCQ6k
svn:mime-type
text/plain
title
Intro to REST
Powered by Google Project Hosting