Transcript Slide 1

REST
Representational
State Transfer
Pat Croke, Aine Leddy
DERI Líon Research Project, HewlettPackard
© 2004 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
Disclaimer
•
Opinions and intuitions expressed in this presentation
are the author’s and do not necessarily reflect HewlettPackard Company’s position.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
2
Simplified Topology of the Web
Client
Proxy
request
cache
request
cache
response
7/18/2015
Server
security
cache
response
Copyright © 2003 HP corporate presentation. All rights reserved.
security
3
REpresentational State Transfer
•
•
•
•
REST is not a standard!
REST is an architectural style for distributed
hypermedia systems
relevance: modern web is (to a large extent) an
implementation of this style
While REST is not a standard, it does prescribe
the use of standards:
−
−
−
−
7/18/2015
HTTP
URL
XML/HTML/GIF/JPEG/etc (Resource Representations)
text/xml, text/html, image/gif, image/jpeg, etc (Resource Types,
MIME Types)
Copyright © 2003 HP corporate presentation. All rights reserved.
4
Representational State Transfer
•
Clients in a REST type system can be viewed as
state machines
•
Progress (transfer) from one state to another by
receiving resource representations
•
In a network of web pages...
− links are state transitions
− individual web pages are states
•
The term REST was coined by Roy Fielding in
his Ph.D. dissertation (Fielding 2000a)
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
5
What‘s in the name?
http://www.boeing.com/aircraft/747
Resource
Client
Fuel requirements
Maintenance schedule
...
(Costello)
Boeing747.html
• The Client references a Web resource using a URL.
• A representation of the resource is returned (in this case as an HTML document).
• The representation (e.g., Boeing747.html) places the client application in
a state.
• The result of the client traversing a hyperlink in Boeing747.html is another
resource
is accessed.
• The new representation places the client application into yet another state.
• Thus, the client application changes (transfers) state with each resource
representation --> Representation State Transfer!
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
6
Characteristics of a REST-based
Network
•
Client-Server: a pull-based interaction style: consuming
components pull representations.
•
Stateless: each request from client to server must contain all
the information necessary to understand the request, and
cannot take advantage of any stored context on the server.
•
Cache: to improve network efficiency responses must be
capable of being labeled as cacheable or non-cacheable.
•
Uniform interface: all resources are accessed with a generic
interface (e.g., HTTP GET, POST, PUT, DELETE).
•
Named resources - the system is comprised of resources
which are named using a URI.
•
Hyperlinks- the representations of the resources are
interconnected using URLs, thereby enabling a client to
progress from one state to another.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
7
REST V’s SOAP
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
8
Implementing a Web Services using REST
http://www.parts-depot.com/parts/0035
Response
(HTML/XML doc)
HTTP GET request
Response
(HTML/XML doc)
HTTP POST
PO
(HTML/XML)
URL to submitted PO
7/18/2015
URL 1
Parts
List
HTTP response
URL 2
HTTP response
Web Server
HTTP GET request
Part
URL 3
PO
HTTP response
Copyright © 2003 HP corporate presentation. All rights reserved.
9
Implementing Web Services using SOAP 1.1
In SOAP 1.1
•
All requests are made using the HTTP Post Method
•
The target operation is hidden inside the SOAP envelope.
•
A SOAP server has to peek into this document to
determine what procedure to invoke.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
10
Example of A Soap Request
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<p:getPart xmlns:p="http://www.parts-depot.com">
<part-id>00345</part-id>
</p:getPart>
</soap:Body>
</soap:Envelope>
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
11
Implementing Web Services using SOAP
SOAP envelope
Request
(XML doc)
HTTP POST
URL 1
getPartsList()
Response
(XML doc)
HTTP POST
Response
(XML doc)
PO
(XML doc)
URL 1
HTTP Response
HTTP POST
Web Server
Request
(XML doc)
HTTP Response
SOAP Server
getPart(id)
URL 1
submit(PO)
Response
(XML doc)
HTTP Response
Note the use of the same URL (URL 1) for all transactions. The SOAP Server parses the
SOAP message in the envelope to determine which method to invoke. All SOAP
messages are sent using an HTTP POST.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
12
Implementing Web Services using SOAP 1.2
In SOAP 1.2
•
You have the option of using both HTTP Get and
Post methods
•
All resources that have their own URI can be
accessed using the HTTP Get method
•
Most SOAP Servers are still using the RPC style
of HTTP Post
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
13
State Transition
•
The State Transitions of an Application in REST
are made using Hyperlinks in the representation
•
In a pure SOAP system each SOAP message will
be just data, no hyperlinks.
•
Consequently, the decision on which resource to
access next must be made out-of-band
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
14
Intermediaries
•
•
•
•
The Transport route that a message takes
between Client and Server may go through many
intermediaries, such as proxy servers and
Gateways
In REST the Client and Server do not require any
knowledge of the overall topology
In SOAP however you have the option of
programming the route by including specific
Header Blocks in the SOAP envelope for the
intermediaries.
These header blocks may or may not require
compulsory understanding
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
15
Proxy servers
•
Proxy servers are a security method that decide,
based upon the resource identified by the URI, and
the HTTP method, whether or not to allow the
operation.
•
In SOAP the URI is not always to the target resource,
but rather to a SOAP server.
•
A Proxy Server would have to be specially written to
be able to understand a SOAP message.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
16
Proxy servers
•
As there is no standardized way that a SOAP
message can be written, no Proxy can
understand messages from every SOAP Web
service.
•
This makes it harder, and less likely, for a Proxy
server to determine which resource is actually
being targeted.
•
Therefore its effectiveness as a security Buffer is
compromised
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
17
Caching in REST
•
A Cache Server is able to store a copy of any
response to a HTTP Get request.
•
This shortens the distance that the client must go
to get the data, thus speeding up the request.
•
The results of a resource request in REST
contains an indication in the HTTP header of
whether these results are cacheable (and when
the data will become stale).
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
18
Caching in SOAP
•
In SOAP 1.1 no Caching was possible with SOAP,
because the cache server could not determine
− If data is being requested, as SOAP operations are
always HTTP Post, even requests.
− What resource is being requested as the URI is always
to the SOAP server, not the target resource
•
In SOAP 1.2 you do have the option of declaring
your resources with URI’s and using HTTP Get
•
Only these SOAP resources can be cached.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
19
Principles of Rest Web Service
Design
1.
Identify all of the conceptual entities that you
wish to expose as services.
2.
Create a URL to each resource.
3.
Prefer logical URL’s to Physical URL’s
− http://www.parts-depot.com/parts/00345 is preferred to
− http://www.parts-depot.com/parts/00345.html
− Logical URIs allow the resource implementation to
change without impacting client applications.
− There does not have to be a static HTML page for
every resource, you can use template html pages with
the data being obtained dynamically from a knowledge
base
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
20
Principles of Rest Web Service
Design
5.
6.
7.
8.
As a corollary to (3) use nouns in the logical
URI, not verbs. Resources are "things" not
"actions".
Make all HTTP GET’s side-effect free. Doing so
makes the request "safe".
Put hyperlinks within resource representations to
allow the client to obtain more information
Minimize the use of query strings.
− http://www.parts-depot.com/parts/00345 is preferred to
− http://www.parts-depot.com/parts?part-id=00345
− You can instantiate sub-resources of '00345' easily; this
is not possible if that information is tucked away in a
query string.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
21
Stateful REST
•
A Stateless Architecture is not always possible in the Real
World.
•
In an application where the session information is too
large to resend with every request, it is more efficient to
send it once and store it as session information on the
server.
•
Also some applications require the use of session keys for
security reasons E.g. SSL (secure session layer)
•
The most common method for doing this on the web is
through the use of Cookies
•
Cookies break the rules of the REST architectural style,
but are sometimes considered necessary.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
22
Cookies
•
A Cookie is a text only string that contains state
information tied to a particular URL,
− If enabled they are stored on the client machine and are
rebroadcast each time that URL is requested.
− Cookies are used to
• Personalize information (like on My Yahoo)
• Help with on-line sales/services (like on Amazon Books or eBay)
• Simply for the purposes of collecting demographic information
(like DoubleClick).
• Keep site information fresh and relevant to the users interests
• Securely store any personal data that the user has shared with a
site (to help with quick logins on your favorite sites, for example).
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
23
Cookies cont.
− Cookies are necessary when using SSL’s as the
exchange of Client/Server Session Keys are required.
− The server needs the cookies to keep track of the
session in which the keys have been used.
− The server may have to keep track of multiple clients all
with different encryptions.
− Client manipulations of state are not as straight forward
as with REST and session errors can occur which
require restarting the session.
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
24
Observations
•
Amazon has web services available as both SOAP and
REST styles.
•
85% of accesses are made using the REST style.
•
REST is a lot easier to learn than SOAP.
− Open URL connection.
− Read Buffer
− Parse output.
•
Knowing SOAP, WSDL doesn’t make the task easier.
•
REST is more efficient due to the allowance of caching.
•
I have yet to meet a programmer who can explain to me
why SOAP is useful. (Challenge)
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
25
Sources
•
Fielding, Roy T. Architectural styles and the design of network-based
software architectures. PhD Thesis, University of California, Irvine,
2000.
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
•
Fielding, Roy T. and Richard N. Taylor. Principled Design of the
Modern Web Architecture.
http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf
•
Costello, Roger L. Building Web Services the REST Way.
http://www.xfront.com/REST-Web-Services.html
•
Developing Web Services Choreography Standards – The Case of
REST vs SOAP, zur Muehlen, M:Nickerson, J.V.;Swenson K.D.
http://www.workflow-research.de/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf
•
REST vs. SOAP at Amazon
http://www.oreillynet.com/pub/wlg/3005
7/18/2015
Copyright © 2003 HP corporate presentation. All rights reserved.
26