SlideShare a Scribd company logo

REST in Practice

•
Guilherme Silveira, profile picture
Guilherme Silveira

This document provides an overview of a tutorial on REST and web services. The tutorial will cover web basics, URI templates, HTTP, CRUD, semantics, hypermedia formats, and Atom/AtomPub. It is intended to explain how to design distributed systems using the web as a platform and leverage REST architectural principles. The tutorial will use Richardson's maturity model to discuss different service styles on a spectrum from non-RESTful to fully RESTful.

1 of 302
Downloaded 2,913 times
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
REST  in  Practice   A  Tutorial  on  Web-­‐based  Services   Jim  Webber   h*p://jim.webber.name   Savas  Parasta8dis   h*p://savas.me   Ian  Robinson   h*p://iansrobinson.com  
Motivation   •  This  follows  the  plot  from  a  book  called  REST  in  Practice   which  is  currently  being  written  by:   –  Jim  Webber   –  Savas  Parastatidis   –  Ian  Robinson   •  With  help  from  lots  of  other  lovely  people  like:   –  Halvard  Skogsrud,  Lasse  Westh-­‐Nielsen,  Steve  Vinoski,   Mark  Nottingham,  Colin  Jack,  Spiros  Tzavellas,  Glen   Ford,  Sriram  Narayan,  Ken  Kolchier,  Guilherme  Silveira   and  many  more!     •  The  book  deals  with  the  Web  as  a  distributed  computing   platform   –  The  Web  as  a  whole,  not  just  REST   •  And  so  does  this  tutorial…  
Timetable   •  09:00-­‐10:30   •  12:00-­‐13:00   –  Web  basics   –  Lunch   –  URI  templates   –  RPC   •  13:00-­‐14:30   –  HTTP   –  Hypermedia  design   –  CRUD   –  Scalability   •  10:30-­‐10:45     –  Security   –  Coffee  break   •  14:30-­‐14:45   •  10:45-­‐12:00   –  Coffee  break   –  Semantics   •  14:45-­‐16:00   –  Hypermedia  formats   –  Atom   –  Restbucks  DAP   –  AtomPub   –  Restbucks  retrospective   –  Epilogue  
Introduction   •  This  is  a  tutorial  about  the  Web   •  It’s  very  HTTP  centric   •  But  it’s  not  about  Web  pages!   •  The  Web  is  a  middleware  platform  which  is…   –  Globally  deployed   –  Has  reach   –  Is  mature   –  And  is  a  reality  in  every  part  of  our  lives   •  Which  makes  it  interesting  for  distributed  systems  geeks  
Leonard  Richardson's  Web  service  maturity  heuristic   What?   Why?   How?   Spreads  complexity   URIs   Divide  and  conquer   around   Refactor   (Do  the  same  things   Reduces  complexity   Uniform  interface   in  the  same  way)   Describe  special   Makes  complexity   Hypermedia   behaviour  in  a   learnable   standard  way   http://www.crummy.com/writing/  
Why  Web?  Why  not  just  REST?   •  REST  is  a  brilliant   architectural  style   •  But  the  Web  allows  for   more  than  just  RESTful   systems   •  There’s  a  spectrum  of   maturity  of  service  styles   –  From  completely  bonkers  to   completely  RESTful   •  We’ll  use  the  Richardson   maturity  model  to  frame   these  kinds  of  discussions   –  Level  0  to  Level  3   –  Web-­‐ignorant  to  RESTful!  
HTTP   URIs   REST  is  an  Architectural  style  suited  to  the  Web…   …but  it  is  not  mandatory  
Why  the  Web?  Why  be  RESTful?   •  Scalable   •  Fault-­‐tolerant   •  Recoverable   •  Secure   •  Loosely  coupled   •  Precisely  the  same  characteristics  we  want  in  business   software  systems!  
REST  isn’t…   •  Just  pretty  URIs   •  Just  XML  or  JSON   •  URI  templates   •  AJAX  applications   But  you  could  be  forgiven  for  thinking  it  is!  
Web  Architecture  
Web  History   •  Started  as  a  distributed  hypermedia  platform   –  CERN,  Berners-­‐Lee,  1990   •  Revolutionised  hypermedia   –  Imagine  emailing  someone  a  hypermedia  deck   nowadays!   •  Architecture  of  the  Web  largely  fortuitous   –  W3C  and  others  have  since  retrofitted/captured  the   Web’s  architectural  characteristics  
The  Web  broke  the  rules  
Web  Fundamentals   •  To  embrace  the  Web,  we  need  to  understand  how  it  works   •  The  Web  is  a  distributed  hypermedia  model   –  It  doesn’t  try  to  hide  that  distribution  from  you!   •  Our  challenge:     –  Figure  out  the  mapping  between  our  problem  domain   and  the  underlying  Web  platform  
Key  Actors  in  the  Web  Architecture   Client   Cache   Firewall   Firewall   Resources   Router   Web  Server   Web  Server   ISP   Reverse   Proxy   Proxy  Server   Firewall   Resources  
Resources   •  A  resource  is  something  “interesting”  in  your  system   •  Can  be  anything   –  Spreadsheet  (or  one  of  its  cells)   –  Blog  posting   –  Printer   –  Winning  lottery  numbers   –  A  transaction   –  Others?  
Interacting  with  Resources   •  We  deal  with  representations  of  resources   –  Not  the  resources  themselves   •  “Pass-­‐by-­‐value”  semantics   –  Representation  can  be  in  any  format   •  Any  media  type   •  Each  resource  implements  a  standard  uniform  interface   –  Typically  the  HTTP  interface   •  Resources  have  names  and  addresses  (URIs)   –  Typically  HTTP  URIs  (aka  URLs)  
Resource  Architecture   Consumer   (Web  Client)   Uniform  Interface   (Web  Server)   Logical  Resources   Resource  Representa8on   (e.g.  XML  document)   Physical  Resources  
Resource  Representations   •  Making  your  system  Web-­‐friendly  increases  its  surface  area   –  You  expose  many  resources,  rather  than  fewer   endpoints   •  Each  resource  has  one  or  more  representations   –  Representations  like  JSON  or  XML  or  good  for  the   programmatic  Web   •  Moving  representations  across  the  network  is  the  way  we   transact  work  in  a  Web-­‐native  system  
URIs   •  URIs  are  addresses  of  resources  in  Web-­‐based  systems   –  Each  resource  has  at  least  one  URI   •  They  identify  “interesting”  things   –  i.e.  Resources     •  Any  resource  implements  the  same  (uniform)  interface   –  Which  means  we  can  access  it  programmatically!   •  Declarative  scheme  
URI/Resource  Relationship   •  Any  two  resources  cannot  be  identical   –  Because  then  you’ve  only  got  one  resource!   •  But  they  can  have  more  than  one  name   –  http://foo.com/software/latest   –  http://foo.com/software/v1.4   •  No  mechanism  for  URI  equality   •  Canonical  URIs  are  long-­‐lived   –  E.g.  http://example.com/versions/1.1  versus   http://example.com/versions/latest   –  Send  back  HTTP  303  (“see  also”)  if  the  request  is  for  an   alternate  URI   –  Or  set  the  Content-­‐Location  header  in  the  response  
Scalability   •  Web  is  truly  Internet-­‐scale   –  Loose  coupling   •  Growth  of  the  Web  in  one  place  is  not  impacted  by   changes  in  other  places   –  Uniform  interface   •  HTTP  defines  a  standard  interface  for  all  actors  on   the  Web   •  Replication  and  caching  is  baked  into  this  model   –  Caches  have  the  same  interface  as  real  resources!   –  Stateless  model   •  Supports  horizontal  scaling  
Fault  Tolerant   •  The  Web  is  stateless   –  All  information  required  to  process  a  request  must  be   present  in  that  request   •  Sessions  are  still  plausible,  but  must  be  handled  in  a   Web-­‐consistent  manner   –  Modelled  as  resources!   •  Statelessness  means  easy  replication   –  One  Web  server  is  replaceable  with  another   –  Easy  fail-­‐over,  horizontal  scaling  
Recoverable   •  The  Web  places  emphasis  on  repeatable  information   retrieval   –  GET  is  idempotent   •  Library  of  Congress  found  this  the  hard  way!   –  In  failure  cases,  can  safely  repeat  GET  on  resources   •  HTTP  verbs  plus  rich  error  handling  help  to  remove   guesswork  from  recovery   –  HTTP  statuses  tell  you  what  happened!   –  Some  verbs  (e.g.  PUT,  DELETE)  are  safe  to  repeat  
Secure   •  HTTPs  is  a  mature  technology   –  Based  on  SSL  for  secure  point-­‐to-­‐point  information   retrieval   •  Isn’t  sympathetic  to  Web  architecture   –  Restricted  caching  opportunities   •  Higher-­‐order  protocols  like  Atom  are  starting  to  change   this...   –  Encrypt  parts  of  a  resource  representation,  not  the   transport  channel   –  OK  to  cache!  
Loosely  Coupled   •  Adding  a  Web  site  to  the  WWW  does  not  affect  any  other   existing  sites   •  All  Web  actors  support  the  same,  uniform  interface   –  Easy  to  plumb  new  actors  into  the  big  wide  web   •  Caches,  proxies,  servers,  resources,  etc  
Tech  Interlude   URI  Templates  
Conflicting  URI  Philosophies   •  URIs  should  be  descriptive,  predictable?   –  http://spreadsheet/cells/a2,a9   –  http://jim.webber.name/2007/06.aspx   •  Convey  some  ideas  about  how  the  underlying   resources  are  arranged   –  Can  infer  http://spreadsheet/cells/b0,b10  and  http:// jim.webber.name/2005/05.aspx  for  example   •  Nice  for  programmatic  access,  but  may  introduce   coupling   •  URIs  should  be  opaque?   –  http://tinyurl.com/6   –  TimBL  says  “opaque  URIs  are  cool”   •  Convey  no  semantics,  can’t  infer  anything  from  them   –  Don’t  introduce  coupling  
URI  Templates,  in  brief   •  Use  URI  templates  to  make  your  resource  structure  easy  to   understand   •  For  Amazon  S3  (storage  service)  it’s  easy:   –  http://s3.amazon.com/{bucket-name}/{object- name} Bucket1   Bucket2   Object2   Object1   Object1   Object3   Object2  
URI  Templates  are  Easy!   •  Take  the  URI:     http://restbucks.com/orders?{order_id} •  You  could  do  the  substitution  and  get  a  URI:     http://restbucks.com/orders?1234 •  Can  easily  make  more  complex  URIs  too   –  Mixing  template  and  non-­‐template  sections   http://restbucks.com/{orders}/{shop}/{year}/{month}.xml •  Use  URI  templates  client-­‐side  to  compute  server-­‐side  URIs   –  But  beware  this  introduces  coupling!  
Why  URI  Templates?   •  Regular  URIs  are  a  good  idiom  in  Web-­‐based  services   –  Helps  with  understanding,  self  documentation   •  They  allow  users  to  infer  a  URI   –  If  the  pattern  is  regular   •  URI  templates  formalise  this  arrangement   –  And  advertise  a  template  rather  than  a  regular  URI  
URI  Templates  Pros  and  Cons   •  Everything  interesting  in  a  Web-­‐based  service  has  a  URI   •  Remember,  two  schools  of  thought:   –  Opaque  URIs  are  cool  (Berners-­‐Lee)   –  Transparent  URIs  are  cool  (everyone  else)   •  URI  templates  present  two  core  concerns:   –  They  invite  clients  to  invent  URIs  which  may  not  be   honoured  by  the  server   –  They  increase  coupling  since  servers  must  honour   forever  any  URI  templates  they’ve  advertised   •  Use  URI  templates  sparingly,  and  with  caution   –  Entry  point  URIs  only  is  a  good  rule  of  thumb  
RPC  Again!  
Web  Tunnelling   •  Web  Services  tunnel  SOAP  over  HTTP   –  Using  the  Web  as  a  transport  only   –  Ignoring  many  of  the  features  for  robustness  the  Web   has  built  in   •  Many  Web  people  do  the  same!   –  URI  tunnelling,  POX  approaches  are  the  most  popular   styles  on  today’s  Web   –  Worse  than  SOAP!   But  they  claim  to   be  “lightweight”   •  Less  metadata!   and  RESTful  
Richardson  Model  Level  1   •  Lots  of  URIs   –  But  really  has  a  more   level  0  mindset   •  Doesn’t  understand   HTTP   –  Other  than  as  a   transport   •  No  hypermedia  
URI  Tunnelling  Pattern   •  Web  servers  understand  URIs   •  URIs  have  structure   •  Methods  have  signatures   •  Can  match  URI  structure  to  method  signature  
On  The  Wire  
Server-­‐Side  URI  Tunnelling  Example   public void ProcessGet(HttpListenerContext context) { // Parse the URI Order order = ParseUriForOrderDetails(context.Request.QueryString); string response = string.Empty; if (order != null) { // Process the order by calling the mapped method var orderConfirmation = RestbucksService.PlaceOrder(order); response = "OrderId=" + orderConfirmation.OrderId.ToString(); } else { response = "Failure: Could not place order."; } // Write to the response stream using (var sw = new StreamWriter(context.Response.OutputStream)) { sw.Write(response); } }
Client-­‐Side  URI  Tunnelling   public OrderConfirmation PlaceOrder(Order order) { // Create the URI var sb = new StringBuilder("http://restbucks.com/PlaceOrder?"); sb.AppendFormat("coffee={0}", order.Coffee.ToString()); sb.AppendFormat("&size={0}", order.Size.ToString()); sb.AppendFormat("&milk={0}", order.Milk.ToString()); sb.AppendFormat("&consume-location={0}", order.ConsumeLocation.ToString()); // Set up the GET request var request = HttpRequest.Create(sb.ToString()) as HttpWebRequest; request.Method = "GET"; // Get the response var response = request.GetResponse(); // Read the contents of the response OrderConfirmation orderConfirmation = null; using (var sr = new StreamReader(response.GetResponseStream())) { var str = sr.ReadToEnd(); // Create an OrderConfirmation object from the response orderConfirmation = new OrderConfirmation(str); } return orderConfirmation; }
URI  Tunnelling  Strengths   •  Very  easy  to  understand   •  Great  for  simple  procedure-­‐calls   •  Simple  to  code   –  Do  it  with  the  servlet  API,  HttpListener,  IHttpHandler,   Rails,  whatever!   •  Interoperable   –  It’s  just  URIs!  
URI  Tunnelling  Weaknesses   •  It’s  brittle  RPC!   •  Tight  coupling,  no  metadata   –  No  typing  or  “return  values”  specified  in  the  URI   •  Not  robust  –  have  to  handle  failure  cases  manually   •  No  metadata  support   –  Construct  the  URIs  yourself,  map  them  to  the  function   manually   •  You  typically  use  GET  (prefer  POST)   –  OK  for  functions,  but  against  the  Web  for  procedures   with  side-­‐affects  
POX  Pattern   •  Web  servers  understand  how  to  process  requests  with   bodies   –  Because  they  understand  forms   •  And  how  to  respond  with  a  body   –  Because  that’s  how  the  Web  works   •  POX  uses  XML  in  the  HTTP  request  and  response  to  move  a   call  stack  between  client  and  server  
Richardson  Model  Level  0   •  Single  well-­‐known   endpoint   –  Not  really  URI  friendly   •  Doesn’t  understand   HTTP   –  Other  than  as  a   transport   •  No  hypermedia  
POX  Architecture  
POX  on  the  Wire  
.Net  POX  Service  Example   From  the  Web  server   private void ProcessRequest(HttpListenerContext context) { string verb = context.Request.HttpMethod.ToLower().Trim(); switch (verb) { case "post": Check  HTTP  Verb  (we   { want  POST)   // Everything's done with post in this case XmlDocument request = new XmlDocument(); request.Load(XmlReader.Create (context.Request.InputStream)); Dispatch  it  for  processing   Turn  the  HTTP  body  into  an   XmlElement result = MyApp.Processdocument  for   XML   (request.DocumentElement); processing   byte[] returnValue = Utils.ConvertUnicodeString (Constants.Xml.XML_DECLARATION + result.OuterXml); Get  XML  result,  and  get  bytes   context.Response.OutputStream.Write(returnValue, 0, returnValue.Length); break; } ... Return  XML  bytes  to  client  
Java  POX  Servlet   public class RestbucksService extends HttpServlet { @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Initialization code omitted for brevity try { requestReader = request.getReader(); responseWriter = response.getWriter(); String xmlRequest = extractPayload(requestReader); Order order = createOrder(xmlRequest); OrderConfirmation confirmation = restbucksService.placeOrder(order); embedPayload(requestWriter, confirmation.toString()); } finally { // Cleanup code omitted for brevity } }
C#  POX  Client  Example   public OrderConfirmation PlaceOrder(string customerId, Item[] items) { // Serialize our objects XmlDocument requestXml = CreateXmlRequest(customerId, items); var client = new WebClient(); var ms = new MemoryStream(); requestXml.Save(ms); client.Headers.Add("Content-Type", "application/xml"); ms = new MemoryStream(client.UploadData("http://restbucks.com/ PlaceOrder", null, ms.ToArray())); var responseXml = new XmlDocument(); responseXml.Load(ms); return CreateOrderConfirmation(responseXml); }
Java  Apache  Commons  Client   public class OrderingClient { private String sendRequestPost(String request, String uri) private static final String XML_HEADING = "<?xml throws version="1.0"?>n"; IOException, HttpException { private static final String NO_RESPONSE = "Error: No response."; PostMethod method = new PostMethod (uri); public String placeOrder(String customerId, method.setRequestHeader("Content- String[] itemIds) type", "application/xml"); throws Exception { method.setRequestBody(XML_HEADING + request); // XML string creation omitted for brevity // ... String responseBody = NO_RESPONSE; try { String response = sendRequestPost(request, new HttpClient().executeMethod "http://restbucks.com/PlaceOrder"); (method); responseBody = new String Document xmlResponse = (method.getResponseBody(), "UTF-8"); DocumentBuilderFactory.newInstance() .newDocumentBuilder } finally { ().parse( method.releaseConnection(); new InputSource(new } StringReader(response))); return responseBody; // XML response handling omitted for brevity } } }
POX  Strengths   •  Simplicity  –  just  use  HTTP  POST  and  XML   •  Re-­‐use  existing  infrastructure  and  libraries   •  Interoperable   –  It’s  just  XML  and  HTTP   •  Can  use  complex  data  structures   –  By  encoding  them  in  XML  
POX  Weaknesses   •  Client  and  server  must  collude  on  XML  payload   –  Tightly  coupled  approach   •  No  metadata  support   –  Unless  you’re  using  a  POX  toolkit  that  supports  WSDL   with  HTTP  binding  (like  WCF)   •  Does  not  use  Web  for  robustness   •  Does  not  use  SOAP  +  WS-­‐*  for  robustness  either  
Web  Abuse   •  Both  POX  and  URI  Tunnelling  fail  to  take  advantage  of  the   Web   –  Ignoring  status  codes   –  Reduced  scope  for  caching   –  No  metadata   –  Manual  crash  recovery/compensation  leading  to  high   development  cost   –  Etc   •  They’re  useful  in  some  situations   –  And  you  can  implement  them  with  minimal  toolkit   support   –  But  they’re  not  especially  robust  patterns  
REST in Practice
Tech  Interlude   HTTP  Fundamentals  
The  HTTP  Verbs   Decreasing  likelihood  of  being  understood  by  a   •  Retrieve  a  representation  of  a  resource:  GET   •  Create  a  new  resource:  PUT  to  a  new  URI,  or  POST   to  an  existing  URI   Web  server  today   •  Modify  an  existing  resource:  PUT  to  an  existing  URI   •  Delete  an  existing  resource:  DELETE   •  Get  metadata  about  an  existing  resource:  HEAD   •  See  which  of  the  verbs  the  resource  understands:   OPTIONS  
HEAD  Semantics   •  HEAD  is  like  GET,  except  it  only  retrieves  metadata   •  Request   HEAD /order/1234 HTTP 1.1 Host: restbucks.com •  Response   200 OK Content-Type: application/vnd.restbucks +xml Last-Modified: 2007-07-08T15:00:34Z Etag: aabd653b-65d0-74da-bc63-4bca- ba3ef3f50432   Useful  for  caching,   performance  
OPTIONS  Semantics   •  Asks  which  methods  are  supported  by  a  resource   –  Easy  to  spot  read-­‐only  resources  for  example   •  Request   OPTIONS /orders/1234 HTTP 1.1 Host: restbucks.com •  Response   You  can  only  read  and  add  to   this  resource,    may  change   200 OK over  8me   Allow: GET,HEAD,POST
HTTP  Status  Codes   •  The  HTTP  status  codes  provide  metadata  about  the  state  of   resources   •  They  are  part  of  what  makes  the  Web  a  rich  platform  for   building  distributed  systems   •  They  cover  five  broad  categories   –  1xx  -­‐  Metadata   –  2xx  –  Everything’s  fine   –  3xx  –  Redirection   –  4xx  –  Client  did  something  wrong   –  5xx  –  Server  did  a  bad  thing   •  There  are  a  handful  of  these  codes  that  we  need  to  know  in   more  detail  
1xx   •  100  –  Continue   –  The  operation  will  be  accepted  by  the  service   –  The  “look  before  you  leap”  pattern   •  Use  with  the  Expect  header   •  Request   POST /orders HTTP/1.1 Content-Type: application/xml Expect: 100-continue •  Response   100 Continue or   417 Expectation Failed
2xx   •  200  –  OK   –  The  server  successfully  completed  whatever  the  client   asked  of  it   •  201  –  Created   –  Sent  when  a  new  resource  is  created  at  the  client’s   request  via  POST   –  Location  header  should  contain  the  URI  to  the  newly   created  resource   •  202  –  Accepted   –  Client’s  request  can’t  be  handled  in  a  timely  manner   –  Location  header  should  contain  a  URI  to  the  resource   that  will  eventually  be  exposed  to  fulfil  the  client’s   expectations  
More  2xx  Codes   •  203  –  Non-­‐Authoritative  Information   –  Much  like  200,  except  the  client  knows  not  to  place  full  trust   in  any  headers  since  they  could  have  come  from  3rd  parties  or   be  cached  etc.   •  204  –  No  Content   –  The  server  declines  to  send  back  a  representation   •  Perhaps  because  the  associated  resource  doesn’t  have   one   –  Used  like  an  “ack”   •  Prominent  in  AJAX  applications   •  206  –  Partial  Content   –  Optimisation  used  in  failure  cases  to  support  partial  GETs   –  Request  Content-Range  header  must  specify  the  byte   range  of  the  resource  representation  it  wants   –  Response  headers  must  contain  Date;   •  ETag  and    Content-Location  headers  must  be   consistent  with  the  original  request  not  the  current  values  
3xx   •  301  –  Multiple  Choices   –  Response  Location  header  should  contain  the  preferred   URI   –  Message  body  can  contain  list  of  URIs     •  In  XHTML  possibly   –  In  general  avoid  being  ambiguous!   •  301  –  Moved  Permanently   –  Location  header  contains  the  new  location  of  the   resource   •  303  –  See  Other   –  Location  header  contains  the  location  of  an   alternative  resource   –  Used  for  redirection  
More  3xx   •  304  –  Not  Modified   –  The  resource  hasn’t  changed,  use  the  existing   representation   –  Used  in  conjunction  with  conditional  GET   –  Client  sends  the  If-Modified-Since  header   –  Response  Date  header  must  be  set   –  Response  Etag  and  Content-Location headers   must  be  same  as  original  representation   •  307  –  Temporary  Redirect   –  The  request  hasn’t  been  processed,  because  the   resource  has  moved   –  Client  must  resubmit  request  to  the  URI  in  the  response   Location  header  
4xx   •  400  –  Bad  Request   –  The  client  has  PUT  or  POST  a  resource  representation   that  is  in  the  right  format,  but  contains  invalid   information   •  401  –  Unauthorized   –  Proper  credentials  to  operate  on  a  resource  weren’t   provided   –  Response  WWW-Authenticate  header  contains  the   type  of  authentication  the  server  expects   •  Basic,  digest,  WSSE,  etc   –  Don’t  leak  information!   •  Consider  404  in  these  situations  
More  4xx   •  403  –  Forbidden   –  The  client  request  is  OK,  but  the  server  doesn’t  want  to   process  it   •  E.g.  Restricted  by  IP  address   –  Implies  that  resource  exists,  beware  leaking  information   •  404  –  Not  Found   –  The  standard  catch-­‐all  response   –  May  be  a  lie  to  prevent  401  or  403  information  leakage  
Even  more  4xx   •  405  –  Method  Not  Allowed   –  The  resource  doesn’t  support  a  given  method   –  The  response  Allow  header  lists  the  verbs  the  resource   understands   •  E.g.  Allow: GET, POST, PUT •  406  –  Not  Acceptable   –  The  client  places  too  many  restrictions  on  the  resource   representation  via  the  Accept-*  header  in  the  request   –  The  server  can’t  satisfy  any  of  those  representations  
Yet  More  4xx   •  409  –  Conflict   –  Tried  to  change  the  state  of  the  resource  to  something   the  server  won’t  allow   •  E.g.  Trying  to  DELETE  something  that  doesn’t  exist   •  410  –  Gone   –  The  resource  has  gone,  permanently.   –  Don’t  send  in  response  to  DELETE   •  The  client  won’t  know  if  it  was  deleted,  or  if  it  was   gone  and  the  delete  failed   •  411  –  Length  Required   –  If  a  request  (POST,  PUT)  contains  a  representation,  it   should  set  the  Content-Length  header   –  The  server  might  demand  this,  and  interrupt  the  client   request  
Still  more  4xx   •  412  –  Precondition  Failed   –  Server/resource  couldn’t  meet  one  or  more   preconditions   •  As  specified  in  the  request  header   –  E.g.  Using  If-Unmodified-Since  and  PUT  to   modify  a  resource  provided  it  hasn’t  been  changed  by   others   •  413  –  Request  Entity  Too  Large   –  Response  comes  with  the  Retry-After  header  in  the   hope  that  the  failure  is  transient  
Final  4xx  Codes   •  414  –  Request  URI  Too  Long   –  You’ve  got  a  hopeless  HTTP  server,  or  ridiculous  URI   names!   •  415  Unsupported  Media  Type   –  E.g.  If  the  server  resource  expects  JSON  but  the  client   sends  XML  
5xx  Codes   •  500  –  Internal  Server  Error   –  The  normal  response  when  we’re  lazy     •  501  –  Not  Implemented   –  The  client  tried  to  use  something  in  HTTP  which  this   server  doesn’t  support   •  Keep  HTTP  use  simple,  get  a  better  HTTP  server   •  502  –  Bad  Gateway   –  A  proxy  failed   –  Doesn’t  help  us  much    
More  5xx  Codes   •  503  –  Service  Unavailable   –  The  HTTP  server  is  up,  but  not  supporting  resource   communication  properly   –  Server  may  send  a  Retry-After  header,  assuming  the   fault  is  transient  
HTTP  Headers   •  Headers  provide  metadata  to  assist  processing   –  Identify  resource  representation  format  (media  type),   length  of  payload,  supported  verbs,  etc   •  HTTP  defines  a  wealth  of  these   –  And  like  status  codes  they  are  our  building  blocks  for   robust  service  implementations  
Must-­‐know  Headers   •  Authorization   –  Contains  credentials  (basic,  digest,  WSSE,  etc)   –  Extensible   •  Content-­‐Length   –  Length  of  payload,  in  bytes   •  Content-­‐Type   –  The  resource  representation  form   •  E.g.  application/vnd.restbucks+xml,  application/ xhtml+xml  
More  Must-­‐Know  Headers   •  Etag/If-­‐None-­‐Match   –  Opaque  identifier  –  think  “checksum”  for  resource   representations   –  Used  for  conditional  GET   •  If-­‐Modified-­‐Since/Last-­‐Modified   –  Used  for  conditional  GET  too   •  Host   –  Contains  the  domain-­‐name  part  of  the  URI  
Yet  More  Must-­‐Know  Headers   •  Location   –  Used  to  flag  the  location  of  a  created/moved  resource   –  In  combination  with:   •  201  Created,  301  Moved  Permanently,  302  Found,  307   Temporary  Redirect,  300  Multiple  Choices,  303  See   Other   •  User-­‐Agent   –  Tells  the  server  side  what  the  client-­‐side  capabilities  are   –  Should  not  be  used  in  the  programmable  Web!  
Final  Must-­‐Know  Headers   •  WWW-­‐Authenticate   –  Used  with  401  status   –  Informs  client  what  authentication  is  needed   •  Date   –  Mandatory!   –  Timestamps  on  request  and  response  
Useful  Headers   •  Accept   –  Client  tells  server  what  formats  it  wants   –  Can  externalise  this  in  URI  names  in  the  general  case   •  Accept-­‐Encoding   –  Client  tells  server  that  it  can  compress  data  to  save   bandwidth   –  Client  specifies  the  compression  algorithm  it   understands   •  Content-­‐Encoding   –  Server-­‐side  partner  of  Accept-­‐Encoding  
More  Useful  Headers   •  Allow   –  Server  tells  client  what  verbs  are  allowed  for  the   requested  resource  (used  in  combination  with   OPTIONS)   •  Cache-­‐Control   –  Metadata  for  caches,  tells  them  how  to  cache  (or  not)   the  resource  representation   –  And  for  how  long  etc.   •  Content-­‐MD5   –  Cryptographic  checksum  of  body   –  Useful  integrity  check,  has  computation  cost  
Yet  More  Useful  Headers   •  Expect   –  A  conditional  –  client  asks  if  it’s  OK  to  proceed  by   expecting  100-­‐Continue   –  Server  either  responds  with  100  or  417  –  Expectation   Failed     •  Expires   –  Server  tells  client  or  proxy  server  that  representation   can  be  safely  cached  until  a  certain  time   •  If-­‐Match   –  Used  for  ETag  comparison   –  Opposite  of  If-­‐None-­‐Match  
Final  Useful  Headers   •  If-­‐Unmodified-­‐Since   –  Useful  for  conditional  PUT/POST   •  Make  sure  the  resource  hasn’t  changed  while  you’re   been  manipulating  it   –  Compare  with  If-­‐Modified-­‐Since   •  Range   –  Specify  part  of  a  resource  representation  (a  byte  range)   that  you  need  –  aka  partial  GET   –  Useful  for  failure/recovery  scenarios  
Less  Often-­‐Used  Headers   •  Retry-­‐After   –  Resource  or  server  is  out  of  action  for  the  specified  time   –  Usually  associated  with  413  –  Request  Entity  Too  Large,   or  one  of  the  5xx  server  error  statuses   •  Content-­‐Location   –  Header  gives  the  canonical  URI  of  the  resource   –  Client  might  be  using  a  different  URI  to  access  that   resource  
HTTP  RCF  2616  is  Authoritative   •  The  statuses  and  headers  here  are  a  sample  of  the  full   range  of  headers  in  the  HTTP  spec   •  They  spec  contains  more  than  we  discuss  here   •  It  is  authoritative  about  usage   •  And  it’s  a  good  thing  to  keep  handy  when  you’re  working   on  a  Web-­‐based  distributed  system!  
Embracing  HTTP  as  an   Application  Protocol  
Using  the  Web   •  URI  tunnelling  and  POX  use  the  Web  as  a  transport   –  Just  like  SOAP  without  metadata  support   •  CRUD  services  begin  to  use  the  Web’s  coordination  support   •  But  the  Web  is  more  than  transport   HTTP   –  Transport,  plus   Headers   –  Metadata,  plus   Status  Codes   –  Fault  model,  plus   Uniform   Interface   –  Component  model,  plus   Caches,  proxies,   servers,  etc   –  Runtime  environment,  plus...  
CRUD  Resource  Lifecycle   •  The  resource  is  created  with  POST   •  It’s  read  with  GET   •  And  updated  via  PUT   •  Finally  it’s  removed  using  DELETE  
Richardson  Model  Level  2   •  Lots  of  URIs   •  Understands  HTTP!   •  No  hypermedia  
Create  with  POST   POST /orders <order … /> 201 Created Location: …/1234 Ordering   Ordering   Client   400 Bad Request Service   500 Internal Error
POST  Semantics   •  POST  creates  a  new  resource   •  But  the  server  decides  on  that  resource’s  URI   •  Common  human  Web  example:  posting  to  Web  log   –  Server  decides  URI  of  posting  and  any  comments  made   on  that  post   •  Programmatic  Web  example:  creating  a  new  employee   record   –  And  subsequently  adding  to  it  
POST  Request   POST /orders HTTP/1.1 Verb,  path,  and  HTTP   Host: restbucks.example.com version   Content-Type:application/vnd.restbucks+xml Restbucks-­‐specific  XML   Content-Length: 225 content   <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> Content   <items> (again  Restbucks  XML)   <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> </items> </order>
POST  Response   HTTP/1.1 201 Created Location: /orders/1234
When  POST  goes  wrong   •  We  may  be  4xx  or  5xx  errors   –  Client  versus  server  problem   •  We  turn  to  GET!   •  Find  out  the  resource  states  first   –  Then  figure  out  how  to  make  forward  or  backward   progress   •  Then  solve  the  problem   –  May  involve  POSTing  again   –  May  involve  a  PUT  to  rectify  server-­‐side  resources  in-­‐ place  
POST  Implementation  with  a  Servlet   protected void doPost(HttpServletRequest request, HttpServletResponse response) { try { Order order = extractOrderFromRequest(request); String internalOrderId = OrderDatabase.getDatabase().saveOrder(order); response.setHeader("Location", computeLocationHeader(request, internalOrderId)); response.setStatus(HttpServletResponse.SC_CREATED); } catch(Exception ex) { response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); } }
Read  with  GET   GET /orders/1234 200 OK <order … /> Ordering   Ordering   Client   404 Not Found Service   500 Internal Error
GET  Semantics   •  GET  retrieves  the  representation  of  a  resource   •  Should  be  idempotent   –  Shared  understanding  of  GET  semantics   –  Don’t  violate  that  understanding!   Library  of  congress   catalogue  incident!  
GET  Exemplified   GET /orders/1234 HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com
GET  Response   HTTP/1.1 200 OK Content-Length: 232 Content-Type: application/vnd.restbucks+xml Date: Wed, 19 Nov 2008 21:48:10 GMT <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> </items> <status>pending</pending> </order>
When  GET  Goes  wrong   •  Simple!   –  Just  404  –  the  resource  is  no  longer  available   HTTP/1.1 404 Not Found Content-Type: application/vnd.restbucks+xml Content-Length: 952 Date: Sat, 20 Dec 2008 19:01:33 GMT •  Are  you  sure?   –  GET  again!   •  GET  is  safe  and  idempotent   –  Great  for  crash  recovery  scenarios!  
Idempotent  Behaviour   •  An  action  with  no  side  affects   –  Comes  from  mathematics   •  In  practice  means  two  things:   –  A  safe  operation  is  one  which  changes  no  state  at  all   •  E.g.  HTTP  GET   –  An  idempotent  operation  is  one  which  updates  state  in   an  absolute  way   •  E.g.  x  =  4  rather  than  x  +=  2   •  Web-­‐friendly  systems  scale  because  of  safety   –  Caching!   •  And  are  fault  tolerant  because  of  idempotent  behaviour   –  Just  re-­‐try  in  failure  cases  
GET  JAX-­‐RS  Implementation   @Path("/") public class OrderingService { @GET @Produces("application/xml") @Path("/{orderId}") public String getOrder(@PathParam("orderId") String orderId) { try { Order order = OrderDatabase.getDatabase().getOrder(orderId); if (order != null) { return xstream.toXML(order); } else { throw new WebApplicationException(404); } } catch (Exception e) { throw new WebApplicationException(500); } } // Remainder of implementation omitted for brevity }
Update  with  PUT   PUT /orders/1234 <order … /> 200 OK 404 Not Found Ordering   Ordering   Client   Service   409 Conflict 500 Internal Error
PUT  Semantics   •  PUT  creates  a  new  resource  but  the  client  decides  on  the   URI   –  Providing  the  server  logic  allows  it   •  Also  used  to  update  existing  resources  by  overwriting  them   in-­‐place   •  PUT  is  idempotent   –  Makes  absolute  changes   •  But  is  not  safe   –  It  changes  state!  
PUT  Request   PUT /orders/1234 HTTP/1.1 Host: restbucks.com Content-Type: application/xml Content-Length: 386 <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <milk>whole</milk> <name>latte</name> <quantity>2</quantity> <size>small</size> </item> <item> <milk>whole</milk> Updated  content     <name>cappuccino</name> <quantity>1</quantity> <size>large</size> </item> </items> <status>preparing</preparing> </order>
PUT  Response   HTTP/1.1 200 OK Date: Sun, 30 Nov 2008 21:47:34 GMT Content-Length: 0 Minimalist  response  contains  no   en8ty  body  
When  PUT  goes  wrong   •  If  we  get  5xx  error,  or   HTTP/1.1 409 Conflict Date: Sun, 21 Dec 2008 16:43:07 GMT some  4xx  errors  simply   Content-Length:382 PUT  again!   <order xmlns="http://schemas.restbucks.com/ order"> <location>takeAway</location> –  PUT  is  idempotent   <items> <item> •  If  we  get  errors   <milk>whole</milk> <name>latte</name> indicating  incompatible   <quantity>2</quantity> <size>small</size> states  (409,  417)  then  do   </item> <item> some  forward/backward   <milk>whole</milk> <name>cappuccino</name> compensating  work   <quantity>1</quantity> <size>large</size> –  And  maybe  PUT  again   </item> </items> <status>served</status> </order>
WCF  Implementation  for  PUT   [ServiceContract] public interface IOrderingService { [OperationContract] [WebInvoke(Method = "PUT", UriTemplate = "/orders/ {orderId}")] void UpdateOrder(string orderId, Order order); // … }
WCF  Serializable  Types   [DataContract(Namespace = "http://schemas.restbucks.com/order", Name = "order")] public class Order { [DataMember(Name = "location")] public Location ConsumeLocation { get { return location; } set { location = value; } } [DataMember(Name = "items")] public List<Item> Items { get { return items; } set { items = value; } } [DataMember(Name = "status")] public Status OrderStatus { get { return status; } set { status = value; } } // … }
Remove  with  DELETE   DELETE /orders/1234 200 OK 404 Not Found Ordering   Ordering   Client   Service   405 Method Not Allowed 500 Service Unavailable
DELETE  Semantics   This  is  important  for   •  Stop  the  resource  from  being  accessible   decoupling   implementa8on  details   –  Logical  delete,  not  necessarily  physical   from  resources   •  Request   DELETE /orders/1234 HTTP/1.1 Host: restbucks.com •  Response   HTTP/1.1 200 OK Content-Length: 0 Date: Tue, 16 Dec 2008 17:40:11 GMT
When  DELETE  goes  wrong   •  Simple  case,  DELETE  again!   –  Delete  is  idempotent!   –  DELETE  once,  DELETE  10  times  has  the  same  effect:  one   deletion   HTTP/1.1 404 Not Found Content-Length: 0 Date: Tue, 16 Dec 2008 17:42:12 GMT
When  DELETE  goes  Really  Wrong   •  Some  4xx  responses   HTTP/1.1 409 Conflict Content-Length: 379 indicate  that  deletion   Date: Tue, 16 Dec 2008 17:53:09 GMT isn’t  possible   <order xmlns="http://schemas.restbucks.com/ order"> <location>takeAway</location> –  The  state  of  the  resource   <items> isn’t  compatible   <item> <name>latte</name> –  Try  forward/backward   <milk>whole</milk> <size>small</size> compensation  instead   <quantity>2</quantity> </item> <item> <name>cappuccino</name> <milk>skim</milk> <size>large</size> <quantity>1</quantity> </item> </items> Can’t  delete  an   <status>served</status> </order> order  that’s   already  served  
CRUD  does  not  mean  Worthless  
CRUD  is  Good?   •  CRUD  is  good   –  But  it’s  not  great   •  CRUD-­‐style  services  use  some  HTTP  features   •  But  the  application  model  is  limited   –  Suits  database-­‐style  applications   –  Hence  frameworks  like  Microsoft’s  Astoria   •  CRUD  has  limitations   –  CRUD  ignores  hypermedia   –  CRUD  encourages  tight  coupling  through  URI  templates   –  CRUD  encourages  server  and  client  to  collude   •  The  Web  supports  more  sophisticated  patterns  than  CRUD!  
Tech  Interlude   Semantics  
Microformats   •  Microformats  are  an  example  of  little  “s”  semantics   •  Innovation  at  the  edges  of  the  Web   –  Not  by  some  central  design  authority  (e.g.  W3C)   •  Started  by  embedding  machine-­‐processable  elements  in   Web  pages   –  E.g.  Calendar  information,  contact  information,  etc   –  Using  existing  HTML  features  like  class,  rel,  etc  
Semantic  versus  semantic   •  Semantic  Web  is  top-­‐down   –  Driven  by  the  W3C  with  extensive  array  of  technology,   standards,  committees,  etc   –  Has  not  currently  proven  as  scalable  as  the  visionaries   hoped   •  RDF  triples  have  been  harvested  and  processed  in   private  databases   •  Microformats  are  bottom-­‐up   –  Little  formal  organisation,  no  guarantee  of   interoperability   –  Popular  formats  tend  to  be  adopted  (e.g.  hCard)   –  Easy  to  use  and  extend  for  our  systems   –  Trivial  to  integrate  into  current  and  future   programmatic  Web  systems  
Microformats  and  Resources   •  Use  Microformats  to  structure  resources  where  formats   exist   –  I.e.  Use  hCard  for  contacts,  hCalendar  for  data   •  Create  your  own  formats  (sparingly)  in  other  places   –  Annotating  links  is  a  good  start   –  <link rel="withdraw.cash" .../> –  <link rel="service.post" type="application/atom+xml" href="{post-uri}" title="some title"> •  The  rel  attribute  describes  the  semantics  of  the  referred   resource  
Tech  Interlude   Hypermedia  Formats  
Media  Types  Rule!   •  The  Web’s  contracts  are  expressed  in  terms  of  media  types   and  link  relations   –  If  you  know  the  type,  you  can  process  the  content   •  Some  types  are  special  because  they  work  in  harmony  with   the  Web   –  We  call  these  “hypermedia  formats”  
(Hyper)  media  types   General   Standardised  media  type   Processing  model   Compose  application-­‐ specific  behaviours  on   Hypermedia  controls   (links  and  forms)   top  of  the  handling  of   standardised  media  types   Supported  operations   (methods,  headers  and   status  codes)   Representation  formats   (may  include  schemas)   Specific  
Other  Resource  Representations   •  Remember,  XML  is  not  the  only  way  a  resource  can  be   serialised   –  Remember  the  Web  is  based  on  REpresentational  State   Transfer   •  The  choice  of  representation  is  left  to  the  implementer   –  Can  be  a  standard  registered  media  type   –  Or  something  else   •  But  there  is  a  division  on  the  Web  between  two  families   –  Hypermedia  formats   •  Formats  which  host  URIs  and  links   –  Regular  formats   •  Which  don’t  
Plain  Old  XML  is  not  Hypermedia  Friendly   HTTP/1.1 200 OK Content-Length: 227 Content-Type: application/xml Date: Wed, 19 Nov 2008 21:48:10 GMT <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <name>latte</name> Where  are  the  links?   <quantity>1</quantity> Where’s  the  protocol?   <milk>whole</milk> <size>small</size> </item> </items> <status>pending</pending> </order>
So  what?   •  How  do  you  know  the  next  thing  to  do?   •  How  do  you  know  the  resources  you’re  meant  to  interact   with  next?   •  In  short,  how  do  you  know  the  service’s  protocol?   –  Turn  to  WADL?  Yuck!   –  Read  the  documentation?  Come  on!   –  URI  Templates?  Tight  Coupling!  
URI  Templates  are  NOT  a  Hypermedia  Substitute   •  Often  URI  templates  are  used  to  advertise  all  resources  a   service  hosts   –  Do  we  really  need  to  advertise  them  all?   •  This  is  verbose   •  This  is  out-­‐of-­‐band  communication   •  This  encourages  tight-­‐coupling  to  resources  through  their   URI  template   •  This  has  the  opportunity  to  cause  trouble!   –  Knowledge  of  “deep”  URIs  is  baked  into  consuming   programs   –  Services  encapsulation  is  weak  and  consumers  will   program  to  it   –  Service  will  change  its  implementation  and  break   consumers  
Bad  Ideas  with  URI  Templates   •  Imagine  we’re  created  an  order,  what  next?   •  We  could  share  this  URI  template:   –  http://restbucks.com/payment/{order_id} •  The  order_id  field  should  match  the  order  ID  that  came   from  the  restbucks  service   –  Sounds  great!   •  But  what  if  Restbucks  outsources  payment?   –  Change  the  URI  for  payments,  break  the  template,   break  consumers!   –  D’oh!   •  Be  careful  what  you  share!  
Better  Ideas  for  URI  Templates:  Entry  Points   •  Imagine  that  we  have  a  well-­‐known  entry  point  to  our   service   –  Which  corresponds  to  a  starting  point  for  a  protocol   •  Why  not  advertise  that  with  a  URI  template?   •  For  example:   –  http://restbucks.com/signIn/{store_id}/ {barista_id} •  Changes  infrequently   •  Is  important  to  Restbucks   •  Is  transparent,  and  easy  to  bind  to    
Better  Ideas  for  URI  Templates:  Documentation!   •  Services  tend  to  support   / Internal  URI   lots  of  resources   payment/ Templates   {order_id}   External  URI   •  We  need  a  shorthand  for   Templates   talking  about  a  large   number  of  resources  easily   •  We  can  use  a  URI  template   /{store}/ /order/ for  each  “type”  of   orders   {order_id}   resource  that  a  service  (or   services)  supports   •  But  we  don’t  share  this   information  with  others   /order/ –  Don’t  violate  encapsulation!   {order_id}  
application/xml  is  not  the  media  type  you’re  looking  for   •  Remember  that  HTTP  is  an  application  protocol   –  Headers  and  representations  are  intertwined   –  Headers  set  processing  context  for  representations   •  Remember  that  application/xml  has  a  particular   processing  model   –  Which  doesn’t  include  understanding  the  semantics  of   links   •  Remember  if  a  representation  is  declared  in  the  Content- Type  header,  you  must  treat  it  that  way   –  HTTP  is  an  application  protocol  –  did  you  forget  already?      •  We  need  real  hypermedia  formats!  
Hypermedia  Formats   •  Standard   –  Wide  “reach”   –  Software  agents  already  know  how  to  process  them   –  But  sometimes  need  to  be  shoe-­‐horned   •  Self-­‐created   –  Can  craft  specifically  for  domain   –  Semantically  rich   –  But  lack  reach  
Two  Common  Hypermedia  Formats:  XHTML  and  ATOM   •  Both  are  commonplace  today   •  Both  are  hypermedia  formats   –  They  contain  links   •  Both  have  a  processing  model  that  explicitly  supports  links   •  Which  means  both  can  describe  protocols…  
XHTML   •  XHTML  is  just  HTML  that  is  also  XML   Default  XML   •  For  example:   namespace   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:r="http://restbucks.org">XML   Other   namespaces   <head> <title> XHTML Example </title> </head> <body> <p> ...
What’s  the  big  deal  with  XHTML?   •  It  does  two  interesting  things:   1.  It  gives  us  document  structure   2.  It  gives  us  links   •  So?   1.  We  can  understand  the  format  of  those  resources   2.  We  can  discover  other  resources!   •  How?   1.  Follow  the  links!   2.  Encode  the  resource  representation  as  “normal”  XML   in  your  XHTML  documents   •  Contrast  this  with  the  Atom  and  APP  approach...similar!  
XHTML  in  Action   <html xmlns="http://www.w3.org/1999/xhtml"> <body> <div class="order"> <p class="location">takeAway</p> <ul class="items"> Business  data   <li class="item"> <p class="name">latte</p> <p class="quantity">1</p> <p class="milk">whole</p> “Hypermedia   <p class="size">small</p> Control”   </li> </ul> <a href="http://restbucks.com/payment/ 1234" rel="payment">payment</a> </div> </body> </html>
application/xhtml+xml •  Can  ask  which  verb  the  resource  at  the  end  of  the  link   supports   –  Via  HTTP  OPTIONS   •  No  easy  way  to  tell  what  each  link  actually  does   –  Does  it  buy  the  music?   –  Does  it  give  you  lyrics?   –  Does  it  vote  for  a  favourite  album?   •  We  lack  semantic  understanding  of  the  linkspace  and   resources   –  But  we  have  microformats  for  that  semantic  stuff!   •  Importantly  XHTML  is  a  hypermedia  format   –  It  contains  hypermedia  controls  that  can  be  used  to   describe  protocols!  
Atom  Syndication  Format   •  We’ll  study  this  in  more   HTTP/1.1 200 OK Content-Length: 342 depth  later,  but  for   Content-Type: application/atom+xml Date: Sun, 22 Mar 2009 17:04:10 GMT now…   <entry xmlns="http://www.w3.org/2005/ •  The  application/atom Atom"> +xml  media  type  is   <title>Order 1234</title> <link rel="payment" href="http:// hypermedia  aware   restbucks.com/payment/1234"/> <link rel="special-offer" href="http://restbucks.com/offers/ •  You  should  expect  links   freeCookie"/> when  processing  such   <id>http://restbucks.com/order/ 1234</id> representations   other  resources,   <updated>2009-03-22T16:57:02Z</ Links  to   updated> •  And  be  prepared  to  drotocol   </entry> a  nascent  p o   <summary>1x Cafe Latte</summary> things  with  them!  
application/atom+xml •  No  easy  way  to  tell  what  each  link  actually  does   –  But  look  at  the  way  the  rel  attribute  is  being  used   –  Can  we  inject  semantics  there?   •  Atom  is  a  hypermedia  format   –  Both  feeds  and  entries  contains  hypermedia  controls   that  can  describe  protocols  
application/vnd.restbucks+xml •  What  a  mouthful!   •  The  vnd  namespace  is  for  proprietary  media  types   –  As  opposed  to  the  IANA-­‐registered  ones   •  Restbucks  own  XML  is  a  hybrid   –  We  use  plain  old  XML  to  convey  information   –  And  Atom  link  elements  to  convey  protocol   •  This  is  important,  since  it  allows  us  to  create  RESTful,   hypermedia  aware  services  
Hypermedia  and  RESTful   Services  
Revisiting  Resource  Lifetime   •  On  the  Web,  the  lifecycle  of  a  single  resource  is  more  than:   –  Creation   –  Updating   –  Reading   –  Deleting   •  Can  also  get  metadata   –  About  the  resource   –  About  its  (subset  of)  the  verbs  it  understands   •  And  as  we  see,  resources  tell  us  about  other  resources  we   might  want  to  interact  with…  
Links   •  Connectedness  is  good  in  Web-­‐based  systems   •  Resource  representations  can  contain  other  URIs   •  Links  act  as  state  transitions   •  Application  (conversation)  state  is  captured  in  terms  of   these  states  
Describing  Contracts  with  Links   •  The  value  of  the  Web  is  its  “linked-­‐ness”   –  Links  on  a  Web  page  constitute  a  contractfor  page   traversals   •  The  same  is  true  of  the  programmatic  Web   •  Use  Links  to  describe  state  transitions  in  programmatic   Web  services   –  By  navigating  resources  you  change  application  state   •  Hypermedia  formats  support  this   –  Allow  us  to  describe  higher-­‐order  protocols  which  sit   comfortably  atop  HTTP   –  Hence  application/vnd.restbucks+xml
Links  are  State  Transitions  
Links  as  APIs   <confirm xmlns="..."> •  Following  a  link  causes   <link rel="payment" href="https://pay" an  action  to  occur   type="application/xml"/> •  This  is  the  start  of  a   <link rel="postpone" href="https://wishlist" state  machine!   type="application/xml"/> •  Links  lead  to  other   </confirm> resources  which  also   have  links   •  Can  make  this  stronger   with  semantics   –  Microformats  
We  have  a  framework!   •  The  Web  gives  us  a  processing  and  metadata  model   –  Verbs  and  status  codes   –  Headers   •  Gives  us  metadata  contracts  or  Web  “APIs”   –  URI  Templates   –  Links   •  Strengthened  with  semantics   –  Little  “s”  
REST in Practice
Richardson  Model  Level  3   •  Lots  of  URIs  that   address  resources   •  Embraces  HTTP  as  an   application  protocol   •  Resource   representations  and   formats  identify  other   resources   –  Hypermedia  at  last!  
Structural  versus  Protocol   •  “Structural”  REST   –  Domain  model  broken  up  with  URIs   –  Lazy  loading,  caching  over  the  network   –  Proliferation  of  media  types?   •  “Protocol”  REST   –  Focus  on  media  types  as  contracts   –  Protocol  state  transitions   –  DAPs  –  Domain  Application  Protocols  
Workflow  and  MOM   •  With  Web  Services  we   exchange  messages  with   the  service   •  Resource  state  is  hidden   from  view   •  Conversation  state  is  all   we  know   –  Advertise  it  with  SSDL,   BPEL   •  Uniform  interface,  roles   defined  by  SOAP   –  No  “operations”  
Hypermedia  Describes  Protocols!   •  Links  declare  next  valid  steps   •  Following  links  and  interacting  with  resources  changes   application  state   •  Media  types  with  links  define  contracts   –  Media  type  defines  processing  model   –  Links  (with  microformats)  describe  state  transitions   •  Don’t  need  a  static  contract  description   –  No  WSDL,  no  WADL   •  This  is  HATEOAS!   •  So  let’s  see  how  we  order  a  coffee  at  Restbucks.com…   –  Based  on:    http://www.infoq.com/articles/webber-­‐rest-­‐workflow  
Hypermedia  Protocols  Span  Services   Unfollowed  Link   Followed  Link  
Workflow   •  How  does  a  typical  enterprise  workflow  look  when  it’s   implemented  in  a  Web-­‐friendly  way?   •  Let’s  take  Restbucks  ordering  servas  an  example,  the   happy  path  is:   –  Make  selection   •  Add  any  specialities   –  Pay   –  Wait  for  a  while   –  Collect  drink  
Static  Interface  and  State  Transitions   3'42/&1'&2 9:;<2 !"#$%%&'()*+,-(.,/0%/&1'&2 5,&'6)'2&'(/+&,'72 82 +#16)'2/&1'&25/3@A2BC2()6)'2B(2 9:;<2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 6)2D#6A0'3)2'E#',)'1F72 =2 /&1'&2,63,'@@'125/3@A2BC2 GHIH<H2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 ()6)'2B(26)2D#6A0'3)2 >2 'E#',)'1F72 9J<2 !"#($%%&'()*+,-(.,/0%#6A0'3)%8=>?2 96A0'3)26,,'#)'12 ?2 M6&B()62#&'#6&'12/&1'&2 N2 /&1'&2&','BK'125/3@A2BC2()6)'2 GHIH<H2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 B(26)2D&'61AF72 L2 &')+&32@6)'()2&'#&'('3)6O/32 PH<2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 /C2)!'2&'(/+&,'2 4( !,%!",-&.( 1( ,%"+#( 2( */$!0%'%+( =2 5( 3( !"#$%&'( %)!%*'%+( 6( *"&*%00%+(
Place  an  Order   •  POST  to  a  well-­‐known  URI   –  http://restbucks.com/order   Restbucks  Service   Client  
Placing  an  Order   •  Request   POST /order HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 278 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> </rb:order>
Placing  an  Order   •  Response   HTTP/1.1 201 Created Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link uri="http://restbucks.com/order/f932f92d" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/ f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
Confirm  the  Order   •  GET  from  the  rel=“latest”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
Confirm  the  Order   •  Request   GET /order/f932f92d HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive
Confirm  the  Order   •  Response   HTTP/1.1 200 OK Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link uri="http://restbucks.com/order/f932f92d" mediaType="application/vnd.restbucks+xml" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
Change  the  Order   •  POST  new  order  to  service-­‐generated  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
POST?  Not  PUT?   •  PUT  expects  the  whole  resource  state  to  be  presented  in   the  request   –  But  our  clients  aren’t  responsible  for  generating   hypermedia  links   •  PATCH  would  be  better   –  It  allows  us  to  send  diffs,  but  isn’t  part  of  the  standard   yet   •  So  POST  is  our  only  option   –  Compare  this  to  our  CRUD  protocol  in  SOA  321  
Change  the  Order   •  Request   POST order/f932f92d HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 278 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> </rb:order>
Change  the  Order   •  Response   HTTP/1.1 200 OK Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:52:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
Statelessness   •  Remember  interactions  with  resources  are  stateless   •  The  resource  “forgets”  about  you  while  you’re  not  directly   interacting  with  it     •  Which  means  race  conditions  are  possible   •  Use  If-Unmodified-Since  on  a  timestamp  to  make   sure   –  Or  use  If-Match  and  an  ETag •  You’ll  get  a  412 PreconditionFailed  if  you  lost  the   race   –  But  you’ll  avoid  potentially  putting  the  resource  into   some  inconsistent  state  
Warning:  Don’t  be  Slow!   •  Can  only  make  changes  until  someone  actually  makes  your   drink   –  You’re  safe  if  you  use  If-Unmodified-Since  or  If- Match   –  But  resource  state  can  change  without  you!     Request    Response   POST /order/1234 HTTP 1.1 Host: restbucks.com 409 Conflict ... Too  slow!  Someone  else  has   changed  the  state  of  my  order    Request    Response   OPTIONS /order/1234 HTTP 1.1 Allow: GET Host: restbucks.com
What  if  we  want  to  cancel?   •  DELETE  order  at  order  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
What  if  we  want  to  cancel?   •  Request   DELETE /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Date: Sun, 06 Sep 2009 06:53:22 GMT
Order  Payment   •  PUT  to  service-­‐generated  payment  URI   –  http://restbucks.com/payment/f932f92d   Restbucks  Service   Client  
Why  PUT  this  time?   •  It’s  idempotent   –  Safe  to  repeat  in  the  event  of  failures   •  For  all  $  transactions,  prefer  idempotent  verbs  
Order  Payment   •  Request   PUT /payment/f932f92d HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 269 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <payment xmlns="http://schemas.restbucks.com"> <amount>2.0</amount> <cardholderName>Michael Farraday</cardholderName> <cardNumber>11223344</cardNumber> <expiryMonth>12</expiryMonth> <expiryYear>12</expiryYear> </payment>
Order  Payment   •  Response   HTTP/1.1 201 Created Location: http://restbucks.com/payment/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 547 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:payment xmlns="http://schemas.restbucks.com/dap" xmlns:rb="http:// schemas.restbucks.com"> <link rel="latest" uri="http://restbucks.com/order/f932f92d" /> <link rel="receipt" uri="http://restbucks.com/receipt/f932f92d" /> <rb:amount>2.0</rb:amount> <rb:cardholderName>Michael Farraday</rb:cardholderName> <rb:cardNumber>11223344</rb:cardNumber> <rb:expiryMonth>12</rb:expiryMonth> <rb:expiryYear>12</rb:expiryYear> </rb:payment>
What  if  we  want  to  cancel  now?   •  Request   DELETE /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive •  Response   HTTP/1.1 405 Method Not Allowed Allow: GET Content-Type: application/vnd.restbucks+xml Content-Length: 0 Date: Sun, 06 Sep 2009 07:43:29 GMT
Grab  a  Receipt   •  GET  service-­‐generated  receipt  URI   –  http://restbucks.com/receipt/f932f92d   Restbucks  Service   Client  
Grab  a  Receipt   •  Request   GET /receipt/f932f92d HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive
Grab  a  Receipt   •  Request   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 332 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:receipt xmlns="http://schemas.restbucks.com/dap" xmlns:rb="http://schemas.restbucks.com"> <link rel="order" uri="http://restbucks.com/order/f932f92d" /> <rb:amount>2.0</rb:amount> <rb:paid>2009-09-06T16:51:22.814+10:00</rb:paid> </rb:receipt>
Complete    the  Order   •  GET  from  the  rel=“order”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
Complete  the  Order   •  Request   GET /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive
Complete  the  Order   •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 455 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>ready</rb:status> </rb:order>
Complete  the  Order   •  DELETE  order  at  rel=“latest”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
Complete  the  Order   •  Request   DELETE/order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive
Complete  the  Order   •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 360 Date: Sun, 06 Sep 2009 23:01:10 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>taken</rb:status> </rb:order>
Source:  h*p://images.businessweek.com/ss/06/07/top_brands/image/starbucks.jpg  
What  did  we  learn  from  Restbucks?   •  HTTP  has  a  header/status  combination  for  every  occasion   •  APIs  are  expressed  in  terms  of  links,  and  links  are  great!   –  APP-­‐esque  APIs   •  APIs  can  also  be  constructed  with  URI  templates  and   inference   –  But  beware  tight  coupling  outside  of  CRUD  services!   •  XML  is  fine,  but  we  could  also  use  formats  like  Atom,  JSON   or  even  default  to  XHTML  as  a  sensible  middle  ground   •  State  machines  (defined  by  links)  are  important   –  Just  as  in  Web  Services…  
Tech  Interlude     Design  Exercise:  Adding  HTTP  Idioms  to  Restbucks
Ordering  and  Payments  Protocol  Weaknesses   •  Lacks  HTTP  idioms   –  ETags   –  Cache  metadata   –  Etc   •  No  circuit  breaker   –  E.g.  413  at  busy  times  
Ordering  and  Payments  Protocol  Retrospective   •  Scenario:   –  The  system  is  in  production,  and  has  delivered  revenue   successfully.  What  design  decisions  should  we  change   for  our  next  version?   •  Four  categories:   –  Introduce   •  New  things  we  should  do   –  Do  more  of   •  Good  things  we  should  do  more  of   –  Do  less  of   •  Poor  things  we  should  do  less  of   –  Remove   •  Stupid  things  we  should  cease  
Tech  Interlude   Hypermedia  Design  Walkthrough  
Problem   •  What’s  the  solution  for  integrating  ordering  and  barista-­‐ing   systems?   •  Guidelines:   –  Design  applications  in  terms  of  application  protocol   state  machines     –  Implement  them  in  terms  of  resource  lifecycles   –  Advertise/document  them  using  media  types,  link   relation  values  and  HTTP  idioms  
Fulfillment  domain  application  protocol   Awai8ng   fulfillment   barista  accepts   add  deliverable   Correc8ng   Fulfilling   order  modified   drinks  ==  line  items   remove  drink   Fulfilled  
Resource  lifecycles   1   *   Order   Drink   Created   1   1   Created   Drinks   Fulfilling   Corrected   Drinks  contains   Discarded   items  not  in   order   Started   Ready   Consumed   Requires   Preparing   amending   Completed  
Barista  reviews  outstanding  orders   GET /orders HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <orders xmlns="http://schemas.restbucks.com/orders"> <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>created</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order> ... </orders>
Barista  reviews  drinks  status  of  first  order   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "1" <drinks xmlns="http://schemas.restbucks.com/drinks"> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>started</status> </drinks>
Barista  creates  latte   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "1" <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/1 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink>
Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "2" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
Barista  creates  first  cappuccino   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "2" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/2 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink>
Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "3" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
Cashier  reviews  order  status   GET /orders/123 HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> <item> <name>cappuccino</name> <quantity>1</quantity> <milk>whole</milk> <size>large</size> </item> <status>fulfilling</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order>
Cashier  changes  order   POST /orders/123 HTTP/1.1 Host: restbucks.com Content-Type: application/vnd.restbucks+xml Content-Length: ... <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> HTTP/1.1 200 OK </order> Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>fulfilling</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order>
Barista  continues  making  drinks   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "3" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 412 Precondition Failed
Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "4" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <unwanted/> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>requires-amending</status> </drinks>
Barista  discards  latte   DELETE /orders/123/drinks/1 Host: internal.restbucks.com HTTP/1.1 204 No Content Date: ...
Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "5" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <unwanted/> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
Barista  creates  another  cappuccino   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "5" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/3 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/3"/> </drink>
Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "6" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/3"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>completed</status> </drinks>
Cashier  reviews  order  status   GET /orders/123 HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>ready</status> </order>
The  documented  protocol   !"#$%&'()"#& !""#$%%&'(")*+,(-+./%.&0'&(1 *+,)-&#%'+& 2##34+5"4.6%760-&'(")*+,(89/31 .+/(0$1+/& :&0'&(1 !""#$%%(+!'/5(-&'(")*+,(-+./%.&0'&(1 ;("5"*(<1'3'/'6"1 4604+5"'(1"!'1.&0'&1("5"*(-1 =53*'(15&'$1+&'5"'0>1 ?*3?43346@>1&'50A-1 :&0'&1 !""#$%%(+!'/5(-&'(")*+,(-+./%.&0'&1 1 B&46,(1 !""#$%%(+!'/5(-&'(")*+,(-+./%0&46,(1 ;("5"*(<1'3'/'6"1 4604+5"'(1"!'1#&.@&'((1.?1 "!'1#&'#5&'010&46,(-1 =53*'(15&'$1("5&"'0>1 &'C*4&'(D5/'6046@>1 #&'#5&46@>1+./#3'"'0-1 B&46,1 !""#$%%(+!'/5(-&'(")*+,(-+./%0&46,1 1 1 E*3?43/'6"14(1+./#3'"'1F!'61"!'1.&0'&1("5"*(14(1&'50A>15601"!'10&46,(1("5"*(14(1 +./#3'"'0-1 2)"3&$+4-#)("/& '04"1 G'?'&(1".151&'(.*&+'1"!5"1+561)'1 *('01".1'04"1"!'1346,H(1+.6"'9"-1I.1 '04"1561.&0'&>1J:KI1516'F1.&0'&1".1 "!'1'04"1346,-1I.1&'/.7'1510&46,1 ?&./15134("1.?10&46,(>1BLMLIL1"!'1 346,'01&'(.*&+'-1 !""#$%%&'35"4.6(-&'(")*+,(-+./%?*3?433/'6"1 B&46,(1"!5"1?*3?431561.&0'&-1I!'1 346,'01&'(.*&+'14(15++./#564'01)A1 561LI5@-1N&'5"46@16'F10&46,(1 (!.*301)'10.6'1)A1+.604"4.6533A1 J:KI46@1".1"!'1346,'01&'(.*&+'-1O?1 "!'134("1.?10&46,(1&'C*4&'(15/'6046@1 )'?.&'1516'F10&46,1+561)'1500'0>1 "!'1('&74+'1&'(#.60(1F4"!1PQR1 J&'+.604"4.61E543'0-1 !""#$%%&'35"4.6(-&'(")*+,(-+./%.&0'&1 I!'1.&0'&1".1F!4+!15134("1.?10&46,(1 )'3.6@(-1 1
Scalability  
REST in Practice
Web  Scale!  
Statelessness   •  Every  action  happens  in  isolation   –  This  is  a  good  thing!   •  In  between  requests  the  server  knows  nothing  about  you   –  Excepting  any  state  changes  you  caused  when  you  last   interacted  with  it.   •  Keeps  the  interaction  protocol  simpler   –  Makes  recovery,  scalability,  failover  much  simpler  too   –  Avoid  cookies!  
Application  vs  Resource  State   •  Useful  services  hold  persistent  data  –  Resource  state   –  Resources  are  buckets  of  state   –  What  use  is  Google  without  state?   •  Brittle  implementations  have  application  state   –  They  support  long-­‐lived  conversations   –  No  failure  isolation   –  Poor  crash  recovery   –  Hard  to  scale,  hard  to  do  fail-­‐over  fault  tolerance   •  Recall  stateless  Web  Services  –  same  applies  in  the  Web   too!  
Stateful  Example   What  if  there’s  a  failure   here?  
Stateful  Failure   “Grandmother”   An8pa*ern  
Stateless  System  Tolerates  Intermittent  Failures  
Scaling  Horizontally   •  Web  farms  have  delivered  horizontal  scaling  for  years   –  Though  they  sometimes  do  clever  things  with  session   affinity  to  support  cookie-­‐based  sessions   •  In  the  programmatic  Web,  statelessness  enables  scalability   –  Just  like  in  the  Web  Services  world  
Scalable  Deployment  Configuration   •  Deploy  services  onto  many  servers   •  Services  are  stateless   –  No  cookies!   •  Servers  share  only  back-­‐end  data  
Scaling  Vertically…without  servers   •  The  most  expensive  round-­‐trip:   –  From  client   –  Across  network   –  Through  servers   –  Across  network  again   –  To  database   –  And  all  the  way  back!   •  The  Web  tries  to  short-­‐circuit  this   –  By  determining  early  if  there  is  any  actual  work  to  do!   –  And  by  caching  
Caching   •  Caching  is  about  scaling  vertically   –  As  opposed  to  horizontally   •  Making  a  single  service  run  faster   –  Rather  than  getting  higher  overall  throughput   •  In  the  programmatic  Web  it’s  about  reducing  load  on   servers   –  And  reducing  latency  for  clients  
Caching  in  a  Scalable  Deployment   •  Cache  (reverse  proxy)  in  front  of  server  farm   –  Avoid  hitting  the  server   •  Proxy  at  client  domain   –  Avoid  leaving  the  LAN   •  Local  cache  with  client   –  Avoid  using  the  network  
Web-­‐Inspired  Architecture   Front  End   Caching   Back-­‐end   Database  
Characteristics   Incoming  informa8on   pushes  through   Scaling-­‐out  is   easy   Cache  replicates   naturally   Single  source  of   truth  
Improving  Performance  with  Caching  
Freshness   No  need  to   interact  with   front-­‐end  
Validation   Condi8onal  GET  
Scale  out!  
Scale  the  cache  out!   Cache  peering  
Collapsed  Forwarding  
Being  workshy  is  a  good  thing!   •  Provide  guard  clauses  in  requests  so  that  servers  can   determine  easily  if  there’s  any  work  to  be  done   –  Caches  too   •  Use  headers:   –  If-Modified-Since –  If-None-Match   –  And  friends   •  Web  infrastructure  uses  these  to  determine  if  its  worth   performing  the  request   –  And  often  it  isn’t   –  So  an  existing  representation  can  be  returned  
Conditional  GET  Avoids  Work!   ETag  is  an  opaque   iden8fier  for  specific   •  Bandwidth-­‐saving  pattern   resource  state   •  Requires  client  and  server  to  work  together   •  Server  sends  Last-Modified  and/or  ETag  headers  with   representations   •  Client  sends  back  those  values  when  it  interacts  with   resource  in  If-Modified-Since  and/or  If-None- Match  headers   •  Server  responds  with  a  200  an  empty  body  if  there  have   been  no  updates  to  that  resource  state   •  Or  gives  a  new  resource  representation  (with  new  Last- Modified  and/or  ETag  headers)  
Retrieving  a  Resource  Representation   •  Request   GET /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2009-01-08T15:00:34Z If-None-Match: aabd653b-65d0-74da-bc63-4bca-ba3ef3f50432 •  Response   200 OK Content-Type: application/vnd.restbucks+xml Content-Length: ... Last-Modified: 2009-01-08T15:10:32Z Etag: abbb4828-93ba-567b-6a33-33d374bcad39 <order … />
Not  Retrieving  a  Resource  Representation   •  Request   GET /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2009-01-08T15:00:34Z If-None-Match: aabd653b-65d0-74da- bc63-4bca-ba3ef3f50432 •  Response   Client’s  representa8on  of   the  resource  is  up-­‐to-­‐date   HTTP/1.1 304 Not Modified
Works  with  other  verbs  too   PUT /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2007-07-08T15:00:34Z If-None-Match: aabd653b-65d0-74da- bc63-4bca-ba3ef3f50432 <order …/>
PUT  Results  in  no  Work  Done   200 OK Content-Type: application/xml Content-Length: ... Last-Modified: 2007-07-08T15:00:34Z Etag: aabd653b-65d0-74da-bc63-4bca- ba3ef3f50432  
Security  
Good  Ole’  HTTP  Authentication   •  HTTP  Basic  and  Digest  Authentication:  IETF  RFC  2617   •  Have  been  around  since  1996  (Basic)/1997  (Digest)   •  Pros:   –  Respects  Web  architecture:     •  stateless  design  (retransmit  credentials)   •  headers  and  status  codes  are  well  understood   –  Does  not  prohibit  caching  (set  Cache-Control  to   public)   •  Cons:   –  Basic  Auth  must  be  used  with  SSL/TLS  (plaintext   password)   –  Not  ideal  for  the  human  Web  –  no  standard  logout   –  Only  one-­‐way  authentication  (client  to  server)   232  
HTTP  Basic  Auth  Example   1.  Initial  HTTP  request  to  protected  resource   GET /index.html HTTP/1.1 Host: example.org 2.  Server  responds  with     HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm=”MyRealm”   3.  Client  resubmits  request   GET /index.html HTTP/1.1 Host: example.org Authorization: Basic Qm9iCnBhc3N3b3JkCg== Further  requests  with  same  or  deeper  path  can  include  the   additional  Authorization  header  preemptively  
HTTP  Digest  Difference   •  Server  reply  to  first  client  request:   HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm=myrealm@example.org, qop="auth,auth-int", nonce="a97d8b710244df0e8b11d0f600bfb0cdd2", opaque="8477c69c403ebaf9f0171e9517f347f2" •  Client  response  to  authentication  challenge:   Authorization: Digest username="bob", realm=myrealm@example.org, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/index.html", qop=auth, nc=00000001, cnonce="0a6f188f", response=”56bc2ae49393a65897450978507ff442", opaque="8477c69c403ebaf9f0171e9517f347f2"
WSSE  Authentication   •  Driven  from  the  Atom  community   •  Use  the  WS-­‐Security  Username  Token  profile  mapped  to   HTTP  headers   •  Doesn’t  pass  sensitive  data  in  clear  text   •  Does  require  both  sides  to  know  a  shared  secret  
Man-­‐in-­‐the-­‐Middle   •  All  HTTP  Authentication  schemes  can  be  hijacked  by  a  man-­‐ in-­‐the-­‐middle  attack   •  Can  intercept  a  Digest  response  from  a  service  and  change   it  into  a  Basic  challenge   •  Basic  is  easy  to  crack,  attacker  learns  the  password   •  Transport  level  security  considered  mandatory  when   you’re  using  HTTP  authentication  of  any  variety  
SSL  /  TLS   •  “Strong”  server  and  optional  client  authentication,   confidentiality  and  integrity  protection   •  The  only  feasible  way  to  secure  against  man-­‐in-­‐the-­‐middle   attacks   •  Not  broken!  Even  if  some  people  like  to  claim  otherwise   •  Not  very  cache  friendly  though…  
Transport  Level  Security   •  TLS  is  the  successor  to  Netscape’s  original  SSL   •  Tightened  up  some  security  loopholes   •  Now  under  IETF’s  stewardship   –  RFC  2246   –  RFC  5246   •  Provides  a  secure  channel  between  client  and  server   –  Authenticated   –  Identified  (bilateral  too)   –  Confidential   –  Integrity  assured  
Start  with  a  TCP  Handshake   •  Classic  handshake  the  underpins  HTTP  connections   •  Not  secure  at  this  point,  obviously   *./) *'(+,-') !"#$%&'() *./)0)1!2) 1!2)
Negotiate  some  cryptographic  options   •  Client  sends  its  hashing/encryption  capabilities  and  preferences   to  the  server   •  Server  responds  with  its  choices  from  those  the  client  presented   –  Preferring  highest  levels  of  security   •  Server  sends  its  certificate   –  Public  key,  CA   •  Server  indicates  that  it’s  complete   !.,'#/0'..") *'(+'(0'..") *'(+,-') !"#$%&'() *'(+'(!'(12-3/') *'(+'(0'.."4"#')
Switch  on  the  crypto   •  Client  uses  server’s  public  key  to  send  a  PreMasterKey  to  the  server   –  If  the  server  is  authenticated,  it  can  decrypt  this  secret  with  its   private  key   •  Client  ChangeCipherSpec  flips  client  onto  the  secure  channel   •  ClientFinished  message  sends  a  hash  of  the  entire  conversation   –  To  alleviate  any  possibility  of  missing/tampered  messages   •  Server  ChangeCipherSpec  flips  server  onto  the  secure  channel   •  ServerFinished  sends  a  hash  of  the  entire  conversation  to  the  client   !.,'#/0'123-45#6') !45#6'!,74'(*7'-) !"#$%&'() *'(+,-') !.,'#/8,#,$4'9) !45#6'!,74'(*7'-) *'(+'(8,#,$4'9)
Network  and  performance  considerations   •  Just  use  HTTP  everywhere?   •  Reduces  options  for  caching   –  Reverse  proxies  and  client-­‐side  caching  only   •  Expensive  to  set  up  connections   –  Though  relatively  cheap  to  maintain,  if  you  have  enough   sockets   •  Securing  a  channel  on  the  risk/value  profile  of  a  resource   –  Secure  channels  only  for  high  value/risk  resources     •  Can  use  a  hybrid  approach…  
Publish  secret  data   •  Here  are  my  bank  account  details,  please  feel  free  to  use   them:   bb0ff34c3ab9c2a478cb7b8b61139a787bab5de1b4b 5ec463db070e1b72c502114758f1afd44c09b799207 3ccf00b43dc991579ddc5cbb91ea6984cbda08be9f •  Useless  to  you,  or  anyone  else,  unless  you  know  the   decryption  key  
Widely  publish  secret  data   ./"&)0''1) !"#$%&'() ./"&)2#/(3) ./"&)2#/(3) ./"&)2#/(3) *'(+,-') ./"&)2#/(3) !"#$%&'() ./"&)2#/(3) ./"&)2#/(3) ./"&)2#/(3) !"#$%&'() ./"&)2#/(3)
Secure  messaging  with  Atom   •  The  contents  of  individual  atom:entry  elements  can  be   encrypted  with  public/shared  keys  for  specific  consumers   •  Only  consumers  who  know  the  corresponding  private/ shared  key  can  make  sense  of  the  content   –  To  anyone  else,  it’s  gibberish   •  Keep  the  crypto  strong!   –  This  will  be  in  the  public  domain,  beware  brute  force  on   weak  algorithms   •  Can  cache  this  widely,  reduced  performance  hit   •  But  beware  coupling  via  keys!  
OpenID   •  OpenID  is  a  decentralised  framework  for  digital  identities   –  Not  trust,  just  identity!   •  Your  have  an  OpenID  provider  or  one  is  provided  for  you   –  It  has  a  URI   •  Services  that  you  interact  with  will  ask  for  that  URI   •  Your  OpenID  provider  will  either:   –  Accept  the  request  for  processing  immediately   –  Ask  whether  you  trust  the  requesting  site  (e.g.  via  email   with  hyperlinks)   •  Once  your  OpenID  server  OK’s  the  login,  then  you  are   authenticated  against  the  remote  service   Authen8ca8ng  doesn’t  mo   you’re  authorised  to  d ean   –  With  your  canonical  credentials   anything!     This  is  not  a  trust  system!  
OpenID  Workflow   *+'#,-).("/01'() #) <7) "/'( 8" :7 =' )- 59 0$5 ;)> ) #8 @' ?5 @9 %C ; )E # C) 3' D7 '5 ) 10( )B' F7 !"2'') !"#$%&'() 67),#0898"#) *(1'(0#3) 4'(/05') ) A7)B'10('5C )!('1 '#89H$) G7).('$'#C
Not-­‐So-­‐OpenID?   •  There’s  no  trust  between  OpenID  providers   •  Your  Web  service  might  not  accept  my  OpenID  provider   –  In  general  it  won’t!   •  Trusted  providers  centralise  control   –  Against  the  philosophy  of  decentralised  ID!   •  Federated  providers  won’t  interoperate   –  Need  a  hybrid  “signing”  model  like  CAs?  
OAuth   •  Web-­‐focused  access  delegation  protocol   •  Give  other  Web-­‐based  services  access  to  some  of  your   protected  data  without  disclosing  your  credentials   •  Simple  protocol  based  on  HTTP  redirection,  cryptographic   hashes  and  digital  signatures   •  Extends  HTTP  Authentication  as  the  spec  allows   –  Makes  use  of  the  same  headers  and  status  codes   –  These  are  understood  by  browsers  and  programmatic   clients   •  Not  dependent  on  OpenID,  but  can  be  used  together  
Why  OAuth?  
OAuth  Workflow   Consumer   2.  Request  insurance  policies   Service  Provider   Insurance   Insurance   Broker   3.  Reject  with  authorisa8on  token   Provider   5.  Log  in  to   4.  Redirect  to     insurance  provider  and   insurance  provider   supply  authorisa8on  token   with  authorisa8on  token   6.  Authorise     1.  Request   broker  access  to   broker  to  obtain   exis8ng  policies   exis8ng  insurance     policies  from  insurance  provider   User  
Tech  Interlude   Service  Hacks  and  Defences  
Denial  of  Service   POST /order HTTP/1.1 •  Large  incoming  representations   Host: restbucks.com can  cause  problems   Content-Type:application/vnd.restbucks +xml –  DoS  through  memory  consumption   on  the  server   <order xmlns="http:// schemas.restbucks.com/order"> •  Use  the  Content-Length   <location>takeAway</location> <item> header  strictly   <name>latte</name> –  No  header,  bin  payload   <quantity>1</quantity> •  400  Bad  Request   <milk>whole</milk> <size>small</size> –  Stop  processing  payload  after  the   </item> number  of  bytes  in  the  header   <!-- Millions more item elements --> <item> –  Bin  payloads  for  suspiciously  large   <name>latte</name> headers   <quantity>1</quantity> •  Who  wants  a  million  cappuccinos?   <milk>skim</milk> <size>small</size> •  Swallow  OutOfMemoryError   </item> or  OutOfMemoryException </order> –  Don’t  let  them  know  they  won!  
Keep  Secrets,  Secret   •  You  can  be  a  good  guy,  and  help  attackers   –  E.g.  401   –  Says  there’s  something  interesting  here!   •  Or  you  can  be  less  helpful   –  404   –  Says  there’s  nothing  to  see  here,  even  if  there  really  is   •  Don’t  use  easily  guessable  URIs  –  they  can  be  hijacked   –  UUID  is  your  friend   •  Think  carefully  about  what  attackers  can  learn  from   probing  you   –  You  don’t  always  want  to  be  a  good  guy!  
Act  Defensively   •  Validate  the  content  of   <order xmlns="http:// representations   schemas.restbucks.com/ –  Just  over  216  café  lattes  would  be   order"> quite  lucrative     <location>takeAway</ –  But  is  likely  a  ruse  to  get  a  large   location> negative  number  into  our   workflow   <item> •  Integer  overflow?   <name>latte</name> •  Don’t  forget  anti-­‐corruption   <quantity> layering  between  your  resources   2147483648 and  you  domain  model   </quantity> –  REST  is  not  mindlessly  exposing  a   domain  over  HTTP!   <milk>whole</milk> <size>small</size> </item> ... </order>
Don’t  be  gamed   GET /order/../../../../etc/passwd HTTP/1.1 GET /order/../../../../dev/random HTTP/1.1 Host: restbucks.com Host: restbucks.com •  Oh  oh   •  Oh  oh   •  We  just  gave  up  the   •  We  just  generated  a  never-­‐ password  file   ending  stream  of  bytes   •  And  rainbow  tables   •  And  now  we’re  going  to   cracked  it  in  no  time   spend  all  our  time  serving   them   Frameworks  help  avoid  these  problems  
Less  is  best   •  Bugs  hide  in  code   •  Bugs  cause  security  breaches   •  Less  code,  less  places  for  bugs  to  hide   •  So  build  only  what  you  need   –  And  keep  your  software  soft  so  you  can  grow  it  over   time  
Defend  in  Depth   •  Use  firewalls   –  On  the  network,  and  on  the  server   •  Do  open  ports  80  and  443   –  Do  not  open  other  ports   •  Do  not  mistake  HTTPS  for  security   –  It’s  not  enough!   •  Run  at  least  privilege   –  Never  run  your  service  as  root  or  administrator   •  Keep  good  deployment  hygiene   –  No  lingering  artifacts  that  attackers  can  grab  hold  of     •  Deploy  only  the  config  files,  DBs,  etc  that  you  need   •  And  remove  what  you  don’t   •  And  remember  that  social  engineering  is  still  effective!  
Atom  and  AtomPub  
Atom   <feed xmlns="http://www.w3.org/2005/Atom"> <title type="text">Inventory</title> <id>urn:uuid:426830d2-ab1d-11dd-a9c5-c85155d89593</id> <updated>2008-09-10T14:50:00Z</updated> <author> <name>Leicester Square</name> <uri>http://restbucks.com/stores/1234</uri> </author> <link rel="self" href="http://restbucks.com/stores/1234/inventory"/> <entry> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">Chocolate Chip Cookies</title> <updated>2008-09-10T14:45:32Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/9876" type="application/vnd.restbucks+xml"/> </product> <quantity>678</quantity> </inventory> </content> </entry> <entry> <id>urn:uuid:7fb82319-b190-46d2-bb88-c9fcce240643</id> <title type="text">Fairtrade Coffee</title> <updated>2008-09-10T13:55:02Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/211" type="application/vnd.restbucks+xml"/> </product> <quantity>407</quantity> </inventory> </content> </entry> </feed>
Atom  model   feed entry 0 id category id title title updated updated content resource outOfLine inlineText inlineXHTML inlineOther Based  on  diagrams  by  Stefan  Tilkov  
Entries  can  be  standalone   <entry xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">Chocolate Chip Cookies</title> <updated>2008-09-10T14:45:32Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/9876" type="application/vnd.restbucks+xml"/> </product> <quantity>678</quantity> </inventory> </content> </entry>
AtomPub     Application  protocol   Methods,   Not  just   Client     status  codes,   for   Atom   Server   headers   resources   editing  Web  resources   Atom   using   envelope   HTTP  transfer  of   Atom-­‐formatted  representations  
AtomPub  model   collection member 0 id id title title updated updated category workspace entry link service document resource Based  on  diagrams  by  Stefan  Tilkov  
Restbucks   Order   Management   Product   Regional   Management   Distribution   Inventory  
Who  needs  to  know  what?   Order   Management   Product  Updated   Product  Updated   Product   Regional   Management   Distribution   Inventory   Product  Updated  
Implementation  options   Point-­‐to-­‐point   •  Publisher  maintains  subscriber  list   •  Queues  to  reduce  temporal  coupling   Bus   •  Subscriptions  and  guaranteed  delivery  delegated  to   middleware   •  Reduced  location  and  temporal  coupling   Consumers  pull  events   •  Consumers  poll  publishers   •  Guaranteed  delivery  delegated  to  consumers   •  No  list  of  subscribers  to  maintain  
Polling  an  Atom  feed   Order     Management   Atom  Client   http://restbucks.com/products/notifications   Product   Management   Atom  icons  from  http://sniker.blogage.de/  
Atom  feed  represents  an  event  stream   <feed xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:be21b6b0-57b4-4029-ada4-09585ee74adc</id> <title type="text">Product Notifications</title> <updated>2008-09-10T14:50:32+01:00</updated> <author> <name>Product Management</name> <uri>http://restbucks.com/products</uri> </author> <link rel="self" href="http://restbucks.com/products/notifications/2008/9/10/13"/> <link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/12"/> <entry> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">product created</title> <updated>2008-09-10T14:45:32+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/95506d98-aae9-4d34-a8f4-1ff30bece80c"/> <category term="product"/> <category term="created"/> <content type="application/xml"> <product xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="1" href="http://restbucks.com/products/527"/> <id>527</id> <name>Fairtrade Roma Coffee Beans</name> <size>1kg</size> <price>10</price> </product> </content> </entry> ... </feed>
On  the  wire   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com Response   HTTP/1.1 200 OK Cache-Control: max-age=60 Content-Length: 12230 Content-Type: application/atom+xml;charset="utf-8" Content-Location: http://restbucks.com/products/notifications/2008/9/10/13 Last-Modified: Wed, 10 Sep 2008 13:50:32 GMT ETag: "6a0806ca" Date: Wed, 10 Sep 2008 13:51:03 GMT <feed xmlns="http://www.w3.org/2005/Atom"><id>urn:uuid:be21b6b0-57b4-4029- ada4-09585ee74adc</id><title type="text">Product Notifications</ title><updated>2008-09-10T14:50:32+01:00</updated><author><name>Product Management</ name><uri>http://restbucks.com/products</uri></author><link rel="self" href="http:// restbucks.com/products/notifications/2008/9/10/13"/><link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/12"/><entry><id>urn:uuid: 95506d98-aae9-4d34-a8f4-1ff30bece80c</id><title type="text">product created</ title><updated>2008-09-10T14:45:32+01:00</updated><link rel="self" href="http:// restbucks.com/products/notifications/95506d98-aae9-4d34-a8f4-1ff30bece80c"/><category term="product"/><category term="created"/><content type="application/xml"><product xmlns="http://restbucks.com/products" ...
Retrieving  the  archive  by  following  links   Request   GET /products/notifications/2008/9/10/12 HTTP/1.1 Host: restbucks.com Response   HTTP/1.1 200 OK Cache-Control: max-age=2592000 Content-Length: 9877 Content-Type: application/atom+xml;charset="utf-8" Last-Modified: Wed, 10 Sep 2008 12:57:14 GMT Date: Wed, 10 Sep 2008 13:51:46 GMT <feed xmlns="http://www.w3.org/2005/Atom"><id>urn:uuid:4cbc0acf-a211-40ce-a50e- a75d299571da</id><title type="text">Product Notifications</ title><updated>2008-09-10T13:57:14+01:00</updated><author><name>Product Management</ name><uri>http://restbucks.com/products</uri></author><link rel="self" href="http:// restbucks.com/products/notifications/2008/9/10/12"/><link rel="current" href="http:// restbucks.com/products/notifications/2008/9/10/13"/><link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/11"/ ><entry><id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id><title type="text">promotion cancelled</title><updated>2008-09-10T13:57:14+01:00</ updated><link rel="self" href="http://restbucks.com/products/notifications/ b436fda6-93f5-4c00-98a3-06b62c3d31b8"/><category term="promotion"/><category term="cancelled"/><content type="application/xml"><promotion xmlns="http:// restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"><atom:link type="application/xml" ...
Archive   <feed xmlns="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"> <id>urn:uuid:4cbc0acf-a211-40ce-a50e-a75d299571da</id> <title type="text">Product Notifications</title> <updated>2008-09-10T13:57:14+01:00</updated> <author> <name>Product Management</name> <uri>http://restbucks.com/products</uri> </author> <link rel="self" href="http://restbucks.com/products/notifications/2008/9/10/12"/> <link rel=”next-archive" href="http://restbucks.com/products/notifications/2008/9/10/13"/> <link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/11"/> <fh:archive/> <entry> <id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id> <title type="text">promotion cancelled</title> <updated>2008-09-10T13:57:14+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/b436fda6-93f5-4c00-98a3-06b62c3d31b8"/> <category term="promotion"/> <category term="cancelled"/> <content type="application/xml"> <promotion xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="3" href="http://restbucks.com/products/391"/> <regions> <atom:link type="application/atom+xml;type=feed" etag="14" href="http://restbucks.com/regions/london"/> </regions> <products> <atom:link type="application/xml" etag="1" href="http://restbucks.com/products/7642"/> </products> </promotion> </content> </entry> ... </feed>
An  Atom  entry  represents  an  event   <entry xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id> <title type="text">promotion cancelled</title> <updated>2008-09-10T13:57:14+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/b436fda6-93f5-4c00-98a3-06b62c3d31b8"/> <category term="promotion"/> <category term="cancelled"/> <content type="application/xml"> <promotion xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="3" href="http://restbucks.com/products/391"/> <regions> <atom:link type="application/atom+xml;type=feed" etag="14" href="http://restbucks.com/regions/london"/> </regions> <products> <atom:link type="application/xml" etag="1" href="http://restbucks.com/products/7642"/> </products> </promotion> </content> </entry>
Handling  eager  re-­‐polling   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com If-None-Match: "6a0806ca" Response   HTTP/1.1 304 Not Modified Date: Wed, 10 Sep 2008 13:57:20 GMT
Divide  and  conquer   feed   entry   Events   Entities   promotion   product  
An  Atom-­‐  and  AtomPub-­‐enabled  service   AtomPub   AtomPub   Atom   Atom  
Caching  archived  feeds   “prev-­‐archive”   Current   “prev-­‐archive”   “prev-­‐archive”   “next-­‐archive”   Local  cache   “next-­‐archive”   “next-­‐archive”  
Domain  application  protocol   prev next consuming antecedent feed prev consuming next prev current feed consuming next subsequent feed next
"application/atom+xml"   Atom  Publishing  Protocol   "An  IRI  of  an  editable  Member  Entry.   When  appearing  within  an  atom:entry,   the  href  IRI  can  be  used  to  retrieve,   update  and  delete  the  Resource   represented  by  that  Entry."   <link rel="edit" href="http://restbucks.com/products/notifications/2008/9/10/13" type="application/atom+xml;type=entry"/> Atom  Syndication  Format  
Remember:  "application/xml"  is  not  your  friend   "application/xml"   Out-­‐of-­‐band  processing  model   Processing  model   Namespace   Application-­‐specific   ?   hypermedia  semantics   Documented   ?   operations   XML  Schema,     It’s  XML…   RELAX  NG,  etc  
Custom  media  types   "application/vnd.restbucks+xml"   Processing  model   "application/atom+xml"   Hypermedia  controls   <atom:link/>   Registry  of  Link   Supported  methods   Relations   Representation   formats   Media  type  for  tuning  the   hypermedia  engine;   schema  for  structure  
Caching   Uri   Description   Caching   /products/notifications Current   Short   /products/notifications/{year}/{month}/{day}/{hour} Archive   Long   /products/notifications/{entry-id} Notification   Long   /products/{product-id} Product   Varies   /products/{hardware-id} Promotion   Varies  
Caches   Caching  proxy   Local  cache   Reverse  proxy   (Gateway)  
Caching  the  bus   Client   Cache   Service   Client   Client  
Protecting  feeds   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com Authorization: Basic aWFuc3JvYmluc29uOlBhdHQzcm41== Response   ... Cache-control: public, no-cache Caching  proxy   Local  cache   Reverse  proxy   (Gateway)  
Caching  dilemma   Efficient  use  of  network     resources   High  TTL   Low  TTL   Publisher  controls  freshness     of  data  
Cache  channels   Mark  Nottingham,  Yahoo   •  http://www.mnot.net/cache_channels/   Use  Atom  to  extend  the  freshness  of  cached  responses   Response   Cache-Control: max-age=60, channel="http://restbucks.com/products/channel/index", channel-maxage Response  remains  fresh  as  long  as:   •  Cache  polls  channel  at  least  as  often  as  "precision"   specified  by  channel   •  Channel  doesn’t  issue  stale  event  
Epilogue  
Web  Architecture   •  Ubiquitous,  global  on-­‐ramp   •  Connects  everything  to  everything,  based  on  URI-­‐ addressable  resources   –  With  a  uniform  interface   •  Also  provides  standard  coordination  mechanism   –  Status  codes!   •  And  is  ambivalent  about  content   •  Media  types!  
URI  Tunnelling   •  Map  URIs  to  methods  and  GET  those  URIs   –  Easy,  ubiquitous   •  Not  very  Web-­‐friendly   –  Breaks  expectations   –  Remember  the  library  of  congress  incident?  
POX   •  Treats  HTTP  as  a  synchronous  transport  protocol   –  Great  because  it  gets  through  firewalls   •  But  again  breaks  expectations   –  HTTP  is  not  MOM!   •  Misses  out  on  all  the  good  stuff  from  the  Web   –  Status  codes  for  coordination   –  Caching  for  performance   –  Loose  coupling  via  hypermedia   –  Etc   •  Not  as  good  as  proper  message-­‐oriented  middleware   –  Which  are  low-­‐latency,  reliable,  etc.  
CRUD  Services   •  The  simplest  kind  of  Web-­‐based  service   •  Embraces  HTTP  and  Web  infrastructure   –  Four  verbs,  status  codes,  formats   –  Cacheable!   •  Can  easily  describe  them   –  URI  templates   –  WADL   •  But  tightly  couples  client  and  server   –  Might  not  be  a  problem  in  some  domains  
Hypermedia   •  It’s  all  about  media  types  and  link  relations!   –  Describe  state  machines  with  lots  of  lovely  links   •  Constrain  what  you  can  do  to  resources  with  the  uniform   interface   •  Loosely  coupled   –  The  server  mints  URIs  to  resources,  clients  follow  them   –  Easily  spans  systems/domains  (URIs  are  great!)   •  Embraces  the  Web  for  robustness   –  Verbs,  status  codes,  caching   •  Design  and  implementation:   –  Design  application  protocol  state  machines;     –  Implement  resource  lifecycles;     –  Document  using  media  types,  link  relation  values  and   HTTP  idioms.  
REST in Practice
REST in Practice
REST in Practice
Scalability   •  Everything  you  know  still  applies   –  Stateless  is  good   –  Horizontal  is  good   •  Yet  everything  you  know  no  longer  applies!   –  Text-­‐based  synchronous  protocol  is  scalable???   •  Do  as  little  work  as  possible   –  Make  interactions  conditional   •  ETags  and  if-­‐modified  etc  are  your  friends   •  And  cache!  
Security   •  HTTPS  is  still  our  friend!   –  But  it  inhibits  caching   •  OpenID  support  waning  on  the  human  Web   •  OpenAuth  now  finding  its  feet   –  Likely  to  become  dominant  approach   •  Other  approaches  like  SAML,  mature  but  yet  to  be  widely   deployed  
REST in Practice
…you   wouldn’t   use  it  at   home!  
Atom  and  AtomPub   •  Atom  is  format  that  describes  list  of  things   –  In  terms  of  feeds  and  entries   •  AtomPub  is  a  protocol  defined  in  terms  Atom  entries  and   links   •  Together  they  can  be  used  for  very  scalable  pub/sub   –  But  latency  is  very  high  compared  to  enterprise  pub/sub   –  Caching  enables  massive  scalability   –  But  causes  latency  
Liked  the  Tutorial?   GET  /theBook   204  No  Content     (until  early  2010!)  

More Related Content

PPT
AP/AR Netting R12
abhinav.garud
 
PDF
Oracle procurement contracts
sivakumar046
 
PDF
Oaf personaliztion examples
Kaushik Kumar Kuberanathan
 
PDF
Oracle R12 Cash Management New Features
Sanjay Challagundla
 
PPT
Oracle Cash Management
Mohamed159686
 
PPTX
Ssrs introduction session 1
Muthuvel P
 
PPT
Extensions in OAF
iWare Logic Technologies Pvt. Ltd.
 
DOCX
BR100 Oracle AP Setup
Baker Khader Abdallah, PMP
 
AP/AR Netting R12
abhinav.garud
 
Oracle procurement contracts
sivakumar046
 
Oaf personaliztion examples
Kaushik Kumar Kuberanathan
 
Oracle R12 Cash Management New Features
Sanjay Challagundla
 
Oracle Cash Management
Mohamed159686
 
Ssrs introduction session 1
Muthuvel P
 
Extensions in OAF
iWare Logic Technologies Pvt. Ltd.
 
BR100 Oracle AP Setup
Baker Khader Abdallah, PMP
 

What's hot (20)

PPT
Oracle Applications R12 architecture
Sekhar Byna
 
PPTX
Statistical Accounts and Data in Oracle Cloud General Ledger
Mahesh Vallampati
 
PDF
R12 Tax GST slides
InSync Conference
 
DOC
R12 subinventory transfer and inter org transfers
shravan kumar chelika
 
PDF
Oracle apps-interview-questions
Pakeera Mekala
 
PPTX
Oracle Cloud ERP Report and Analytics | What are Cloud ERP reporting Options ...
CLTConsultingService
 
DOC
Oracle Assets Period Closing
Baker Khader Abdallah, PMP
 
PPTX
Oracle receivables
Suresh Mishra
 
PDF
Oracle_Procurement_Cloud_Release_8_Whats_New
Khalil Rehman NLP (MPrac) MCIPS, PMP,OCP
 
PPT
Basics of Oracle Order Management
shravan kumar chelika
 
PDF
Oracle Apps Technical – Short notes on RICE Components.
Boopathy CS
 
PPTX
Oracle fusion financial p2p cycle
mohamed mahmoud
 
PPT
Oracle Web ADI Implementation Steps
standale
 
PDF
Ame how to diagnose issues with the default approver list in purchasing when ...
Abdul Rahman Fouad Thabit
 
PDF
OLTP vs OLAP
BI_Solutions
 
PDF
All About Multi Organization Access
Ahmed Elshayeb
 
PDF
The Wright Move – A Continued Journey to the Oracle EPM Cloud
Alithya
 
PPTX
oracle ebs-r12-advanced-collections-ppt.pptx
Vikas Rai PRINCE2® ITIL®
 
PPTX
IntegrationBroker
meghamystic
 
PDF
Oracle Payables R12 ivas
Ali Ibrahim
 
Oracle Applications R12 architecture
Sekhar Byna
 
Statistical Accounts and Data in Oracle Cloud General Ledger
Mahesh Vallampati
 
R12 Tax GST slides
InSync Conference
 
R12 subinventory transfer and inter org transfers
shravan kumar chelika
 
Oracle apps-interview-questions
Pakeera Mekala
 
Oracle Cloud ERP Report and Analytics | What are Cloud ERP reporting Options ...
CLTConsultingService
 
Oracle Assets Period Closing
Baker Khader Abdallah, PMP
 
Oracle receivables
Suresh Mishra
 
Oracle_Procurement_Cloud_Release_8_Whats_New
Khalil Rehman NLP (MPrac) MCIPS, PMP,OCP
 
Basics of Oracle Order Management
shravan kumar chelika
 
Oracle Apps Technical – Short notes on RICE Components.
Boopathy CS
 
Oracle fusion financial p2p cycle
mohamed mahmoud
 
Oracle Web ADI Implementation Steps
standale
 
Ame how to diagnose issues with the default approver list in purchasing when ...
Abdul Rahman Fouad Thabit
 
OLTP vs OLAP
BI_Solutions
 
All About Multi Organization Access
Ahmed Elshayeb
 
The Wright Move – A Continued Journey to the Oracle EPM Cloud
Alithya
 
oracle ebs-r12-advanced-collections-ppt.pptx
Vikas Rai PRINCE2® ITIL®
 
IntegrationBroker
meghamystic
 
Oracle Payables R12 ivas
Ali Ibrahim
 
Ad

Viewers also liked (20)

PPT
Stop Making The Web Harder Than It Is; Real-world REST, HATEOAS, and Hypermed...
kiphampton
 
PDF
Introduction to PhoneGap
RameshNair6
 
PPTX
All About Phonegap
Sushan Sharma
 
PDF
WS-* vs. RESTful Services
Cesare Pautasso
 
PPTX
MomentumSI Programming Language Recommendations
Jeff Schneider
 
PPTX
Fixed Fee / Fixed Bid Delivery
Jeff Schneider
 
PPTX
Dev ops in 2013
Jeff Schneider
 
PPTX
A MomentumSI Briefing: SOA in 2013
Jeff Schneider
 
PDF
HATEOAS: The Confusing Bit from REST
elliando dias
 
PPTX
Beyond technical debt
Jeff Schneider
 
ODP
Introduction to PhoneGap
Quang Minh Dao
 
PPTX
Phone gap
Madhura Keskar
 
PDF
REST: From GET to HATEOAS
Jos Dirksen
 
PDF
Jim Webber Martin Fowler Does My Bus Look Big In This
deimos
 
PDF
How Can I Grow Tall
wiesneskib
 
PDF
อุปกรณ์เครือข่ายคอมพิวเตอร์
I'Tay Tanawin
 
PDF
Urban intelligence - June 2012 - Asian cities and the global growth map
MIPIMWorld
 
PDF
Node.js first slide
Soni Pandey
 
PPTX
Ostern in finnland atte 8 m (2)
Eine kleine Deutschkiste
 
PDF
Purity 2016
Sophie Cusack
 
Stop Making The Web Harder Than It Is; Real-world REST, HATEOAS, and Hypermed...
kiphampton
 
Introduction to PhoneGap
RameshNair6
 
All About Phonegap
Sushan Sharma
 
WS-* vs. RESTful Services
Cesare Pautasso
 
MomentumSI Programming Language Recommendations
Jeff Schneider
 
Fixed Fee / Fixed Bid Delivery
Jeff Schneider
 
Dev ops in 2013
Jeff Schneider
 
A MomentumSI Briefing: SOA in 2013
Jeff Schneider
 
HATEOAS: The Confusing Bit from REST
elliando dias
 
Beyond technical debt
Jeff Schneider
 
Introduction to PhoneGap
Quang Minh Dao
 
Phone gap
Madhura Keskar
 
REST: From GET to HATEOAS
Jos Dirksen
 
Jim Webber Martin Fowler Does My Bus Look Big In This
deimos
 
How Can I Grow Tall
wiesneskib
 
อุปกรณ์เครือข่ายคอมพิวเตอร์
I'Tay Tanawin
 
Urban intelligence - June 2012 - Asian cities and the global growth map
MIPIMWorld
 
Node.js first slide
Soni Pandey
 
Ostern in finnland atte 8 m (2)
Eine kleine Deutschkiste
 
Purity 2016
Sophie Cusack
 
Ad

Similar to REST in Practice (20)

PPTX
Cross-platform interaction
Oleksii Duhno
 
PDF
SharePoint on Imaginary Hardware - IndyTechFest 2010
John Ferringer
 
PPTX
Rest assured
Yaniv Rodenski
 
PDF
Understanding REST-Based Services: Simple, Scalable, and Platform Independent
Charles Knight
 
PPT
A review of the state of the art in Machine Learning on the Semantic Web
Simon Price
 
PDF
Service-Oriented Design and Implement with Rails3
Wen-Tien Chang
 
PDF
Mark Little R E S Tand W S Star
SOA Symposium
 
PPTX
Web 3 final(1)
Venky Dood
 
PDF
Jim Webber R E S Tful Services
SOA Symposium
 
PPTX
Reconceiving the Web as a Distributed (NoSQL) Data System
Daniel Austin
 
PDF
W3C Data Shapes Working Group 2014
3 Round Stones
 
PDF
Devoxx 2008 - REST in Peace
stevenn
 
PDF
ISWC GoodRelations Tutorial Part 2
Martin Hepp
 
PDF
GoodRelations Tutorial Part 2
guestecacad2
 
PPTX
Scaling with swagger
Tony Tam
 
PDF
The Characteristics of a RESTful Semantic Web and Why They Are Important
Chimezie Ogbuji
 
PPT
Rest introduction
Manav Prasad
 
PDF
Introduction to REST and Jersey
Chris Winters
 
PPTX
The Rise of NoSQL and Polyglot Persistence
Abdelmonaim Remani
 
PDF
eMusic: WordPress in the Enterprise
Scott Taylor
 
Cross-platform interaction
Oleksii Duhno
 
SharePoint on Imaginary Hardware - IndyTechFest 2010
John Ferringer
 
Rest assured
Yaniv Rodenski
 
Understanding REST-Based Services: Simple, Scalable, and Platform Independent
Charles Knight
 
A review of the state of the art in Machine Learning on the Semantic Web
Simon Price
 
Service-Oriented Design and Implement with Rails3
Wen-Tien Chang
 
Mark Little R E S Tand W S Star
SOA Symposium
 
Web 3 final(1)
Venky Dood
 
Jim Webber R E S Tful Services
SOA Symposium
 
Reconceiving the Web as a Distributed (NoSQL) Data System
Daniel Austin
 
W3C Data Shapes Working Group 2014
3 Round Stones
 
Devoxx 2008 - REST in Peace
stevenn
 
ISWC GoodRelations Tutorial Part 2
Martin Hepp
 
GoodRelations Tutorial Part 2
guestecacad2
 
Scaling with swagger
Tony Tam
 
The Characteristics of a RESTful Semantic Web and Why They Are Important
Chimezie Ogbuji
 
Rest introduction
Manav Prasad
 
Introduction to REST and Jersey
Chris Winters
 
The Rise of NoSQL and Polyglot Persistence
Abdelmonaim Remani
 
eMusic: WordPress in the Enterprise
Scott Taylor
 

More from Guilherme Silveira (20)

KEY
Equipes ágeis em 2012 - Lições aprendidas
Guilherme Silveira
 
KEY
Introducao a machine learning na educacao
Guilherme Silveira
 
KEY
Depois de Scrum e XP: não pare de aprender, não pare de inovar
Guilherme Silveira
 
KEY
O grandiosismo dos loucos - Agile Brazil 2011, Cecilia Fernandes e Guilherme ...
Guilherme Silveira
 
KEY
Software de qualidade e qualidade de código
Guilherme Silveira
 
KEY
REST: Hypermidia e Cache - DNAD 2011
Guilherme Silveira
 
KEY
Crie seu sistema REST com JAX-RS e o futuro
Guilherme Silveira
 
PDF
Using the web for real
Guilherme Silveira
 
PDF
Arquitetura: chega de mesmice
Guilherme Silveira
 
KEY
Arquitetura: chega de mesmice
Guilherme Silveira
 
KEY
Arquitetura chega de mesmice
Guilherme Silveira
 
KEY
Arquitetura: chega de mesmice
Guilherme Silveira
 
KEY
Put your client and server to rest - Javaone
Guilherme Silveira
 
KEY
Rest @ Qcon 2010
Guilherme Silveira
 
KEY
Rest clients
Guilherme Silveira
 
KEY
Rest clients
Guilherme Silveira
 
KEY
Rest clients
Guilherme Silveira
 
KEY
Um produto por semana
Guilherme Silveira
 
KEY
Deploy continuo, integraçao continua não basta
Guilherme Silveira
 
KEY
noSql + rest: Arquitetura Contemporanea
Guilherme Silveira
 
Equipes ágeis em 2012 - Lições aprendidas
Guilherme Silveira
 
Introducao a machine learning na educacao
Guilherme Silveira
 
Depois de Scrum e XP: não pare de aprender, não pare de inovar
Guilherme Silveira
 
O grandiosismo dos loucos - Agile Brazil 2011, Cecilia Fernandes e Guilherme ...
Guilherme Silveira
 
Software de qualidade e qualidade de código
Guilherme Silveira
 
REST: Hypermidia e Cache - DNAD 2011
Guilherme Silveira
 
Crie seu sistema REST com JAX-RS e o futuro
Guilherme Silveira
 
Using the web for real
Guilherme Silveira
 
Arquitetura: chega de mesmice
Guilherme Silveira
 
Arquitetura: chega de mesmice
Guilherme Silveira
 
Arquitetura chega de mesmice
Guilherme Silveira
 
Arquitetura: chega de mesmice
Guilherme Silveira
 
Put your client and server to rest - Javaone
Guilherme Silveira
 
Rest @ Qcon 2010
Guilherme Silveira
 
Rest clients
Guilherme Silveira
 
Rest clients
Guilherme Silveira
 
Rest clients
Guilherme Silveira
 
Um produto por semana
Guilherme Silveira
 
Deploy continuo, integraçao continua não basta
Guilherme Silveira
 
noSql + rest: Arquitetura Contemporanea
Guilherme Silveira
 

REST in Practice

  • 1. REST  in  Practice   A  Tutorial  on  Web-­‐based  Services   Jim  Webber   h*p://jim.webber.name   Savas  Parasta8dis   h*p://savas.me   Ian  Robinson   h*p://iansrobinson.com  
  • 2. Motivation   •  This  follows  the  plot  from  a  book  called  REST  in  Practice   which  is  currently  being  written  by:   –  Jim  Webber   –  Savas  Parastatidis   –  Ian  Robinson   •  With  help  from  lots  of  other  lovely  people  like:   –  Halvard  Skogsrud,  Lasse  Westh-­‐Nielsen,  Steve  Vinoski,   Mark  Nottingham,  Colin  Jack,  Spiros  Tzavellas,  Glen   Ford,  Sriram  Narayan,  Ken  Kolchier,  Guilherme  Silveira   and  many  more!     •  The  book  deals  with  the  Web  as  a  distributed  computing   platform   –  The  Web  as  a  whole,  not  just  REST   •  And  so  does  this  tutorial…  
  • 3. Timetable   •  09:00-­‐10:30   •  12:00-­‐13:00   –  Web  basics   –  Lunch   –  URI  templates   –  RPC   •  13:00-­‐14:30   –  HTTP   –  Hypermedia  design   –  CRUD   –  Scalability   •  10:30-­‐10:45     –  Security   –  Coffee  break   •  14:30-­‐14:45   •  10:45-­‐12:00   –  Coffee  break   –  Semantics   •  14:45-­‐16:00   –  Hypermedia  formats   –  Atom   –  Restbucks  DAP   –  AtomPub   –  Restbucks  retrospective   –  Epilogue  
  • 4. Introduction   •  This  is  a  tutorial  about  the  Web   •  It’s  very  HTTP  centric   •  But  it’s  not  about  Web  pages!   •  The  Web  is  a  middleware  platform  which  is…   –  Globally  deployed   –  Has  reach   –  Is  mature   –  And  is  a  reality  in  every  part  of  our  lives   •  Which  makes  it  interesting  for  distributed  systems  geeks  
  • 5. Leonard  Richardson's  Web  service  maturity  heuristic   What?   Why?   How?   Spreads  complexity   URIs   Divide  and  conquer   around   Refactor   (Do  the  same  things   Reduces  complexity   Uniform  interface   in  the  same  way)   Describe  special   Makes  complexity   Hypermedia   behaviour  in  a   learnable   standard  way   http://www.crummy.com/writing/  
  • 6. Why  Web?  Why  not  just  REST?   •  REST  is  a  brilliant   architectural  style   •  But  the  Web  allows  for   more  than  just  RESTful   systems   •  There’s  a  spectrum  of   maturity  of  service  styles   –  From  completely  bonkers  to   completely  RESTful   •  We’ll  use  the  Richardson   maturity  model  to  frame   these  kinds  of  discussions   –  Level  0  to  Level  3   –  Web-­‐ignorant  to  RESTful!  
  • 7. HTTP   URIs   REST  is  an  Architectural  style  suited  to  the  Web…   …but  it  is  not  mandatory  
  • 8. Why  the  Web?  Why  be  RESTful?   •  Scalable   •  Fault-­‐tolerant   •  Recoverable   •  Secure   •  Loosely  coupled   •  Precisely  the  same  characteristics  we  want  in  business   software  systems!  
  • 9. REST  isn’t…   •  Just  pretty  URIs   •  Just  XML  or  JSON   •  URI  templates   •  AJAX  applications   But  you  could  be  forgiven  for  thinking  it  is!  
  • 11. Web  History   •  Started  as  a  distributed  hypermedia  platform   –  CERN,  Berners-­‐Lee,  1990   •  Revolutionised  hypermedia   –  Imagine  emailing  someone  a  hypermedia  deck   nowadays!   •  Architecture  of  the  Web  largely  fortuitous   –  W3C  and  others  have  since  retrofitted/captured  the   Web’s  architectural  characteristics  
  • 12. The  Web  broke  the  rules  
  • 13. Web  Fundamentals   •  To  embrace  the  Web,  we  need  to  understand  how  it  works   •  The  Web  is  a  distributed  hypermedia  model   –  It  doesn’t  try  to  hide  that  distribution  from  you!   •  Our  challenge:     –  Figure  out  the  mapping  between  our  problem  domain   and  the  underlying  Web  platform  
  • 14. Key  Actors  in  the  Web  Architecture   Client   Cache   Firewall   Firewall   Resources   Router   Web  Server   Web  Server   ISP   Reverse   Proxy   Proxy  Server   Firewall   Resources  
  • 15. Resources   •  A  resource  is  something  “interesting”  in  your  system   •  Can  be  anything   –  Spreadsheet  (or  one  of  its  cells)   –  Blog  posting   –  Printer   –  Winning  lottery  numbers   –  A  transaction   –  Others?  
  • 16. Interacting  with  Resources   •  We  deal  with  representations  of  resources   –  Not  the  resources  themselves   •  “Pass-­‐by-­‐value”  semantics   –  Representation  can  be  in  any  format   •  Any  media  type   •  Each  resource  implements  a  standard  uniform  interface   –  Typically  the  HTTP  interface   •  Resources  have  names  and  addresses  (URIs)   –  Typically  HTTP  URIs  (aka  URLs)  
  • 17. Resource  Architecture   Consumer   (Web  Client)   Uniform  Interface   (Web  Server)   Logical  Resources   Resource  Representa8on   (e.g.  XML  document)   Physical  Resources  
  • 18. Resource  Representations   •  Making  your  system  Web-­‐friendly  increases  its  surface  area   –  You  expose  many  resources,  rather  than  fewer   endpoints   •  Each  resource  has  one  or  more  representations   –  Representations  like  JSON  or  XML  or  good  for  the   programmatic  Web   •  Moving  representations  across  the  network  is  the  way  we   transact  work  in  a  Web-­‐native  system  
  • 19. URIs   •  URIs  are  addresses  of  resources  in  Web-­‐based  systems   –  Each  resource  has  at  least  one  URI   •  They  identify  “interesting”  things   –  i.e.  Resources     •  Any  resource  implements  the  same  (uniform)  interface   –  Which  means  we  can  access  it  programmatically!   •  Declarative  scheme  
  • 20. URI/Resource  Relationship   •  Any  two  resources  cannot  be  identical   –  Because  then  you’ve  only  got  one  resource!   •  But  they  can  have  more  than  one  name   –  http://foo.com/software/latest   –  http://foo.com/software/v1.4   •  No  mechanism  for  URI  equality   •  Canonical  URIs  are  long-­‐lived   –  E.g.  http://example.com/versions/1.1  versus   http://example.com/versions/latest   –  Send  back  HTTP  303  (“see  also”)  if  the  request  is  for  an   alternate  URI   –  Or  set  the  Content-­‐Location  header  in  the  response  
  • 21. Scalability   •  Web  is  truly  Internet-­‐scale   –  Loose  coupling   •  Growth  of  the  Web  in  one  place  is  not  impacted  by   changes  in  other  places   –  Uniform  interface   •  HTTP  defines  a  standard  interface  for  all  actors  on   the  Web   •  Replication  and  caching  is  baked  into  this  model   –  Caches  have  the  same  interface  as  real  resources!   –  Stateless  model   •  Supports  horizontal  scaling  
  • 22. Fault  Tolerant   •  The  Web  is  stateless   –  All  information  required  to  process  a  request  must  be   present  in  that  request   •  Sessions  are  still  plausible,  but  must  be  handled  in  a   Web-­‐consistent  manner   –  Modelled  as  resources!   •  Statelessness  means  easy  replication   –  One  Web  server  is  replaceable  with  another   –  Easy  fail-­‐over,  horizontal  scaling  
  • 23. Recoverable   •  The  Web  places  emphasis  on  repeatable  information   retrieval   –  GET  is  idempotent   •  Library  of  Congress  found  this  the  hard  way!   –  In  failure  cases,  can  safely  repeat  GET  on  resources   •  HTTP  verbs  plus  rich  error  handling  help  to  remove   guesswork  from  recovery   –  HTTP  statuses  tell  you  what  happened!   –  Some  verbs  (e.g.  PUT,  DELETE)  are  safe  to  repeat  
  • 24. Secure   •  HTTPs  is  a  mature  technology   –  Based  on  SSL  for  secure  point-­‐to-­‐point  information   retrieval   •  Isn’t  sympathetic  to  Web  architecture   –  Restricted  caching  opportunities   •  Higher-­‐order  protocols  like  Atom  are  starting  to  change   this...   –  Encrypt  parts  of  a  resource  representation,  not  the   transport  channel   –  OK  to  cache!  
  • 25. Loosely  Coupled   •  Adding  a  Web  site  to  the  WWW  does  not  affect  any  other   existing  sites   •  All  Web  actors  support  the  same,  uniform  interface   –  Easy  to  plumb  new  actors  into  the  big  wide  web   •  Caches,  proxies,  servers,  resources,  etc  
  • 26. Tech  Interlude   URI  Templates  
  • 27. Conflicting  URI  Philosophies   •  URIs  should  be  descriptive,  predictable?   –  http://spreadsheet/cells/a2,a9   –  http://jim.webber.name/2007/06.aspx   •  Convey  some  ideas  about  how  the  underlying   resources  are  arranged   –  Can  infer  http://spreadsheet/cells/b0,b10  and  http:// jim.webber.name/2005/05.aspx  for  example   •  Nice  for  programmatic  access,  but  may  introduce   coupling   •  URIs  should  be  opaque?   –  http://tinyurl.com/6   –  TimBL  says  “opaque  URIs  are  cool”   •  Convey  no  semantics,  can’t  infer  anything  from  them   –  Don’t  introduce  coupling  
  • 28. URI  Templates,  in  brief   •  Use  URI  templates  to  make  your  resource  structure  easy  to   understand   •  For  Amazon  S3  (storage  service)  it’s  easy:   –  http://s3.amazon.com/{bucket-name}/{object- name} Bucket1   Bucket2   Object2   Object1   Object1   Object3   Object2  
  • 29. URI  Templates  are  Easy!   •  Take  the  URI:     http://restbucks.com/orders?{order_id} •  You  could  do  the  substitution  and  get  a  URI:     http://restbucks.com/orders?1234 •  Can  easily  make  more  complex  URIs  too   –  Mixing  template  and  non-­‐template  sections   http://restbucks.com/{orders}/{shop}/{year}/{month}.xml •  Use  URI  templates  client-­‐side  to  compute  server-­‐side  URIs   –  But  beware  this  introduces  coupling!  
  • 30. Why  URI  Templates?   •  Regular  URIs  are  a  good  idiom  in  Web-­‐based  services   –  Helps  with  understanding,  self  documentation   •  They  allow  users  to  infer  a  URI   –  If  the  pattern  is  regular   •  URI  templates  formalise  this  arrangement   –  And  advertise  a  template  rather  than  a  regular  URI  
  • 31. URI  Templates  Pros  and  Cons   •  Everything  interesting  in  a  Web-­‐based  service  has  a  URI   •  Remember,  two  schools  of  thought:   –  Opaque  URIs  are  cool  (Berners-­‐Lee)   –  Transparent  URIs  are  cool  (everyone  else)   •  URI  templates  present  two  core  concerns:   –  They  invite  clients  to  invent  URIs  which  may  not  be   honoured  by  the  server   –  They  increase  coupling  since  servers  must  honour   forever  any  URI  templates  they’ve  advertised   •  Use  URI  templates  sparingly,  and  with  caution   –  Entry  point  URIs  only  is  a  good  rule  of  thumb  
  • 33. Web  Tunnelling   •  Web  Services  tunnel  SOAP  over  HTTP   –  Using  the  Web  as  a  transport  only   –  Ignoring  many  of  the  features  for  robustness  the  Web   has  built  in   •  Many  Web  people  do  the  same!   –  URI  tunnelling,  POX  approaches  are  the  most  popular   styles  on  today’s  Web   –  Worse  than  SOAP!   But  they  claim  to   be  “lightweight”   •  Less  metadata!   and  RESTful  
  • 34. Richardson  Model  Level  1   •  Lots  of  URIs   –  But  really  has  a  more   level  0  mindset   •  Doesn’t  understand   HTTP   –  Other  than  as  a   transport   •  No  hypermedia  
  • 35. URI  Tunnelling  Pattern   •  Web  servers  understand  URIs   •  URIs  have  structure   •  Methods  have  signatures   •  Can  match  URI  structure  to  method  signature  
  • 37. Server-­‐Side  URI  Tunnelling  Example   public void ProcessGet(HttpListenerContext context) { // Parse the URI Order order = ParseUriForOrderDetails(context.Request.QueryString); string response = string.Empty; if (order != null) { // Process the order by calling the mapped method var orderConfirmation = RestbucksService.PlaceOrder(order); response = "OrderId=" + orderConfirmation.OrderId.ToString(); } else { response = "Failure: Could not place order."; } // Write to the response stream using (var sw = new StreamWriter(context.Response.OutputStream)) { sw.Write(response); } }
  • 38. Client-­‐Side  URI  Tunnelling   public OrderConfirmation PlaceOrder(Order order) { // Create the URI var sb = new StringBuilder("http://restbucks.com/PlaceOrder?"); sb.AppendFormat("coffee={0}", order.Coffee.ToString()); sb.AppendFormat("&size={0}", order.Size.ToString()); sb.AppendFormat("&milk={0}", order.Milk.ToString()); sb.AppendFormat("&consume-location={0}", order.ConsumeLocation.ToString()); // Set up the GET request var request = HttpRequest.Create(sb.ToString()) as HttpWebRequest; request.Method = "GET"; // Get the response var response = request.GetResponse(); // Read the contents of the response OrderConfirmation orderConfirmation = null; using (var sr = new StreamReader(response.GetResponseStream())) { var str = sr.ReadToEnd(); // Create an OrderConfirmation object from the response orderConfirmation = new OrderConfirmation(str); } return orderConfirmation; }
  • 39. URI  Tunnelling  Strengths   •  Very  easy  to  understand   •  Great  for  simple  procedure-­‐calls   •  Simple  to  code   –  Do  it  with  the  servlet  API,  HttpListener,  IHttpHandler,   Rails,  whatever!   •  Interoperable   –  It’s  just  URIs!  
  • 40. URI  Tunnelling  Weaknesses   •  It’s  brittle  RPC!   •  Tight  coupling,  no  metadata   –  No  typing  or  “return  values”  specified  in  the  URI   •  Not  robust  –  have  to  handle  failure  cases  manually   •  No  metadata  support   –  Construct  the  URIs  yourself,  map  them  to  the  function   manually   •  You  typically  use  GET  (prefer  POST)   –  OK  for  functions,  but  against  the  Web  for  procedures   with  side-­‐affects  
  • 41. POX  Pattern   •  Web  servers  understand  how  to  process  requests  with   bodies   –  Because  they  understand  forms   •  And  how  to  respond  with  a  body   –  Because  that’s  how  the  Web  works   •  POX  uses  XML  in  the  HTTP  request  and  response  to  move  a   call  stack  between  client  and  server  
  • 42. Richardson  Model  Level  0   •  Single  well-­‐known   endpoint   –  Not  really  URI  friendly   •  Doesn’t  understand   HTTP   –  Other  than  as  a   transport   •  No  hypermedia  
  • 44. POX  on  the  Wire  
  • 45. .Net  POX  Service  Example   From  the  Web  server   private void ProcessRequest(HttpListenerContext context) { string verb = context.Request.HttpMethod.ToLower().Trim(); switch (verb) { case "post": Check  HTTP  Verb  (we   { want  POST)   // Everything's done with post in this case XmlDocument request = new XmlDocument(); request.Load(XmlReader.Create (context.Request.InputStream)); Dispatch  it  for  processing   Turn  the  HTTP  body  into  an   XmlElement result = MyApp.Processdocument  for   XML   (request.DocumentElement); processing   byte[] returnValue = Utils.ConvertUnicodeString (Constants.Xml.XML_DECLARATION + result.OuterXml); Get  XML  result,  and  get  bytes   context.Response.OutputStream.Write(returnValue, 0, returnValue.Length); break; } ... Return  XML  bytes  to  client  
  • 46. Java  POX  Servlet   public class RestbucksService extends HttpServlet { @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Initialization code omitted for brevity try { requestReader = request.getReader(); responseWriter = response.getWriter(); String xmlRequest = extractPayload(requestReader); Order order = createOrder(xmlRequest); OrderConfirmation confirmation = restbucksService.placeOrder(order); embedPayload(requestWriter, confirmation.toString()); } finally { // Cleanup code omitted for brevity } }
  • 47. C#  POX  Client  Example   public OrderConfirmation PlaceOrder(string customerId, Item[] items) { // Serialize our objects XmlDocument requestXml = CreateXmlRequest(customerId, items); var client = new WebClient(); var ms = new MemoryStream(); requestXml.Save(ms); client.Headers.Add("Content-Type", "application/xml"); ms = new MemoryStream(client.UploadData("http://restbucks.com/ PlaceOrder", null, ms.ToArray())); var responseXml = new XmlDocument(); responseXml.Load(ms); return CreateOrderConfirmation(responseXml); }
  • 48. Java  Apache  Commons  Client   public class OrderingClient { private String sendRequestPost(String request, String uri) private static final String XML_HEADING = "<?xml throws version="1.0"?>n"; IOException, HttpException { private static final String NO_RESPONSE = "Error: No response."; PostMethod method = new PostMethod (uri); public String placeOrder(String customerId, method.setRequestHeader("Content- String[] itemIds) type", "application/xml"); throws Exception { method.setRequestBody(XML_HEADING + request); // XML string creation omitted for brevity // ... String responseBody = NO_RESPONSE; try { String response = sendRequestPost(request, new HttpClient().executeMethod "http://restbucks.com/PlaceOrder"); (method); responseBody = new String Document xmlResponse = (method.getResponseBody(), "UTF-8"); DocumentBuilderFactory.newInstance() .newDocumentBuilder } finally { ().parse( method.releaseConnection(); new InputSource(new } StringReader(response))); return responseBody; // XML response handling omitted for brevity } } }
  • 49. POX  Strengths   •  Simplicity  –  just  use  HTTP  POST  and  XML   •  Re-­‐use  existing  infrastructure  and  libraries   •  Interoperable   –  It’s  just  XML  and  HTTP   •  Can  use  complex  data  structures   –  By  encoding  them  in  XML  
  • 50. POX  Weaknesses   •  Client  and  server  must  collude  on  XML  payload   –  Tightly  coupled  approach   •  No  metadata  support   –  Unless  you’re  using  a  POX  toolkit  that  supports  WSDL   with  HTTP  binding  (like  WCF)   •  Does  not  use  Web  for  robustness   •  Does  not  use  SOAP  +  WS-­‐*  for  robustness  either  
  • 51. Web  Abuse   •  Both  POX  and  URI  Tunnelling  fail  to  take  advantage  of  the   Web   –  Ignoring  status  codes   –  Reduced  scope  for  caching   –  No  metadata   –  Manual  crash  recovery/compensation  leading  to  high   development  cost   –  Etc   •  They’re  useful  in  some  situations   –  And  you  can  implement  them  with  minimal  toolkit   support   –  But  they’re  not  especially  robust  patterns  
  • 53. Tech  Interlude   HTTP  Fundamentals  
  • 54. The  HTTP  Verbs   Decreasing  likelihood  of  being  understood  by  a   •  Retrieve  a  representation  of  a  resource:  GET   •  Create  a  new  resource:  PUT  to  a  new  URI,  or  POST   to  an  existing  URI   Web  server  today   •  Modify  an  existing  resource:  PUT  to  an  existing  URI   •  Delete  an  existing  resource:  DELETE   •  Get  metadata  about  an  existing  resource:  HEAD   •  See  which  of  the  verbs  the  resource  understands:   OPTIONS  
  • 55. HEAD  Semantics   •  HEAD  is  like  GET,  except  it  only  retrieves  metadata   •  Request   HEAD /order/1234 HTTP 1.1 Host: restbucks.com •  Response   200 OK Content-Type: application/vnd.restbucks +xml Last-Modified: 2007-07-08T15:00:34Z Etag: aabd653b-65d0-74da-bc63-4bca- ba3ef3f50432   Useful  for  caching,   performance  
  • 56. OPTIONS  Semantics   •  Asks  which  methods  are  supported  by  a  resource   –  Easy  to  spot  read-­‐only  resources  for  example   •  Request   OPTIONS /orders/1234 HTTP 1.1 Host: restbucks.com •  Response   You  can  only  read  and  add  to   this  resource,    may  change   200 OK over  8me   Allow: GET,HEAD,POST
  • 57. HTTP  Status  Codes   •  The  HTTP  status  codes  provide  metadata  about  the  state  of   resources   •  They  are  part  of  what  makes  the  Web  a  rich  platform  for   building  distributed  systems   •  They  cover  five  broad  categories   –  1xx  -­‐  Metadata   –  2xx  –  Everything’s  fine   –  3xx  –  Redirection   –  4xx  –  Client  did  something  wrong   –  5xx  –  Server  did  a  bad  thing   •  There  are  a  handful  of  these  codes  that  we  need  to  know  in   more  detail  
  • 58. 1xx   •  100  –  Continue   –  The  operation  will  be  accepted  by  the  service   –  The  “look  before  you  leap”  pattern   •  Use  with  the  Expect  header   •  Request   POST /orders HTTP/1.1 Content-Type: application/xml Expect: 100-continue •  Response   100 Continue or   417 Expectation Failed
  • 59. 2xx   •  200  –  OK   –  The  server  successfully  completed  whatever  the  client   asked  of  it   •  201  –  Created   –  Sent  when  a  new  resource  is  created  at  the  client’s   request  via  POST   –  Location  header  should  contain  the  URI  to  the  newly   created  resource   •  202  –  Accepted   –  Client’s  request  can’t  be  handled  in  a  timely  manner   –  Location  header  should  contain  a  URI  to  the  resource   that  will  eventually  be  exposed  to  fulfil  the  client’s   expectations  
  • 60. More  2xx  Codes   •  203  –  Non-­‐Authoritative  Information   –  Much  like  200,  except  the  client  knows  not  to  place  full  trust   in  any  headers  since  they  could  have  come  from  3rd  parties  or   be  cached  etc.   •  204  –  No  Content   –  The  server  declines  to  send  back  a  representation   •  Perhaps  because  the  associated  resource  doesn’t  have   one   –  Used  like  an  “ack”   •  Prominent  in  AJAX  applications   •  206  –  Partial  Content   –  Optimisation  used  in  failure  cases  to  support  partial  GETs   –  Request  Content-Range  header  must  specify  the  byte   range  of  the  resource  representation  it  wants   –  Response  headers  must  contain  Date;   •  ETag  and    Content-Location  headers  must  be   consistent  with  the  original  request  not  the  current  values  
  • 61. 3xx   •  301  –  Multiple  Choices   –  Response  Location  header  should  contain  the  preferred   URI   –  Message  body  can  contain  list  of  URIs     •  In  XHTML  possibly   –  In  general  avoid  being  ambiguous!   •  301  –  Moved  Permanently   –  Location  header  contains  the  new  location  of  the   resource   •  303  –  See  Other   –  Location  header  contains  the  location  of  an   alternative  resource   –  Used  for  redirection  
  • 62. More  3xx   •  304  –  Not  Modified   –  The  resource  hasn’t  changed,  use  the  existing   representation   –  Used  in  conjunction  with  conditional  GET   –  Client  sends  the  If-Modified-Since  header   –  Response  Date  header  must  be  set   –  Response  Etag  and  Content-Location headers   must  be  same  as  original  representation   •  307  –  Temporary  Redirect   –  The  request  hasn’t  been  processed,  because  the   resource  has  moved   –  Client  must  resubmit  request  to  the  URI  in  the  response   Location  header  
  • 63. 4xx   •  400  –  Bad  Request   –  The  client  has  PUT  or  POST  a  resource  representation   that  is  in  the  right  format,  but  contains  invalid   information   •  401  –  Unauthorized   –  Proper  credentials  to  operate  on  a  resource  weren’t   provided   –  Response  WWW-Authenticate  header  contains  the   type  of  authentication  the  server  expects   •  Basic,  digest,  WSSE,  etc   –  Don’t  leak  information!   •  Consider  404  in  these  situations  
  • 64. More  4xx   •  403  –  Forbidden   –  The  client  request  is  OK,  but  the  server  doesn’t  want  to   process  it   •  E.g.  Restricted  by  IP  address   –  Implies  that  resource  exists,  beware  leaking  information   •  404  –  Not  Found   –  The  standard  catch-­‐all  response   –  May  be  a  lie  to  prevent  401  or  403  information  leakage  
  • 65. Even  more  4xx   •  405  –  Method  Not  Allowed   –  The  resource  doesn’t  support  a  given  method   –  The  response  Allow  header  lists  the  verbs  the  resource   understands   •  E.g.  Allow: GET, POST, PUT •  406  –  Not  Acceptable   –  The  client  places  too  many  restrictions  on  the  resource   representation  via  the  Accept-*  header  in  the  request   –  The  server  can’t  satisfy  any  of  those  representations  
  • 66. Yet  More  4xx   •  409  –  Conflict   –  Tried  to  change  the  state  of  the  resource  to  something   the  server  won’t  allow   •  E.g.  Trying  to  DELETE  something  that  doesn’t  exist   •  410  –  Gone   –  The  resource  has  gone,  permanently.   –  Don’t  send  in  response  to  DELETE   •  The  client  won’t  know  if  it  was  deleted,  or  if  it  was   gone  and  the  delete  failed   •  411  –  Length  Required   –  If  a  request  (POST,  PUT)  contains  a  representation,  it   should  set  the  Content-Length  header   –  The  server  might  demand  this,  and  interrupt  the  client   request  
  • 67. Still  more  4xx   •  412  –  Precondition  Failed   –  Server/resource  couldn’t  meet  one  or  more   preconditions   •  As  specified  in  the  request  header   –  E.g.  Using  If-Unmodified-Since  and  PUT  to   modify  a  resource  provided  it  hasn’t  been  changed  by   others   •  413  –  Request  Entity  Too  Large   –  Response  comes  with  the  Retry-After  header  in  the   hope  that  the  failure  is  transient  
  • 68. Final  4xx  Codes   •  414  –  Request  URI  Too  Long   –  You’ve  got  a  hopeless  HTTP  server,  or  ridiculous  URI   names!   •  415  Unsupported  Media  Type   –  E.g.  If  the  server  resource  expects  JSON  but  the  client   sends  XML  
  • 69. 5xx  Codes   •  500  –  Internal  Server  Error   –  The  normal  response  when  we’re  lazy     •  501  –  Not  Implemented   –  The  client  tried  to  use  something  in  HTTP  which  this   server  doesn’t  support   •  Keep  HTTP  use  simple,  get  a  better  HTTP  server   •  502  –  Bad  Gateway   –  A  proxy  failed   –  Doesn’t  help  us  much    
  • 70. More  5xx  Codes   •  503  –  Service  Unavailable   –  The  HTTP  server  is  up,  but  not  supporting  resource   communication  properly   –  Server  may  send  a  Retry-After  header,  assuming  the   fault  is  transient  
  • 71. HTTP  Headers   •  Headers  provide  metadata  to  assist  processing   –  Identify  resource  representation  format  (media  type),   length  of  payload,  supported  verbs,  etc   •  HTTP  defines  a  wealth  of  these   –  And  like  status  codes  they  are  our  building  blocks  for   robust  service  implementations  
  • 72. Must-­‐know  Headers   •  Authorization   –  Contains  credentials  (basic,  digest,  WSSE,  etc)   –  Extensible   •  Content-­‐Length   –  Length  of  payload,  in  bytes   •  Content-­‐Type   –  The  resource  representation  form   •  E.g.  application/vnd.restbucks+xml,  application/ xhtml+xml  
  • 73. More  Must-­‐Know  Headers   •  Etag/If-­‐None-­‐Match   –  Opaque  identifier  –  think  “checksum”  for  resource   representations   –  Used  for  conditional  GET   •  If-­‐Modified-­‐Since/Last-­‐Modified   –  Used  for  conditional  GET  too   •  Host   –  Contains  the  domain-­‐name  part  of  the  URI  
  • 74. Yet  More  Must-­‐Know  Headers   •  Location   –  Used  to  flag  the  location  of  a  created/moved  resource   –  In  combination  with:   •  201  Created,  301  Moved  Permanently,  302  Found,  307   Temporary  Redirect,  300  Multiple  Choices,  303  See   Other   •  User-­‐Agent   –  Tells  the  server  side  what  the  client-­‐side  capabilities  are   –  Should  not  be  used  in  the  programmable  Web!  
  • 75. Final  Must-­‐Know  Headers   •  WWW-­‐Authenticate   –  Used  with  401  status   –  Informs  client  what  authentication  is  needed   •  Date   –  Mandatory!   –  Timestamps  on  request  and  response  
  • 76. Useful  Headers   •  Accept   –  Client  tells  server  what  formats  it  wants   –  Can  externalise  this  in  URI  names  in  the  general  case   •  Accept-­‐Encoding   –  Client  tells  server  that  it  can  compress  data  to  save   bandwidth   –  Client  specifies  the  compression  algorithm  it   understands   •  Content-­‐Encoding   –  Server-­‐side  partner  of  Accept-­‐Encoding  
  • 77. More  Useful  Headers   •  Allow   –  Server  tells  client  what  verbs  are  allowed  for  the   requested  resource  (used  in  combination  with   OPTIONS)   •  Cache-­‐Control   –  Metadata  for  caches,  tells  them  how  to  cache  (or  not)   the  resource  representation   –  And  for  how  long  etc.   •  Content-­‐MD5   –  Cryptographic  checksum  of  body   –  Useful  integrity  check,  has  computation  cost  
  • 78. Yet  More  Useful  Headers   •  Expect   –  A  conditional  –  client  asks  if  it’s  OK  to  proceed  by   expecting  100-­‐Continue   –  Server  either  responds  with  100  or  417  –  Expectation   Failed     •  Expires   –  Server  tells  client  or  proxy  server  that  representation   can  be  safely  cached  until  a  certain  time   •  If-­‐Match   –  Used  for  ETag  comparison   –  Opposite  of  If-­‐None-­‐Match  
  • 79. Final  Useful  Headers   •  If-­‐Unmodified-­‐Since   –  Useful  for  conditional  PUT/POST   •  Make  sure  the  resource  hasn’t  changed  while  you’re   been  manipulating  it   –  Compare  with  If-­‐Modified-­‐Since   •  Range   –  Specify  part  of  a  resource  representation  (a  byte  range)   that  you  need  –  aka  partial  GET   –  Useful  for  failure/recovery  scenarios  
  • 80. Less  Often-­‐Used  Headers   •  Retry-­‐After   –  Resource  or  server  is  out  of  action  for  the  specified  time   –  Usually  associated  with  413  –  Request  Entity  Too  Large,   or  one  of  the  5xx  server  error  statuses   •  Content-­‐Location   –  Header  gives  the  canonical  URI  of  the  resource   –  Client  might  be  using  a  different  URI  to  access  that   resource  
  • 81. HTTP  RCF  2616  is  Authoritative   •  The  statuses  and  headers  here  are  a  sample  of  the  full   range  of  headers  in  the  HTTP  spec   •  They  spec  contains  more  than  we  discuss  here   •  It  is  authoritative  about  usage   •  And  it’s  a  good  thing  to  keep  handy  when  you’re  working   on  a  Web-­‐based  distributed  system!  
  • 82. Embracing  HTTP  as  an   Application  Protocol  
  • 83. Using  the  Web   •  URI  tunnelling  and  POX  use  the  Web  as  a  transport   –  Just  like  SOAP  without  metadata  support   •  CRUD  services  begin  to  use  the  Web’s  coordination  support   •  But  the  Web  is  more  than  transport   HTTP   –  Transport,  plus   Headers   –  Metadata,  plus   Status  Codes   –  Fault  model,  plus   Uniform   Interface   –  Component  model,  plus   Caches,  proxies,   servers,  etc   –  Runtime  environment,  plus...  
  • 84. CRUD  Resource  Lifecycle   •  The  resource  is  created  with  POST   •  It’s  read  with  GET   •  And  updated  via  PUT   •  Finally  it’s  removed  using  DELETE  
  • 85. Richardson  Model  Level  2   •  Lots  of  URIs   •  Understands  HTTP!   •  No  hypermedia  
  • 86. Create  with  POST   POST /orders <order … /> 201 Created Location: …/1234 Ordering   Ordering   Client   400 Bad Request Service   500 Internal Error
  • 87. POST  Semantics   •  POST  creates  a  new  resource   •  But  the  server  decides  on  that  resource’s  URI   •  Common  human  Web  example:  posting  to  Web  log   –  Server  decides  URI  of  posting  and  any  comments  made   on  that  post   •  Programmatic  Web  example:  creating  a  new  employee   record   –  And  subsequently  adding  to  it  
  • 88. POST  Request   POST /orders HTTP/1.1 Verb,  path,  and  HTTP   Host: restbucks.example.com version   Content-Type:application/vnd.restbucks+xml Restbucks-­‐specific  XML   Content-Length: 225 content   <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> Content   <items> (again  Restbucks  XML)   <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> </items> </order>
  • 89. POST  Response   HTTP/1.1 201 Created Location: /orders/1234
  • 90. When  POST  goes  wrong   •  We  may  be  4xx  or  5xx  errors   –  Client  versus  server  problem   •  We  turn  to  GET!   •  Find  out  the  resource  states  first   –  Then  figure  out  how  to  make  forward  or  backward   progress   •  Then  solve  the  problem   –  May  involve  POSTing  again   –  May  involve  a  PUT  to  rectify  server-­‐side  resources  in-­‐ place  
  • 91. POST  Implementation  with  a  Servlet   protected void doPost(HttpServletRequest request, HttpServletResponse response) { try { Order order = extractOrderFromRequest(request); String internalOrderId = OrderDatabase.getDatabase().saveOrder(order); response.setHeader("Location", computeLocationHeader(request, internalOrderId)); response.setStatus(HttpServletResponse.SC_CREATED); } catch(Exception ex) { response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); } }
  • 92. Read  with  GET   GET /orders/1234 200 OK <order … /> Ordering   Ordering   Client   404 Not Found Service   500 Internal Error
  • 93. GET  Semantics   •  GET  retrieves  the  representation  of  a  resource   •  Should  be  idempotent   –  Shared  understanding  of  GET  semantics   –  Don’t  violate  that  understanding!   Library  of  congress   catalogue  incident!  
  • 94. GET  Exemplified   GET /orders/1234 HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com
  • 95. GET  Response   HTTP/1.1 200 OK Content-Length: 232 Content-Type: application/vnd.restbucks+xml Date: Wed, 19 Nov 2008 21:48:10 GMT <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> </items> <status>pending</pending> </order>
  • 96. When  GET  Goes  wrong   •  Simple!   –  Just  404  –  the  resource  is  no  longer  available   HTTP/1.1 404 Not Found Content-Type: application/vnd.restbucks+xml Content-Length: 952 Date: Sat, 20 Dec 2008 19:01:33 GMT •  Are  you  sure?   –  GET  again!   •  GET  is  safe  and  idempotent   –  Great  for  crash  recovery  scenarios!  
  • 97. Idempotent  Behaviour   •  An  action  with  no  side  affects   –  Comes  from  mathematics   •  In  practice  means  two  things:   –  A  safe  operation  is  one  which  changes  no  state  at  all   •  E.g.  HTTP  GET   –  An  idempotent  operation  is  one  which  updates  state  in   an  absolute  way   •  E.g.  x  =  4  rather  than  x  +=  2   •  Web-­‐friendly  systems  scale  because  of  safety   –  Caching!   •  And  are  fault  tolerant  because  of  idempotent  behaviour   –  Just  re-­‐try  in  failure  cases  
  • 98. GET  JAX-­‐RS  Implementation   @Path("/") public class OrderingService { @GET @Produces("application/xml") @Path("/{orderId}") public String getOrder(@PathParam("orderId") String orderId) { try { Order order = OrderDatabase.getDatabase().getOrder(orderId); if (order != null) { return xstream.toXML(order); } else { throw new WebApplicationException(404); } } catch (Exception e) { throw new WebApplicationException(500); } } // Remainder of implementation omitted for brevity }
  • 99. Update  with  PUT   PUT /orders/1234 <order … /> 200 OK 404 Not Found Ordering   Ordering   Client   Service   409 Conflict 500 Internal Error
  • 100. PUT  Semantics   •  PUT  creates  a  new  resource  but  the  client  decides  on  the   URI   –  Providing  the  server  logic  allows  it   •  Also  used  to  update  existing  resources  by  overwriting  them   in-­‐place   •  PUT  is  idempotent   –  Makes  absolute  changes   •  But  is  not  safe   –  It  changes  state!  
  • 101. PUT  Request   PUT /orders/1234 HTTP/1.1 Host: restbucks.com Content-Type: application/xml Content-Length: 386 <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <milk>whole</milk> <name>latte</name> <quantity>2</quantity> <size>small</size> </item> <item> <milk>whole</milk> Updated  content     <name>cappuccino</name> <quantity>1</quantity> <size>large</size> </item> </items> <status>preparing</preparing> </order>
  • 102. PUT  Response   HTTP/1.1 200 OK Date: Sun, 30 Nov 2008 21:47:34 GMT Content-Length: 0 Minimalist  response  contains  no   en8ty  body  
  • 103. When  PUT  goes  wrong   •  If  we  get  5xx  error,  or   HTTP/1.1 409 Conflict Date: Sun, 21 Dec 2008 16:43:07 GMT some  4xx  errors  simply   Content-Length:382 PUT  again!   <order xmlns="http://schemas.restbucks.com/ order"> <location>takeAway</location> –  PUT  is  idempotent   <items> <item> •  If  we  get  errors   <milk>whole</milk> <name>latte</name> indicating  incompatible   <quantity>2</quantity> <size>small</size> states  (409,  417)  then  do   </item> <item> some  forward/backward   <milk>whole</milk> <name>cappuccino</name> compensating  work   <quantity>1</quantity> <size>large</size> –  And  maybe  PUT  again   </item> </items> <status>served</status> </order>
  • 104. WCF  Implementation  for  PUT   [ServiceContract] public interface IOrderingService { [OperationContract] [WebInvoke(Method = "PUT", UriTemplate = "/orders/ {orderId}")] void UpdateOrder(string orderId, Order order); // … }
  • 105. WCF  Serializable  Types   [DataContract(Namespace = "http://schemas.restbucks.com/order", Name = "order")] public class Order { [DataMember(Name = "location")] public Location ConsumeLocation { get { return location; } set { location = value; } } [DataMember(Name = "items")] public List<Item> Items { get { return items; } set { items = value; } } [DataMember(Name = "status")] public Status OrderStatus { get { return status; } set { status = value; } } // … }
  • 106. Remove  with  DELETE   DELETE /orders/1234 200 OK 404 Not Found Ordering   Ordering   Client   Service   405 Method Not Allowed 500 Service Unavailable
  • 107. DELETE  Semantics   This  is  important  for   •  Stop  the  resource  from  being  accessible   decoupling   implementa8on  details   –  Logical  delete,  not  necessarily  physical   from  resources   •  Request   DELETE /orders/1234 HTTP/1.1 Host: restbucks.com •  Response   HTTP/1.1 200 OK Content-Length: 0 Date: Tue, 16 Dec 2008 17:40:11 GMT
  • 108. When  DELETE  goes  wrong   •  Simple  case,  DELETE  again!   –  Delete  is  idempotent!   –  DELETE  once,  DELETE  10  times  has  the  same  effect:  one   deletion   HTTP/1.1 404 Not Found Content-Length: 0 Date: Tue, 16 Dec 2008 17:42:12 GMT
  • 109. When  DELETE  goes  Really  Wrong   •  Some  4xx  responses   HTTP/1.1 409 Conflict Content-Length: 379 indicate  that  deletion   Date: Tue, 16 Dec 2008 17:53:09 GMT isn’t  possible   <order xmlns="http://schemas.restbucks.com/ order"> <location>takeAway</location> –  The  state  of  the  resource   <items> isn’t  compatible   <item> <name>latte</name> –  Try  forward/backward   <milk>whole</milk> <size>small</size> compensation  instead   <quantity>2</quantity> </item> <item> <name>cappuccino</name> <milk>skim</milk> <size>large</size> <quantity>1</quantity> </item> </items> Can’t  delete  an   <status>served</status> </order> order  that’s   already  served  
  • 110. CRUD  does  not  mean  Worthless  
  • 111. CRUD  is  Good?   •  CRUD  is  good   –  But  it’s  not  great   •  CRUD-­‐style  services  use  some  HTTP  features   •  But  the  application  model  is  limited   –  Suits  database-­‐style  applications   –  Hence  frameworks  like  Microsoft’s  Astoria   •  CRUD  has  limitations   –  CRUD  ignores  hypermedia   –  CRUD  encourages  tight  coupling  through  URI  templates   –  CRUD  encourages  server  and  client  to  collude   •  The  Web  supports  more  sophisticated  patterns  than  CRUD!  
  • 113. Microformats   •  Microformats  are  an  example  of  little  “s”  semantics   •  Innovation  at  the  edges  of  the  Web   –  Not  by  some  central  design  authority  (e.g.  W3C)   •  Started  by  embedding  machine-­‐processable  elements  in   Web  pages   –  E.g.  Calendar  information,  contact  information,  etc   –  Using  existing  HTML  features  like  class,  rel,  etc  
  • 114. Semantic  versus  semantic   •  Semantic  Web  is  top-­‐down   –  Driven  by  the  W3C  with  extensive  array  of  technology,   standards,  committees,  etc   –  Has  not  currently  proven  as  scalable  as  the  visionaries   hoped   •  RDF  triples  have  been  harvested  and  processed  in   private  databases   •  Microformats  are  bottom-­‐up   –  Little  formal  organisation,  no  guarantee  of   interoperability   –  Popular  formats  tend  to  be  adopted  (e.g.  hCard)   –  Easy  to  use  and  extend  for  our  systems   –  Trivial  to  integrate  into  current  and  future   programmatic  Web  systems  
  • 115. Microformats  and  Resources   •  Use  Microformats  to  structure  resources  where  formats   exist   –  I.e.  Use  hCard  for  contacts,  hCalendar  for  data   •  Create  your  own  formats  (sparingly)  in  other  places   –  Annotating  links  is  a  good  start   –  <link rel="withdraw.cash" .../> –  <link rel="service.post" type="application/atom+xml" href="{post-uri}" title="some title"> •  The  rel  attribute  describes  the  semantics  of  the  referred   resource  
  • 117. Media  Types  Rule!   •  The  Web’s  contracts  are  expressed  in  terms  of  media  types   and  link  relations   –  If  you  know  the  type,  you  can  process  the  content   •  Some  types  are  special  because  they  work  in  harmony  with   the  Web   –  We  call  these  “hypermedia  formats”  
  • 118. (Hyper)  media  types   General   Standardised  media  type   Processing  model   Compose  application-­‐ specific  behaviours  on   Hypermedia  controls   (links  and  forms)   top  of  the  handling  of   standardised  media  types   Supported  operations   (methods,  headers  and   status  codes)   Representation  formats   (may  include  schemas)   Specific  
  • 119. Other  Resource  Representations   •  Remember,  XML  is  not  the  only  way  a  resource  can  be   serialised   –  Remember  the  Web  is  based  on  REpresentational  State   Transfer   •  The  choice  of  representation  is  left  to  the  implementer   –  Can  be  a  standard  registered  media  type   –  Or  something  else   •  But  there  is  a  division  on  the  Web  between  two  families   –  Hypermedia  formats   •  Formats  which  host  URIs  and  links   –  Regular  formats   •  Which  don’t  
  • 120. Plain  Old  XML  is  not  Hypermedia  Friendly   HTTP/1.1 200 OK Content-Length: 227 Content-Type: application/xml Date: Wed, 19 Nov 2008 21:48:10 GMT <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <items> <item> <name>latte</name> Where  are  the  links?   <quantity>1</quantity> Where’s  the  protocol?   <milk>whole</milk> <size>small</size> </item> </items> <status>pending</pending> </order>
  • 121. So  what?   •  How  do  you  know  the  next  thing  to  do?   •  How  do  you  know  the  resources  you’re  meant  to  interact   with  next?   •  In  short,  how  do  you  know  the  service’s  protocol?   –  Turn  to  WADL?  Yuck!   –  Read  the  documentation?  Come  on!   –  URI  Templates?  Tight  Coupling!  
  • 122. URI  Templates  are  NOT  a  Hypermedia  Substitute   •  Often  URI  templates  are  used  to  advertise  all  resources  a   service  hosts   –  Do  we  really  need  to  advertise  them  all?   •  This  is  verbose   •  This  is  out-­‐of-­‐band  communication   •  This  encourages  tight-­‐coupling  to  resources  through  their   URI  template   •  This  has  the  opportunity  to  cause  trouble!   –  Knowledge  of  “deep”  URIs  is  baked  into  consuming   programs   –  Services  encapsulation  is  weak  and  consumers  will   program  to  it   –  Service  will  change  its  implementation  and  break   consumers  
  • 123. Bad  Ideas  with  URI  Templates   •  Imagine  we’re  created  an  order,  what  next?   •  We  could  share  this  URI  template:   –  http://restbucks.com/payment/{order_id} •  The  order_id  field  should  match  the  order  ID  that  came   from  the  restbucks  service   –  Sounds  great!   •  But  what  if  Restbucks  outsources  payment?   –  Change  the  URI  for  payments,  break  the  template,   break  consumers!   –  D’oh!   •  Be  careful  what  you  share!  
  • 124. Better  Ideas  for  URI  Templates:  Entry  Points   •  Imagine  that  we  have  a  well-­‐known  entry  point  to  our   service   –  Which  corresponds  to  a  starting  point  for  a  protocol   •  Why  not  advertise  that  with  a  URI  template?   •  For  example:   –  http://restbucks.com/signIn/{store_id}/ {barista_id} •  Changes  infrequently   •  Is  important  to  Restbucks   •  Is  transparent,  and  easy  to  bind  to    
  • 125. Better  Ideas  for  URI  Templates:  Documentation!   •  Services  tend  to  support   / Internal  URI   lots  of  resources   payment/ Templates   {order_id}   External  URI   •  We  need  a  shorthand  for   Templates   talking  about  a  large   number  of  resources  easily   •  We  can  use  a  URI  template   /{store}/ /order/ for  each  “type”  of   orders   {order_id}   resource  that  a  service  (or   services)  supports   •  But  we  don’t  share  this   information  with  others   /order/ –  Don’t  violate  encapsulation!   {order_id}  
  • 126. application/xml  is  not  the  media  type  you’re  looking  for   •  Remember  that  HTTP  is  an  application  protocol   –  Headers  and  representations  are  intertwined   –  Headers  set  processing  context  for  representations   •  Remember  that  application/xml  has  a  particular   processing  model   –  Which  doesn’t  include  understanding  the  semantics  of   links   •  Remember  if  a  representation  is  declared  in  the  Content- Type  header,  you  must  treat  it  that  way   –  HTTP  is  an  application  protocol  –  did  you  forget  already?      •  We  need  real  hypermedia  formats!  
  • 127. Hypermedia  Formats   •  Standard   –  Wide  “reach”   –  Software  agents  already  know  how  to  process  them   –  But  sometimes  need  to  be  shoe-­‐horned   •  Self-­‐created   –  Can  craft  specifically  for  domain   –  Semantically  rich   –  But  lack  reach  
  • 128. Two  Common  Hypermedia  Formats:  XHTML  and  ATOM   •  Both  are  commonplace  today   •  Both  are  hypermedia  formats   –  They  contain  links   •  Both  have  a  processing  model  that  explicitly  supports  links   •  Which  means  both  can  describe  protocols…  
  • 129. XHTML   •  XHTML  is  just  HTML  that  is  also  XML   Default  XML   •  For  example:   namespace   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:r="http://restbucks.org">XML   Other   namespaces   <head> <title> XHTML Example </title> </head> <body> <p> ...
  • 130. What’s  the  big  deal  with  XHTML?   •  It  does  two  interesting  things:   1.  It  gives  us  document  structure   2.  It  gives  us  links   •  So?   1.  We  can  understand  the  format  of  those  resources   2.  We  can  discover  other  resources!   •  How?   1.  Follow  the  links!   2.  Encode  the  resource  representation  as  “normal”  XML   in  your  XHTML  documents   •  Contrast  this  with  the  Atom  and  APP  approach...similar!  
  • 131. XHTML  in  Action   <html xmlns="http://www.w3.org/1999/xhtml"> <body> <div class="order"> <p class="location">takeAway</p> <ul class="items"> Business  data   <li class="item"> <p class="name">latte</p> <p class="quantity">1</p> <p class="milk">whole</p> “Hypermedia   <p class="size">small</p> Control”   </li> </ul> <a href="http://restbucks.com/payment/ 1234" rel="payment">payment</a> </div> </body> </html>
  • 132. application/xhtml+xml •  Can  ask  which  verb  the  resource  at  the  end  of  the  link   supports   –  Via  HTTP  OPTIONS   •  No  easy  way  to  tell  what  each  link  actually  does   –  Does  it  buy  the  music?   –  Does  it  give  you  lyrics?   –  Does  it  vote  for  a  favourite  album?   •  We  lack  semantic  understanding  of  the  linkspace  and   resources   –  But  we  have  microformats  for  that  semantic  stuff!   •  Importantly  XHTML  is  a  hypermedia  format   –  It  contains  hypermedia  controls  that  can  be  used  to   describe  protocols!  
  • 133. Atom  Syndication  Format   •  We’ll  study  this  in  more   HTTP/1.1 200 OK Content-Length: 342 depth  later,  but  for   Content-Type: application/atom+xml Date: Sun, 22 Mar 2009 17:04:10 GMT now…   <entry xmlns="http://www.w3.org/2005/ •  The  application/atom Atom"> +xml  media  type  is   <title>Order 1234</title> <link rel="payment" href="http:// hypermedia  aware   restbucks.com/payment/1234"/> <link rel="special-offer" href="http://restbucks.com/offers/ •  You  should  expect  links   freeCookie"/> when  processing  such   <id>http://restbucks.com/order/ 1234</id> representations   other  resources,   <updated>2009-03-22T16:57:02Z</ Links  to   updated> •  And  be  prepared  to  drotocol   </entry> a  nascent  p o   <summary>1x Cafe Latte</summary> things  with  them!  
  • 134. application/atom+xml •  No  easy  way  to  tell  what  each  link  actually  does   –  But  look  at  the  way  the  rel  attribute  is  being  used   –  Can  we  inject  semantics  there?   •  Atom  is  a  hypermedia  format   –  Both  feeds  and  entries  contains  hypermedia  controls   that  can  describe  protocols  
  • 135. application/vnd.restbucks+xml •  What  a  mouthful!   •  The  vnd  namespace  is  for  proprietary  media  types   –  As  opposed  to  the  IANA-­‐registered  ones   •  Restbucks  own  XML  is  a  hybrid   –  We  use  plain  old  XML  to  convey  information   –  And  Atom  link  elements  to  convey  protocol   •  This  is  important,  since  it  allows  us  to  create  RESTful,   hypermedia  aware  services  
  • 136. Hypermedia  and  RESTful   Services  
  • 137. Revisiting  Resource  Lifetime   •  On  the  Web,  the  lifecycle  of  a  single  resource  is  more  than:   –  Creation   –  Updating   –  Reading   –  Deleting   •  Can  also  get  metadata   –  About  the  resource   –  About  its  (subset  of)  the  verbs  it  understands   •  And  as  we  see,  resources  tell  us  about  other  resources  we   might  want  to  interact  with…  
  • 138. Links   •  Connectedness  is  good  in  Web-­‐based  systems   •  Resource  representations  can  contain  other  URIs   •  Links  act  as  state  transitions   •  Application  (conversation)  state  is  captured  in  terms  of   these  states  
  • 139. Describing  Contracts  with  Links   •  The  value  of  the  Web  is  its  “linked-­‐ness”   –  Links  on  a  Web  page  constitute  a  contractfor  page   traversals   •  The  same  is  true  of  the  programmatic  Web   •  Use  Links  to  describe  state  transitions  in  programmatic   Web  services   –  By  navigating  resources  you  change  application  state   •  Hypermedia  formats  support  this   –  Allow  us  to  describe  higher-­‐order  protocols  which  sit   comfortably  atop  HTTP   –  Hence  application/vnd.restbucks+xml
  • 140. Links  are  State  Transitions  
  • 141. Links  as  APIs   <confirm xmlns="..."> •  Following  a  link  causes   <link rel="payment" href="https://pay" an  action  to  occur   type="application/xml"/> •  This  is  the  start  of  a   <link rel="postpone" href="https://wishlist" state  machine!   type="application/xml"/> •  Links  lead  to  other   </confirm> resources  which  also   have  links   •  Can  make  this  stronger   with  semantics   –  Microformats  
  • 142. We  have  a  framework!   •  The  Web  gives  us  a  processing  and  metadata  model   –  Verbs  and  status  codes   –  Headers   •  Gives  us  metadata  contracts  or  Web  “APIs”   –  URI  Templates   –  Links   •  Strengthened  with  semantics   –  Little  “s”  
  • 144. Richardson  Model  Level  3   •  Lots  of  URIs  that   address  resources   •  Embraces  HTTP  as  an   application  protocol   •  Resource   representations  and   formats  identify  other   resources   –  Hypermedia  at  last!  
  • 145. Structural  versus  Protocol   •  “Structural”  REST   –  Domain  model  broken  up  with  URIs   –  Lazy  loading,  caching  over  the  network   –  Proliferation  of  media  types?   •  “Protocol”  REST   –  Focus  on  media  types  as  contracts   –  Protocol  state  transitions   –  DAPs  –  Domain  Application  Protocols  
  • 146. Workflow  and  MOM   •  With  Web  Services  we   exchange  messages  with   the  service   •  Resource  state  is  hidden   from  view   •  Conversation  state  is  all   we  know   –  Advertise  it  with  SSDL,   BPEL   •  Uniform  interface,  roles   defined  by  SOAP   –  No  “operations”  
  • 147. Hypermedia  Describes  Protocols!   •  Links  declare  next  valid  steps   •  Following  links  and  interacting  with  resources  changes   application  state   •  Media  types  with  links  define  contracts   –  Media  type  defines  processing  model   –  Links  (with  microformats)  describe  state  transitions   •  Don’t  need  a  static  contract  description   –  No  WSDL,  no  WADL   •  This  is  HATEOAS!   •  So  let’s  see  how  we  order  a  coffee  at  Restbucks.com…   –  Based  on:    http://www.infoq.com/articles/webber-­‐rest-­‐workflow  
  • 148. Hypermedia  Protocols  Span  Services   Unfollowed  Link   Followed  Link  
  • 149. Workflow   •  How  does  a  typical  enterprise  workflow  look  when  it’s   implemented  in  a  Web-­‐friendly  way?   •  Let’s  take  Restbucks  ordering  servas  an  example,  the   happy  path  is:   –  Make  selection   •  Add  any  specialities   –  Pay   –  Wait  for  a  while   –  Collect  drink  
  • 150. Static  Interface  and  State  Transitions   3'42/&1'&2 9:;<2 !"#$%%&'()*+,-(.,/0%/&1'&2 5,&'6)'2&'(/+&,'72 82 +#16)'2/&1'&25/3@A2BC2()6)'2B(2 9:;<2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 6)2D#6A0'3)2'E#',)'1F72 =2 /&1'&2,63,'@@'125/3@A2BC2 GHIH<H2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 ()6)'2B(26)2D#6A0'3)2 >2 'E#',)'1F72 9J<2 !"#($%%&'()*+,-(.,/0%#6A0'3)%8=>?2 96A0'3)26,,'#)'12 ?2 M6&B()62#&'#6&'12/&1'&2 N2 /&1'&2&','BK'125/3@A2BC2()6)'2 GHIH<H2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 B(26)2D&'61AF72 L2 &')+&32@6)'()2&'#&'('3)6O/32 PH<2 !"#$%%&'()*+,-(.,/0%/&1'&%8=>?2 /C2)!'2&'(/+&,'2 4( !,%!",-&.( 1( ,%"+#( 2( */$!0%'%+( =2 5( 3( !"#$%&'( %)!%*'%+( 6( *"&*%00%+(
  • 151. Place  an  Order   •  POST  to  a  well-­‐known  URI   –  http://restbucks.com/order   Restbucks  Service   Client  
  • 152. Placing  an  Order   •  Request   POST /order HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 278 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> </rb:order>
  • 153. Placing  an  Order   •  Response   HTTP/1.1 201 Created Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link uri="http://restbucks.com/order/f932f92d" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/ f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
  • 154. Confirm  the  Order   •  GET  from  the  rel=“latest”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
  • 155. Confirm  the  Order   •  Request   GET /order/f932f92d HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive
  • 156. Confirm  the  Order   •  Response   HTTP/1.1 200 OK Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link uri="http://restbucks.com/order/f932f92d" mediaType="application/vnd.restbucks+xml" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>latte</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
  • 157. Change  the  Order   •  POST  new  order  to  service-­‐generated  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
  • 158. POST?  Not  PUT?   •  PUT  expects  the  whole  resource  state  to  be  presented  in   the  request   –  But  our  clients  aren’t  responsible  for  generating   hypermedia  links   •  PATCH  would  be  better   –  It  allows  us  to  send  diffs,  but  isn’t  part  of  the  standard   yet   •  So  POST  is  our  only  option   –  Compare  this  to  our  CRUD  protocol  in  SOA  321  
  • 159. Change  the  Order   •  Request   POST order/f932f92d HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 278 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> </rb:order>
  • 160. Change  the  Order   •  Response   HTTP/1.1 200 OK Location: http://restbucks.com/order/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 828 Date: Sun, 06 Sep 2009 06:52:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="cancel"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/payment/f932f92d" rel="payment"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="update"/> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>unpaid</rb:status> </rb:order>
  • 161. Statelessness   •  Remember  interactions  with  resources  are  stateless   •  The  resource  “forgets”  about  you  while  you’re  not  directly   interacting  with  it     •  Which  means  race  conditions  are  possible   •  Use  If-Unmodified-Since  on  a  timestamp  to  make   sure   –  Or  use  If-Match  and  an  ETag •  You’ll  get  a  412 PreconditionFailed  if  you  lost  the   race   –  But  you’ll  avoid  potentially  putting  the  resource  into   some  inconsistent  state  
  • 162. Warning:  Don’t  be  Slow!   •  Can  only  make  changes  until  someone  actually  makes  your   drink   –  You’re  safe  if  you  use  If-Unmodified-Since  or  If- Match   –  But  resource  state  can  change  without  you!     Request    Response   POST /order/1234 HTTP 1.1 Host: restbucks.com 409 Conflict ... Too  slow!  Someone  else  has   changed  the  state  of  my  order    Request    Response   OPTIONS /order/1234 HTTP 1.1 Allow: GET Host: restbucks.com
  • 163. What  if  we  want  to  cancel?   •  DELETE  order  at  order  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
  • 164. What  if  we  want  to  cancel?   •  Request   DELETE /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Date: Sun, 06 Sep 2009 06:53:22 GMT
  • 165. Order  Payment   •  PUT  to  service-­‐generated  payment  URI   –  http://restbucks.com/payment/f932f92d   Restbucks  Service   Client  
  • 166. Why  PUT  this  time?   •  It’s  idempotent   –  Safe  to  repeat  in  the  event  of  failures   •  For  all  $  transactions,  prefer  idempotent  verbs  
  • 167. Order  Payment   •  Request   PUT /payment/f932f92d HTTP/1.1 Content-Type: application/vnd.restbucks+xml Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive Content-Length: 269 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <payment xmlns="http://schemas.restbucks.com"> <amount>2.0</amount> <cardholderName>Michael Farraday</cardholderName> <cardNumber>11223344</cardNumber> <expiryMonth>12</expiryMonth> <expiryYear>12</expiryYear> </payment>
  • 168. Order  Payment   •  Response   HTTP/1.1 201 Created Location: http://restbucks.com/payment/f932f92d Content-Type: application/vnd.restbucks+xml Content-Length: 547 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:payment xmlns="http://schemas.restbucks.com/dap" xmlns:rb="http:// schemas.restbucks.com"> <link rel="latest" uri="http://restbucks.com/order/f932f92d" /> <link rel="receipt" uri="http://restbucks.com/receipt/f932f92d" /> <rb:amount>2.0</rb:amount> <rb:cardholderName>Michael Farraday</rb:cardholderName> <rb:cardNumber>11223344</rb:cardNumber> <rb:expiryMonth>12</rb:expiryMonth> <rb:expiryYear>12</rb:expiryYear> </rb:payment>
  • 169. What  if  we  want  to  cancel  now?   •  Request   DELETE /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive •  Response   HTTP/1.1 405 Method Not Allowed Allow: GET Content-Type: application/vnd.restbucks+xml Content-Length: 0 Date: Sun, 06 Sep 2009 07:43:29 GMT
  • 170. Grab  a  Receipt   •  GET  service-­‐generated  receipt  URI   –  http://restbucks.com/receipt/f932f92d   Restbucks  Service   Client  
  • 171. Grab  a  Receipt   •  Request   GET /receipt/f932f92d HTTP/1.1 Accept: application/vnd.restbucks+xml Host: restbucks.com Connection: keep-alive
  • 172. Grab  a  Receipt   •  Request   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 332 Date: Sun, 06 Sep 2009 06:51:22 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:receipt xmlns="http://schemas.restbucks.com/dap" xmlns:rb="http://schemas.restbucks.com"> <link rel="order" uri="http://restbucks.com/order/f932f92d" /> <rb:amount>2.0</rb:amount> <rb:paid>2009-09-06T16:51:22.814+10:00</rb:paid> </rb:receipt>
  • 173. Complete    the  Order   •  GET  from  the  rel=“order”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
  • 174. Complete  the  Order   •  Request   GET /order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive
  • 175. Complete  the  Order   •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 455 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <dap:link mediaType="application/vnd.restbucks+xml" uri="http://restbucks.com/order/f932f92d" rel="latest"/> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>ready</rb:status> </rb:order>
  • 176. Complete  the  Order   •  DELETE  order  at  rel=“latest”  URI   –  http://restbucks.com/order/f932f92d   Restbucks  Service   Client  
  • 177. Complete  the  Order   •  Request   DELETE/order/f932f92d HTTP/1.1 Host: restbucks.com Connection: keep-alive
  • 178. Complete  the  Order   •  Response   HTTP/1.1 200 OK Content-Type: application/vnd.restbucks+xml Content-Length: 360 Date: Sun, 06 Sep 2009 23:01:10 GMT <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rb:order xmlns:rb="http://schemas.restbucks.com" xmlns:dap="http://schemas.restbucks.com/dap"> <rb:item> <rb:milk>semi</rb:milk> <rb:size>large</rb:size> <rb:drink>cappuccino</rb:drink> </rb:item> <rb:location>takeaway</rb:location> <rb:cost>2.0</rb:cost> <rb:status>taken</rb:status> </rb:order>
  • 180. What  did  we  learn  from  Restbucks?   •  HTTP  has  a  header/status  combination  for  every  occasion   •  APIs  are  expressed  in  terms  of  links,  and  links  are  great!   –  APP-­‐esque  APIs   •  APIs  can  also  be  constructed  with  URI  templates  and   inference   –  But  beware  tight  coupling  outside  of  CRUD  services!   •  XML  is  fine,  but  we  could  also  use  formats  like  Atom,  JSON   or  even  default  to  XHTML  as  a  sensible  middle  ground   •  State  machines  (defined  by  links)  are  important   –  Just  as  in  Web  Services…  
  • 181. Tech  Interlude     Design  Exercise:  Adding  HTTP  Idioms  to  Restbucks
  • 182. Ordering  and  Payments  Protocol  Weaknesses   •  Lacks  HTTP  idioms   –  ETags   –  Cache  metadata   –  Etc   •  No  circuit  breaker   –  E.g.  413  at  busy  times  
  • 183. Ordering  and  Payments  Protocol  Retrospective   •  Scenario:   –  The  system  is  in  production,  and  has  delivered  revenue   successfully.  What  design  decisions  should  we  change   for  our  next  version?   •  Four  categories:   –  Introduce   •  New  things  we  should  do   –  Do  more  of   •  Good  things  we  should  do  more  of   –  Do  less  of   •  Poor  things  we  should  do  less  of   –  Remove   •  Stupid  things  we  should  cease  
  • 184. Tech  Interlude   Hypermedia  Design  Walkthrough  
  • 185. Problem   •  What’s  the  solution  for  integrating  ordering  and  barista-­‐ing   systems?   •  Guidelines:   –  Design  applications  in  terms  of  application  protocol   state  machines     –  Implement  them  in  terms  of  resource  lifecycles   –  Advertise/document  them  using  media  types,  link   relation  values  and  HTTP  idioms  
  • 186. Fulfillment  domain  application  protocol   Awai8ng   fulfillment   barista  accepts   add  deliverable   Correc8ng   Fulfilling   order  modified   drinks  ==  line  items   remove  drink   Fulfilled  
  • 187. Resource  lifecycles   1   *   Order   Drink   Created   1   1   Created   Drinks   Fulfilling   Corrected   Drinks  contains   Discarded   items  not  in   order   Started   Ready   Consumed   Requires   Preparing   amending   Completed  
  • 188. Barista  reviews  outstanding  orders   GET /orders HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <orders xmlns="http://schemas.restbucks.com/orders"> <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>created</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order> ... </orders>
  • 189. Barista  reviews  drinks  status  of  first  order   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "1" <drinks xmlns="http://schemas.restbucks.com/drinks"> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>started</status> </drinks>
  • 190. Barista  creates  latte   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "1" <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/1 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink>
  • 191. Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "2" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
  • 192. Barista  creates  first  cappuccino   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "2" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/2 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink>
  • 193. Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "3" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
  • 194. Cashier  reviews  order  status   GET /orders/123 HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>latte</name> <quantity>1</quantity> <milk>whole</milk> <size>small</size> </item> <item> <name>cappuccino</name> <quantity>1</quantity> <milk>whole</milk> <size>large</size> </item> <status>fulfilling</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order>
  • 195. Cashier  changes  order   POST /orders/123 HTTP/1.1 Host: restbucks.com Content-Type: application/vnd.restbucks+xml Content-Length: ... <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> HTTP/1.1 200 OK </order> Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>fulfilling</status> <link rel="edit" type="application/vnd.restbucks+xml" href="http://restbucks.com/orders/123"/> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> </order>
  • 196. Barista  continues  making  drinks   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "3" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 412 Precondition Failed
  • 197. Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "4" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <unwanted/> <name>latte</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/1"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>requires-amending</status> </drinks>
  • 198. Barista  discards  latte   DELETE /orders/123/drinks/1 Host: internal.restbucks.com HTTP/1.1 204 No Content Date: ...
  • 199. Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "5" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <unwanted/> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>preparing</status> </drinks>
  • 200. Barista  creates  another  cappuccino   POST /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com If-Match: "5" <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> </drink> HTTP/1.1 201 Created Location: http://internal.restbucks.com/orders/123/drinks/3 Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/3"/> </drink>
  • 201. Barista  reviews  drinks  status   GET /orders/123/drinks HTTP/1.1 Host: internal.restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml ETag: "6" <drinks xmlns="http://schemas.restbucks.com/drinks"> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/2"/> </drink> <drink xmlns="http://schemas.restbucks.com/drink"> <name>cappuccino</name> <milk>whole</milk> <size>small</size> <link rel="edit" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks/3"/> </drink> <link rel="http://relations.restbucks.com/fulfillment" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123/drinks"/> <link rel="http://relations.restbucks.com/order" type="application/vnd.restbucks+xml" href="http://internal.restbucks.com/orders/123"/> <status>completed</status> </drinks>
  • 202. Cashier  reviews  order  status   GET /orders/123 HTTP/1.1 Host: restbucks.com HTTP/1.1 200 OK Date: ... Content-Length: ... Content-Type: application/vnd.restbucks+xml <order xmlns="http://schemas.restbucks.com/order"> <location>takeAway</location> <item> <name>cappuccino</name> <quantity>2</quantity> <milk>whole</milk> <size>small</size> </item> <status>ready</status> </order>
  • 203. The  documented  protocol   !"#$%&'()"#& !""#$%%&'(")*+,(-+./%.&0'&(1 *+,)-&#%'+& 2##34+5"4.6%760-&'(")*+,(89/31 .+/(0$1+/& :&0'&(1 !""#$%%(+!'/5(-&'(")*+,(-+./%.&0'&(1 ;("5"*(<1'3'/'6"1 4604+5"'(1"!'1.&0'&1("5"*(-1 =53*'(15&'$1+&'5"'0>1 ?*3?43346@>1&'50A-1 :&0'&1 !""#$%%(+!'/5(-&'(")*+,(-+./%.&0'&1 1 B&46,(1 !""#$%%(+!'/5(-&'(")*+,(-+./%0&46,(1 ;("5"*(<1'3'/'6"1 4604+5"'(1"!'1#&.@&'((1.?1 "!'1#&'#5&'010&46,(-1 =53*'(15&'$1("5&"'0>1 &'C*4&'(D5/'6046@>1 #&'#5&46@>1+./#3'"'0-1 B&46,1 !""#$%%(+!'/5(-&'(")*+,(-+./%0&46,1 1 1 E*3?43/'6"14(1+./#3'"'1F!'61"!'1.&0'&1("5"*(14(1&'50A>15601"!'10&46,(1("5"*(14(1 +./#3'"'0-1 2)"3&$+4-#)("/& '04"1 G'?'&(1".151&'(.*&+'1"!5"1+561)'1 *('01".1'04"1"!'1346,H(1+.6"'9"-1I.1 '04"1561.&0'&>1J:KI1516'F1.&0'&1".1 "!'1'04"1346,-1I.1&'/.7'1510&46,1 ?&./15134("1.?10&46,(>1BLMLIL1"!'1 346,'01&'(.*&+'-1 !""#$%%&'35"4.6(-&'(")*+,(-+./%?*3?433/'6"1 B&46,(1"!5"1?*3?431561.&0'&-1I!'1 346,'01&'(.*&+'14(15++./#564'01)A1 561LI5@-1N&'5"46@16'F10&46,(1 (!.*301)'10.6'1)A1+.604"4.6533A1 J:KI46@1".1"!'1346,'01&'(.*&+'-1O?1 "!'134("1.?10&46,(1&'C*4&'(15/'6046@1 )'?.&'1516'F10&46,1+561)'1500'0>1 "!'1('&74+'1&'(#.60(1F4"!1PQR1 J&'+.604"4.61E543'0-1 !""#$%%&'35"4.6(-&'(")*+,(-+./%.&0'&1 I!'1.&0'&1".1F!4+!15134("1.?10&46,(1 )'3.6@(-1 1
  • 207. Statelessness   •  Every  action  happens  in  isolation   –  This  is  a  good  thing!   •  In  between  requests  the  server  knows  nothing  about  you   –  Excepting  any  state  changes  you  caused  when  you  last   interacted  with  it.   •  Keeps  the  interaction  protocol  simpler   –  Makes  recovery,  scalability,  failover  much  simpler  too   –  Avoid  cookies!  
  • 208. Application  vs  Resource  State   •  Useful  services  hold  persistent  data  –  Resource  state   –  Resources  are  buckets  of  state   –  What  use  is  Google  without  state?   •  Brittle  implementations  have  application  state   –  They  support  long-­‐lived  conversations   –  No  failure  isolation   –  Poor  crash  recovery   –  Hard  to  scale,  hard  to  do  fail-­‐over  fault  tolerance   •  Recall  stateless  Web  Services  –  same  applies  in  the  Web   too!  
  • 209. Stateful  Example   What  if  there’s  a  failure   here?  
  • 210. Stateful  Failure   “Grandmother”   An8pa*ern  
  • 211. Stateless  System  Tolerates  Intermittent  Failures  
  • 212. Scaling  Horizontally   •  Web  farms  have  delivered  horizontal  scaling  for  years   –  Though  they  sometimes  do  clever  things  with  session   affinity  to  support  cookie-­‐based  sessions   •  In  the  programmatic  Web,  statelessness  enables  scalability   –  Just  like  in  the  Web  Services  world  
  • 213. Scalable  Deployment  Configuration   •  Deploy  services  onto  many  servers   •  Services  are  stateless   –  No  cookies!   •  Servers  share  only  back-­‐end  data  
  • 214. Scaling  Vertically…without  servers   •  The  most  expensive  round-­‐trip:   –  From  client   –  Across  network   –  Through  servers   –  Across  network  again   –  To  database   –  And  all  the  way  back!   •  The  Web  tries  to  short-­‐circuit  this   –  By  determining  early  if  there  is  any  actual  work  to  do!   –  And  by  caching  
  • 215. Caching   •  Caching  is  about  scaling  vertically   –  As  opposed  to  horizontally   •  Making  a  single  service  run  faster   –  Rather  than  getting  higher  overall  throughput   •  In  the  programmatic  Web  it’s  about  reducing  load  on   servers   –  And  reducing  latency  for  clients  
  • 216. Caching  in  a  Scalable  Deployment   •  Cache  (reverse  proxy)  in  front  of  server  farm   –  Avoid  hitting  the  server   •  Proxy  at  client  domain   –  Avoid  leaving  the  LAN   •  Local  cache  with  client   –  Avoid  using  the  network  
  • 217. Web-­‐Inspired  Architecture   Front  End   Caching   Back-­‐end   Database  
  • 218. Characteristics   Incoming  informa8on   pushes  through   Scaling-­‐out  is   easy   Cache  replicates   naturally   Single  source  of   truth  
  • 220. Freshness   No  need  to   interact  with   front-­‐end  
  • 221. Validation   Condi8onal  GET  
  • 223. Scale  the  cache  out!   Cache  peering  
  • 225. Being  workshy  is  a  good  thing!   •  Provide  guard  clauses  in  requests  so  that  servers  can   determine  easily  if  there’s  any  work  to  be  done   –  Caches  too   •  Use  headers:   –  If-Modified-Since –  If-None-Match   –  And  friends   •  Web  infrastructure  uses  these  to  determine  if  its  worth   performing  the  request   –  And  often  it  isn’t   –  So  an  existing  representation  can  be  returned  
  • 226. Conditional  GET  Avoids  Work!   ETag  is  an  opaque   iden8fier  for  specific   •  Bandwidth-­‐saving  pattern   resource  state   •  Requires  client  and  server  to  work  together   •  Server  sends  Last-Modified  and/or  ETag  headers  with   representations   •  Client  sends  back  those  values  when  it  interacts  with   resource  in  If-Modified-Since  and/or  If-None- Match  headers   •  Server  responds  with  a  200  an  empty  body  if  there  have   been  no  updates  to  that  resource  state   •  Or  gives  a  new  resource  representation  (with  new  Last- Modified  and/or  ETag  headers)  
  • 227. Retrieving  a  Resource  Representation   •  Request   GET /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2009-01-08T15:00:34Z If-None-Match: aabd653b-65d0-74da-bc63-4bca-ba3ef3f50432 •  Response   200 OK Content-Type: application/vnd.restbucks+xml Content-Length: ... Last-Modified: 2009-01-08T15:10:32Z Etag: abbb4828-93ba-567b-6a33-33d374bcad39 <order … />
  • 228. Not  Retrieving  a  Resource  Representation   •  Request   GET /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2009-01-08T15:00:34Z If-None-Match: aabd653b-65d0-74da- bc63-4bca-ba3ef3f50432 •  Response   Client’s  representa8on  of   the  resource  is  up-­‐to-­‐date   HTTP/1.1 304 Not Modified
  • 229. Works  with  other  verbs  too   PUT /orders/1234 HTTP 1.1 Host: restbucks.com Accept: application/vnd.restbucks+xml If-Modified-Since: 2007-07-08T15:00:34Z If-None-Match: aabd653b-65d0-74da- bc63-4bca-ba3ef3f50432 <order …/>
  • 230. PUT  Results  in  no  Work  Done   200 OK Content-Type: application/xml Content-Length: ... Last-Modified: 2007-07-08T15:00:34Z Etag: aabd653b-65d0-74da-bc63-4bca- ba3ef3f50432  
  • 232. Good  Ole’  HTTP  Authentication   •  HTTP  Basic  and  Digest  Authentication:  IETF  RFC  2617   •  Have  been  around  since  1996  (Basic)/1997  (Digest)   •  Pros:   –  Respects  Web  architecture:     •  stateless  design  (retransmit  credentials)   •  headers  and  status  codes  are  well  understood   –  Does  not  prohibit  caching  (set  Cache-Control  to   public)   •  Cons:   –  Basic  Auth  must  be  used  with  SSL/TLS  (plaintext   password)   –  Not  ideal  for  the  human  Web  –  no  standard  logout   –  Only  one-­‐way  authentication  (client  to  server)   232  
  • 233. HTTP  Basic  Auth  Example   1.  Initial  HTTP  request  to  protected  resource   GET /index.html HTTP/1.1 Host: example.org 2.  Server  responds  with     HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm=”MyRealm”   3.  Client  resubmits  request   GET /index.html HTTP/1.1 Host: example.org Authorization: Basic Qm9iCnBhc3N3b3JkCg== Further  requests  with  same  or  deeper  path  can  include  the   additional  Authorization  header  preemptively  
  • 234. HTTP  Digest  Difference   •  Server  reply  to  first  client  request:   HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest [email protected], qop="auth,auth-int", nonce="a97d8b710244df0e8b11d0f600bfb0cdd2", opaque="8477c69c403ebaf9f0171e9517f347f2" •  Client  response  to  authentication  challenge:   Authorization: Digest username="bob", [email protected], nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/index.html", qop=auth, nc=00000001, cnonce="0a6f188f", response=”56bc2ae49393a65897450978507ff442", opaque="8477c69c403ebaf9f0171e9517f347f2"
  • 235. WSSE  Authentication   •  Driven  from  the  Atom  community   •  Use  the  WS-­‐Security  Username  Token  profile  mapped  to   HTTP  headers   •  Doesn’t  pass  sensitive  data  in  clear  text   •  Does  require  both  sides  to  know  a  shared  secret  
  • 236. Man-­‐in-­‐the-­‐Middle   •  All  HTTP  Authentication  schemes  can  be  hijacked  by  a  man-­‐ in-­‐the-­‐middle  attack   •  Can  intercept  a  Digest  response  from  a  service  and  change   it  into  a  Basic  challenge   •  Basic  is  easy  to  crack,  attacker  learns  the  password   •  Transport  level  security  considered  mandatory  when   you’re  using  HTTP  authentication  of  any  variety  
  • 237. SSL  /  TLS   •  “Strong”  server  and  optional  client  authentication,   confidentiality  and  integrity  protection   •  The  only  feasible  way  to  secure  against  man-­‐in-­‐the-­‐middle   attacks   •  Not  broken!  Even  if  some  people  like  to  claim  otherwise   •  Not  very  cache  friendly  though…  
  • 238. Transport  Level  Security   •  TLS  is  the  successor  to  Netscape’s  original  SSL   •  Tightened  up  some  security  loopholes   •  Now  under  IETF’s  stewardship   –  RFC  2246   –  RFC  5246   •  Provides  a  secure  channel  between  client  and  server   –  Authenticated   –  Identified  (bilateral  too)   –  Confidential   –  Integrity  assured  
  • 239. Start  with  a  TCP  Handshake   •  Classic  handshake  the  underpins  HTTP  connections   •  Not  secure  at  this  point,  obviously   *./) *'(+,-') !"#$%&'() *./)0)1!2) 1!2)
  • 240. Negotiate  some  cryptographic  options   •  Client  sends  its  hashing/encryption  capabilities  and  preferences   to  the  server   •  Server  responds  with  its  choices  from  those  the  client  presented   –  Preferring  highest  levels  of  security   •  Server  sends  its  certificate   –  Public  key,  CA   •  Server  indicates  that  it’s  complete   !.,'#/0'..") *'(+'(0'..") *'(+,-') !"#$%&'() *'(+'(!'(12-3/') *'(+'(0'.."4"#')
  • 241. Switch  on  the  crypto   •  Client  uses  server’s  public  key  to  send  a  PreMasterKey  to  the  server   –  If  the  server  is  authenticated,  it  can  decrypt  this  secret  with  its   private  key   •  Client  ChangeCipherSpec  flips  client  onto  the  secure  channel   •  ClientFinished  message  sends  a  hash  of  the  entire  conversation   –  To  alleviate  any  possibility  of  missing/tampered  messages   •  Server  ChangeCipherSpec  flips  server  onto  the  secure  channel   •  ServerFinished  sends  a  hash  of  the  entire  conversation  to  the  client   !.,'#/0'123-45#6') !45#6'!,74'(*7'-) !"#$%&'() *'(+,-') !.,'#/8,#,$4'9) !45#6'!,74'(*7'-) *'(+'(8,#,$4'9)
  • 242. Network  and  performance  considerations   •  Just  use  HTTP  everywhere?   •  Reduces  options  for  caching   –  Reverse  proxies  and  client-­‐side  caching  only   •  Expensive  to  set  up  connections   –  Though  relatively  cheap  to  maintain,  if  you  have  enough   sockets   •  Securing  a  channel  on  the  risk/value  profile  of  a  resource   –  Secure  channels  only  for  high  value/risk  resources     •  Can  use  a  hybrid  approach…  
  • 243. Publish  secret  data   •  Here  are  my  bank  account  details,  please  feel  free  to  use   them:   bb0ff34c3ab9c2a478cb7b8b61139a787bab5de1b4b 5ec463db070e1b72c502114758f1afd44c09b799207 3ccf00b43dc991579ddc5cbb91ea6984cbda08be9f •  Useless  to  you,  or  anyone  else,  unless  you  know  the   decryption  key  
  • 244. Widely  publish  secret  data   ./"&)0''1) !"#$%&'() ./"&)2#/(3) ./"&)2#/(3) ./"&)2#/(3) *'(+,-') ./"&)2#/(3) !"#$%&'() ./"&)2#/(3) ./"&)2#/(3) ./"&)2#/(3) !"#$%&'() ./"&)2#/(3)
  • 245. Secure  messaging  with  Atom   •  The  contents  of  individual  atom:entry  elements  can  be   encrypted  with  public/shared  keys  for  specific  consumers   •  Only  consumers  who  know  the  corresponding  private/ shared  key  can  make  sense  of  the  content   –  To  anyone  else,  it’s  gibberish   •  Keep  the  crypto  strong!   –  This  will  be  in  the  public  domain,  beware  brute  force  on   weak  algorithms   •  Can  cache  this  widely,  reduced  performance  hit   •  But  beware  coupling  via  keys!  
  • 246. OpenID   •  OpenID  is  a  decentralised  framework  for  digital  identities   –  Not  trust,  just  identity!   •  Your  have  an  OpenID  provider  or  one  is  provided  for  you   –  It  has  a  URI   •  Services  that  you  interact  with  will  ask  for  that  URI   •  Your  OpenID  provider  will  either:   –  Accept  the  request  for  processing  immediately   –  Ask  whether  you  trust  the  requesting  site  (e.g.  via  email   with  hyperlinks)   •  Once  your  OpenID  server  OK’s  the  login,  then  you  are   authenticated  against  the  remote  service   Authen8ca8ng  doesn’t  mo   you’re  authorised  to  d ean   –  With  your  canonical  credentials   anything!     This  is  not  a  trust  system!  
  • 247. OpenID  Workflow   *+'#,-).("/01'() #) <7) "/'( 8" :7 =' )- 59 0$5 ;)> ) #8 @' ?5 @9 %C ; )E # C) 3' D7 '5 ) 10( )B' F7 !"2'') !"#$%&'() 67),#0898"#) *(1'(0#3) 4'(/05') ) A7)B'10('5C )!('1 '#89H$) G7).('$'#C
  • 248. Not-­‐So-­‐OpenID?   •  There’s  no  trust  between  OpenID  providers   •  Your  Web  service  might  not  accept  my  OpenID  provider   –  In  general  it  won’t!   •  Trusted  providers  centralise  control   –  Against  the  philosophy  of  decentralised  ID!   •  Federated  providers  won’t  interoperate   –  Need  a  hybrid  “signing”  model  like  CAs?  
  • 249. OAuth   •  Web-­‐focused  access  delegation  protocol   •  Give  other  Web-­‐based  services  access  to  some  of  your   protected  data  without  disclosing  your  credentials   •  Simple  protocol  based  on  HTTP  redirection,  cryptographic   hashes  and  digital  signatures   •  Extends  HTTP  Authentication  as  the  spec  allows   –  Makes  use  of  the  same  headers  and  status  codes   –  These  are  understood  by  browsers  and  programmatic   clients   •  Not  dependent  on  OpenID,  but  can  be  used  together  
  • 251. OAuth  Workflow   Consumer   2.  Request  insurance  policies   Service  Provider   Insurance   Insurance   Broker   3.  Reject  with  authorisa8on  token   Provider   5.  Log  in  to   4.  Redirect  to     insurance  provider  and   insurance  provider   supply  authorisa8on  token   with  authorisa8on  token   6.  Authorise     1.  Request   broker  access  to   broker  to  obtain   exis8ng  policies   exis8ng  insurance     policies  from  insurance  provider   User  
  • 252. Tech  Interlude   Service  Hacks  and  Defences  
  • 253. Denial  of  Service   POST /order HTTP/1.1 •  Large  incoming  representations   Host: restbucks.com can  cause  problems   Content-Type:application/vnd.restbucks +xml –  DoS  through  memory  consumption   on  the  server   <order xmlns="http:// schemas.restbucks.com/order"> •  Use  the  Content-Length   <location>takeAway</location> <item> header  strictly   <name>latte</name> –  No  header,  bin  payload   <quantity>1</quantity> •  400  Bad  Request   <milk>whole</milk> <size>small</size> –  Stop  processing  payload  after  the   </item> number  of  bytes  in  the  header   <!-- Millions more item elements --> <item> –  Bin  payloads  for  suspiciously  large   <name>latte</name> headers   <quantity>1</quantity> •  Who  wants  a  million  cappuccinos?   <milk>skim</milk> <size>small</size> •  Swallow  OutOfMemoryError   </item> or  OutOfMemoryException </order> –  Don’t  let  them  know  they  won!  
  • 254. Keep  Secrets,  Secret   •  You  can  be  a  good  guy,  and  help  attackers   –  E.g.  401   –  Says  there’s  something  interesting  here!   •  Or  you  can  be  less  helpful   –  404   –  Says  there’s  nothing  to  see  here,  even  if  there  really  is   •  Don’t  use  easily  guessable  URIs  –  they  can  be  hijacked   –  UUID  is  your  friend   •  Think  carefully  about  what  attackers  can  learn  from   probing  you   –  You  don’t  always  want  to  be  a  good  guy!  
  • 255. Act  Defensively   •  Validate  the  content  of   <order xmlns="http:// representations   schemas.restbucks.com/ –  Just  over  216  café  lattes  would  be   order"> quite  lucrative     <location>takeAway</ –  But  is  likely  a  ruse  to  get  a  large   location> negative  number  into  our   workflow   <item> •  Integer  overflow?   <name>latte</name> •  Don’t  forget  anti-­‐corruption   <quantity> layering  between  your  resources   2147483648 and  you  domain  model   </quantity> –  REST  is  not  mindlessly  exposing  a   domain  over  HTTP!   <milk>whole</milk> <size>small</size> </item> ... </order>
  • 256. Don’t  be  gamed   GET /order/../../../../etc/passwd HTTP/1.1 GET /order/../../../../dev/random HTTP/1.1 Host: restbucks.com Host: restbucks.com •  Oh  oh   •  Oh  oh   •  We  just  gave  up  the   •  We  just  generated  a  never-­‐ password  file   ending  stream  of  bytes   •  And  rainbow  tables   •  And  now  we’re  going  to   cracked  it  in  no  time   spend  all  our  time  serving   them   Frameworks  help  avoid  these  problems  
  • 257. Less  is  best   •  Bugs  hide  in  code   •  Bugs  cause  security  breaches   •  Less  code,  less  places  for  bugs  to  hide   •  So  build  only  what  you  need   –  And  keep  your  software  soft  so  you  can  grow  it  over   time  
  • 258. Defend  in  Depth   •  Use  firewalls   –  On  the  network,  and  on  the  server   •  Do  open  ports  80  and  443   –  Do  not  open  other  ports   •  Do  not  mistake  HTTPS  for  security   –  It’s  not  enough!   •  Run  at  least  privilege   –  Never  run  your  service  as  root  or  administrator   •  Keep  good  deployment  hygiene   –  No  lingering  artifacts  that  attackers  can  grab  hold  of     •  Deploy  only  the  config  files,  DBs,  etc  that  you  need   •  And  remove  what  you  don’t   •  And  remember  that  social  engineering  is  still  effective!  
  • 260. Atom   <feed xmlns="http://www.w3.org/2005/Atom"> <title type="text">Inventory</title> <id>urn:uuid:426830d2-ab1d-11dd-a9c5-c85155d89593</id> <updated>2008-09-10T14:50:00Z</updated> <author> <name>Leicester Square</name> <uri>http://restbucks.com/stores/1234</uri> </author> <link rel="self" href="http://restbucks.com/stores/1234/inventory"/> <entry> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">Chocolate Chip Cookies</title> <updated>2008-09-10T14:45:32Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/9876" type="application/vnd.restbucks+xml"/> </product> <quantity>678</quantity> </inventory> </content> </entry> <entry> <id>urn:uuid:7fb82319-b190-46d2-bb88-c9fcce240643</id> <title type="text">Fairtrade Coffee</title> <updated>2008-09-10T13:55:02Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/211" type="application/vnd.restbucks+xml"/> </product> <quantity>407</quantity> </inventory> </content> </entry> </feed>
  • 261. Atom  model   feed entry 0 id category id title title updated updated content resource outOfLine inlineText inlineXHTML inlineOther Based  on  diagrams  by  Stefan  Tilkov  
  • 262. Entries  can  be  standalone   <entry xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">Chocolate Chip Cookies</title> <updated>2008-09-10T14:45:32Z</updated> <content type="application/vnd.restbucks+xml"> <inventory xmlns="http://schemas.restbucks.com/inventory"> <product xmlns:a="http://www.w3.org/2005/Atom"> <a:link href="http://restbucks.com/product/9876" type="application/vnd.restbucks+xml"/> </product> <quantity>678</quantity> </inventory> </content> </entry>
  • 263. AtomPub     Application  protocol   Methods,   Not  just   Client     status  codes,   for   Atom   Server   headers   resources   editing  Web  resources   Atom   using   envelope   HTTP  transfer  of   Atom-­‐formatted  representations  
  • 264. AtomPub  model   collection member 0 id id title title updated updated category workspace entry link service document resource Based  on  diagrams  by  Stefan  Tilkov  
  • 265. Restbucks   Order   Management   Product   Regional   Management   Distribution   Inventory  
  • 266. Who  needs  to  know  what?   Order   Management   Product  Updated   Product  Updated   Product   Regional   Management   Distribution   Inventory   Product  Updated  
  • 267. Implementation  options   Point-­‐to-­‐point   •  Publisher  maintains  subscriber  list   •  Queues  to  reduce  temporal  coupling   Bus   •  Subscriptions  and  guaranteed  delivery  delegated  to   middleware   •  Reduced  location  and  temporal  coupling   Consumers  pull  events   •  Consumers  poll  publishers   •  Guaranteed  delivery  delegated  to  consumers   •  No  list  of  subscribers  to  maintain  
  • 268. Polling  an  Atom  feed   Order     Management   Atom  Client   http://restbucks.com/products/notifications   Product   Management   Atom  icons  from  http://sniker.blogage.de/  
  • 269. Atom  feed  represents  an  event  stream   <feed xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:be21b6b0-57b4-4029-ada4-09585ee74adc</id> <title type="text">Product Notifications</title> <updated>2008-09-10T14:50:32+01:00</updated> <author> <name>Product Management</name> <uri>http://restbucks.com/products</uri> </author> <link rel="self" href="http://restbucks.com/products/notifications/2008/9/10/13"/> <link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/12"/> <entry> <id>urn:uuid:95506d98-aae9-4d34-a8f4-1ff30bece80c</id> <title type="text">product created</title> <updated>2008-09-10T14:45:32+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/95506d98-aae9-4d34-a8f4-1ff30bece80c"/> <category term="product"/> <category term="created"/> <content type="application/xml"> <product xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="1" href="http://restbucks.com/products/527"/> <id>527</id> <name>Fairtrade Roma Coffee Beans</name> <size>1kg</size> <price>10</price> </product> </content> </entry> ... </feed>
  • 270. On  the  wire   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com Response   HTTP/1.1 200 OK Cache-Control: max-age=60 Content-Length: 12230 Content-Type: application/atom+xml;charset="utf-8" Content-Location: http://restbucks.com/products/notifications/2008/9/10/13 Last-Modified: Wed, 10 Sep 2008 13:50:32 GMT ETag: "6a0806ca" Date: Wed, 10 Sep 2008 13:51:03 GMT <feed xmlns="http://www.w3.org/2005/Atom"><id>urn:uuid:be21b6b0-57b4-4029- ada4-09585ee74adc</id><title type="text">Product Notifications</ title><updated>2008-09-10T14:50:32+01:00</updated><author><name>Product Management</ name><uri>http://restbucks.com/products</uri></author><link rel="self" href="http:// restbucks.com/products/notifications/2008/9/10/13"/><link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/12"/><entry><id>urn:uuid: 95506d98-aae9-4d34-a8f4-1ff30bece80c</id><title type="text">product created</ title><updated>2008-09-10T14:45:32+01:00</updated><link rel="self" href="http:// restbucks.com/products/notifications/95506d98-aae9-4d34-a8f4-1ff30bece80c"/><category term="product"/><category term="created"/><content type="application/xml"><product xmlns="http://restbucks.com/products" ...
  • 271. Retrieving  the  archive  by  following  links   Request   GET /products/notifications/2008/9/10/12 HTTP/1.1 Host: restbucks.com Response   HTTP/1.1 200 OK Cache-Control: max-age=2592000 Content-Length: 9877 Content-Type: application/atom+xml;charset="utf-8" Last-Modified: Wed, 10 Sep 2008 12:57:14 GMT Date: Wed, 10 Sep 2008 13:51:46 GMT <feed xmlns="http://www.w3.org/2005/Atom"><id>urn:uuid:4cbc0acf-a211-40ce-a50e- a75d299571da</id><title type="text">Product Notifications</ title><updated>2008-09-10T13:57:14+01:00</updated><author><name>Product Management</ name><uri>http://restbucks.com/products</uri></author><link rel="self" href="http:// restbucks.com/products/notifications/2008/9/10/12"/><link rel="current" href="http:// restbucks.com/products/notifications/2008/9/10/13"/><link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/11"/ ><entry><id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id><title type="text">promotion cancelled</title><updated>2008-09-10T13:57:14+01:00</ updated><link rel="self" href="http://restbucks.com/products/notifications/ b436fda6-93f5-4c00-98a3-06b62c3d31b8"/><category term="promotion"/><category term="cancelled"/><content type="application/xml"><promotion xmlns="http:// restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"><atom:link type="application/xml" ...
  • 272. Archive   <feed xmlns="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"> <id>urn:uuid:4cbc0acf-a211-40ce-a50e-a75d299571da</id> <title type="text">Product Notifications</title> <updated>2008-09-10T13:57:14+01:00</updated> <author> <name>Product Management</name> <uri>http://restbucks.com/products</uri> </author> <link rel="self" href="http://restbucks.com/products/notifications/2008/9/10/12"/> <link rel=”next-archive" href="http://restbucks.com/products/notifications/2008/9/10/13"/> <link rel="prev-archive" href="http://restbucks.com/products/notifications/2008/9/10/11"/> <fh:archive/> <entry> <id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id> <title type="text">promotion cancelled</title> <updated>2008-09-10T13:57:14+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/b436fda6-93f5-4c00-98a3-06b62c3d31b8"/> <category term="promotion"/> <category term="cancelled"/> <content type="application/xml"> <promotion xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="3" href="http://restbucks.com/products/391"/> <regions> <atom:link type="application/atom+xml;type=feed" etag="14" href="http://restbucks.com/regions/london"/> </regions> <products> <atom:link type="application/xml" etag="1" href="http://restbucks.com/products/7642"/> </products> </promotion> </content> </entry> ... </feed>
  • 273. An  Atom  entry  represents  an  event   <entry xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:b436fda6-93f5-4c00-98a3-06b62c3d31b8</id> <title type="text">promotion cancelled</title> <updated>2008-09-10T13:57:14+01:00</updated> <link rel="self" href="http://restbucks.com/products/notifications/b436fda6-93f5-4c00-98a3-06b62c3d31b8"/> <category term="promotion"/> <category term="cancelled"/> <content type="application/xml"> <promotion xmlns="http://restbucks.com/products" xmlns:atom="http://www.w3.org/2005/Atom"> <atom:link type="application/xml" rel="alternate" etag="3" href="http://restbucks.com/products/391"/> <regions> <atom:link type="application/atom+xml;type=feed" etag="14" href="http://restbucks.com/regions/london"/> </regions> <products> <atom:link type="application/xml" etag="1" href="http://restbucks.com/products/7642"/> </products> </promotion> </content> </entry>
  • 274. Handling  eager  re-­‐polling   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com If-None-Match: "6a0806ca" Response   HTTP/1.1 304 Not Modified Date: Wed, 10 Sep 2008 13:57:20 GMT
  • 275. Divide  and  conquer   feed   entry   Events   Entities   promotion   product  
  • 276. An  Atom-­‐  and  AtomPub-­‐enabled  service   AtomPub   AtomPub   Atom   Atom  
  • 277. Caching  archived  feeds   “prev-­‐archive”   Current   “prev-­‐archive”   “prev-­‐archive”   “next-­‐archive”   Local  cache   “next-­‐archive”   “next-­‐archive”  
  • 278. Domain  application  protocol   prev next consuming antecedent feed prev consuming next prev current feed consuming next subsequent feed next
  • 279. "application/atom+xml"   Atom  Publishing  Protocol   "An  IRI  of  an  editable  Member  Entry.   When  appearing  within  an  atom:entry,   the  href  IRI  can  be  used  to  retrieve,   update  and  delete  the  Resource   represented  by  that  Entry."   <link rel="edit" href="http://restbucks.com/products/notifications/2008/9/10/13" type="application/atom+xml;type=entry"/> Atom  Syndication  Format  
  • 280. Remember:  "application/xml"  is  not  your  friend   "application/xml"   Out-­‐of-­‐band  processing  model   Processing  model   Namespace   Application-­‐specific   ?   hypermedia  semantics   Documented   ?   operations   XML  Schema,     It’s  XML…   RELAX  NG,  etc  
  • 281. Custom  media  types   "application/vnd.restbucks+xml"   Processing  model   "application/atom+xml"   Hypermedia  controls   <atom:link/>   Registry  of  Link   Supported  methods   Relations   Representation   formats   Media  type  for  tuning  the   hypermedia  engine;   schema  for  structure  
  • 282. Caching   Uri   Description   Caching   /products/notifications Current   Short   /products/notifications/{year}/{month}/{day}/{hour} Archive   Long   /products/notifications/{entry-id} Notification   Long   /products/{product-id} Product   Varies   /products/{hardware-id} Promotion   Varies  
  • 283. Caches   Caching  proxy   Local  cache   Reverse  proxy   (Gateway)  
  • 284. Caching  the  bus   Client   Cache   Service   Client   Client  
  • 285. Protecting  feeds   Request   GET /products/notifications HTTP/1.1 Host: restbucks.com Authorization: Basic aWFuc3JvYmluc29uOlBhdHQzcm41== Response   ... Cache-control: public, no-cache Caching  proxy   Local  cache   Reverse  proxy   (Gateway)  
  • 286. Caching  dilemma   Efficient  use  of  network     resources   High  TTL   Low  TTL   Publisher  controls  freshness     of  data  
  • 287. Cache  channels   Mark  Nottingham,  Yahoo   •  http://www.mnot.net/cache_channels/   Use  Atom  to  extend  the  freshness  of  cached  responses   Response   Cache-Control: max-age=60, channel="http://restbucks.com/products/channel/index", channel-maxage Response  remains  fresh  as  long  as:   •  Cache  polls  channel  at  least  as  often  as  "precision"   specified  by  channel   •  Channel  doesn’t  issue  stale  event  
  • 289. Web  Architecture   •  Ubiquitous,  global  on-­‐ramp   •  Connects  everything  to  everything,  based  on  URI-­‐ addressable  resources   –  With  a  uniform  interface   •  Also  provides  standard  coordination  mechanism   –  Status  codes!   •  And  is  ambivalent  about  content   •  Media  types!  
  • 290. URI  Tunnelling   •  Map  URIs  to  methods  and  GET  those  URIs   –  Easy,  ubiquitous   •  Not  very  Web-­‐friendly   –  Breaks  expectations   –  Remember  the  library  of  congress  incident?  
  • 291. POX   •  Treats  HTTP  as  a  synchronous  transport  protocol   –  Great  because  it  gets  through  firewalls   •  But  again  breaks  expectations   –  HTTP  is  not  MOM!   •  Misses  out  on  all  the  good  stuff  from  the  Web   –  Status  codes  for  coordination   –  Caching  for  performance   –  Loose  coupling  via  hypermedia   –  Etc   •  Not  as  good  as  proper  message-­‐oriented  middleware   –  Which  are  low-­‐latency,  reliable,  etc.  
  • 292. CRUD  Services   •  The  simplest  kind  of  Web-­‐based  service   •  Embraces  HTTP  and  Web  infrastructure   –  Four  verbs,  status  codes,  formats   –  Cacheable!   •  Can  easily  describe  them   –  URI  templates   –  WADL   •  But  tightly  couples  client  and  server   –  Might  not  be  a  problem  in  some  domains  
  • 293. Hypermedia   •  It’s  all  about  media  types  and  link  relations!   –  Describe  state  machines  with  lots  of  lovely  links   •  Constrain  what  you  can  do  to  resources  with  the  uniform   interface   •  Loosely  coupled   –  The  server  mints  URIs  to  resources,  clients  follow  them   –  Easily  spans  systems/domains  (URIs  are  great!)   •  Embraces  the  Web  for  robustness   –  Verbs,  status  codes,  caching   •  Design  and  implementation:   –  Design  application  protocol  state  machines;     –  Implement  resource  lifecycles;     –  Document  using  media  types,  link  relation  values  and   HTTP  idioms.  
  • 297. Scalability   •  Everything  you  know  still  applies   –  Stateless  is  good   –  Horizontal  is  good   •  Yet  everything  you  know  no  longer  applies!   –  Text-­‐based  synchronous  protocol  is  scalable???   •  Do  as  little  work  as  possible   –  Make  interactions  conditional   •  ETags  and  if-­‐modified  etc  are  your  friends   •  And  cache!  
  • 298. Security   •  HTTPS  is  still  our  friend!   –  But  it  inhibits  caching   •  OpenID  support  waning  on  the  human  Web   •  OpenAuth  now  finding  its  feet   –  Likely  to  become  dominant  approach   •  Other  approaches  like  SAML,  mature  but  yet  to  be  widely   deployed  
  • 300. …you   wouldn’t   use  it  at   home!  
  • 301. Atom  and  AtomPub   •  Atom  is  format  that  describes  list  of  things   –  In  terms  of  feeds  and  entries   •  AtomPub  is  a  protocol  defined  in  terms  Atom  entries  and   links   •  Together  they  can  be  used  for  very  scalable  pub/sub   –  But  latency  is  very  high  compared  to  enterprise  pub/sub   –  Caching  enables  massive  scalability   –  But  causes  latency  
  • 302. Liked  the  Tutorial?   GET  /theBook   204  No  Content     (until  early  2010!)