ECS781P
CLOUD COMPUTING
RESTful API
Lecturer: Dr. Sukhpal Singh Gill and Dr Ignacio Castro School of Electronic Engineering and Computer Science
Contents
• REST style
• REST Architecture Style Constraints
Recap on REST
REST (REpresentation State Transfer)
As the alternative to “WSDL/SOAP”
– WSDL:standardfordesigninganXMLdocumentto
describe a web service1
– SOAP:anXMLbasedmessagingprotocoltocommunicate
with a WSDL compliant web service, over an application protocol like HTTP
“Web Services” are based on well-defined service interfaces described in a WSDL document. This tried to provided a “standard” way of interaction that has good features like security, but is too verbose, has large coordination overhead, is not friendly with
web-architecture like caching, and they don’t scale well!
1web service vs Web Service!
4
REST style
REST is not a protocol, but rather a set of architectural con- straints.
Everything that is supposed to be interacted with is abstracted as a resource!
Each resource has a unique resource identified URI
The communication is directly done through HTTP (so every REST call is a HTTP request).
5
URI (Uniform Resource Identifier)
Not intended to change over time
It is the only manner to locate a resource (if it
changes any links to it will also change)
The client provides parameters in the URI to
define the desired information and representation
URI structure
URI = scheme[userinfo@]host[:port]path[?query][#fragment]
https://john.doe@www.example.com:123/forum/questions /?tag=networking&order=newest#top
The “?query” allows the client to pass parameters to the server to identify the particular resource that the client desires
REST style
REST is not a protocol, but rather a set of architectural con- straints (guidelines). If an application adheres to these guide- lines, it is called RESTful.
Everything that is supposed to be interacted with is abstracted as a resource!
Each resource has a unique resource identified URI
The communication is directly done through HTTP (so a REST call is just a HTTP request). So all the interactions with a restful application should be encoded using HTTP methods:
– GET, POST, PUT, DELETE
6
REST style
GET request method: Requests the state of an identified resource from the server
– Requestbodyisempty
– Informationcanbeencodedintherequestpath
– Serverreturnsarepresentationofthestateoftheresource
– e.g.: GET /modules
GET /modules/
POST request method: Create a new resource according to the attached representation as a “subordinate” of the resource identified by the request URI (so should be a “collection” URI)
– Requestbodycontainstherepresentationoftheresourceto be created
– e.g. POST /modules
7
REST Style
PUT request method: Update the representation of a resource identified by the request URI according to the attached representation
– Requestbodycontainstherepresentationoftheresourceto be stored instead.
– IftheRequest-URIreferstoanalreadyexistingresource, then an update operation will happen, otherwise create operation should happen if Request-URI is a valid resource URI.
– e.g. PUT /modules/
DELETE request method: Delete the identified resource
– Requestbodyisempty.
– e.g. DELETE /modules/
8
REST Style
Similarity with CRUD operations in persistent storage interfaces:
REST action
POST GET PUT DELETE
Similar function in persistent storage
Create Read (Retrieve)
Update (Modify) Delete (Destroy)
Can you name the specific methods e.g. in SQL?
9
POST vs PUT
POST request URI is a collection URL – e.g.POST /modulesasopposedto
PUT /modules/ECS781P
PUT (update)methodisidempotentbutPOST (create) isnot:ifarequestis retriedmultipletimes,thatshouldbe equivalent to a single request modification. Whereas, each repeated POST request will lead to a new resource created on the server with its newly assigned URI (so, in particular, a PUT response is cacheable unlike a POST response)
PUT should be used to modify (update) a resource that is part of a resource collection. POST should be used to add (create) a new child resource under a resource collection.
10
REST methods, Example
Method URI Action GET /modules ?
POST /modules ?
GET /modules/
Follow this URI design pattern for other more complicated examples as well.
POST method
The POST method is used to CREATE resources The resource URI is usually not known at creation time
The REST server usually automatically generates the new URI for the resource
POST example
http://www.restfuljava.com
GET method
The GET method is used to RETRIEVE resources No effect on the resource
Multiple GETs can be called without changing the state of the resource
It can also return parts of a resource
By altering the URI it can act to read the resource and as a query operation
GET example
http://www.restfuljava.com
PUT method
The PUT method is used to UPDATE resources It works as follows:
• A GET request is used to obtain a representation of the resource which needs to be updated
• The client updates the resource with new values
• The resource is updated using a PUT request with the representation as a payload
PUT example
The initial GET request is omitted in this diagram
http://www.restfuljava.com
DELETE method
The DELETE method is used to remove resources It works in a similar fashion to PUT
Both PUT and DELETE requests apply to the entire resource
Both PUT and DELETE requests are atomic so simultaneous requests are managed and one request will determine the final state of the resource
It can also be used to determine the URI of the resource which is being deleted
DELETE example
http://www.restfuljava.com
Contents
• REST style
• REST Architecture Style Constraints
REST Architectural Style Constraints
► Client-server:theclientandtheserveraredecoupled (separation of concerns between server and client), and must be able to evolve separately without any dependency on each other (as long as the interface is fixed.)
► Stateless: to serve a request, the server must not have to remember the previous interactions (no client context is stored on the server)
– This means that if the client application needs to be a stateful (e.g. user logs in once to be authenticated), then each request from the client should contain all the necessary information necessary to service the request (e.g. authentication/authorisation details).
13
REST Architecture Style Constraints
► Cacheable:wheneverapplicable,resourcesmustdeclare themselves cacheable.
– Caching improves performance for client side and enables better scalability for a server (because of the reduced load).
► Layeredsystem:Thedesignshouldallowintermediaries for load-balancing, shared caching, increased availability systems, auditing, security enforcement, etc. without a client needing to change its interaction.
14
REST Architecture Style Constraints
► UniformInterface:“Onceadeveloperbecomesfamiliarwith one of your API, he should be able to follow the similar approach for other APIs.”
– EachresourcehasaURIandtheURIisintherequests
– Theresourcestatescanberepresentedinstandardformats, e.g. HTML, XML, JSON – the messages are self-descriptive, e.g. they include a media-type to tell which parser to invoke.
– Theresourcescanbemanipulatedthroughstate representation and HTTP methods (GET, POST, PUT, DELETE) in predictable ways.
– HypermediaAsTheEngineOfApplicationState (HATEOAS)
15
REST Architecture Style Constraints: HATEOAS
Hypermedia As The Engine Of Application State (HATEOAS)
as part of the uniform interface constraint, requires the client to be unaware of URIs structure: all the client needs to know is the entry URI, while all remaining URIs are discovered dynamically during the conversation.
much like visiting a web site – where you don’t study its URI beforehand! (recall what HTTP stands for?!)
The server responses should includes hyperlinks to other related actions that are also available.
Reduces the need for the client hard-code the interface, and hence less chance to break is the application is evolved (simplify application evolution – Server side can change without affecting clients)
16
HAETOS: Example 1
17
HAETOS: Example 2
Also, watch this tutorial!
18
RESTful API Design: Example
Sample REST interface: RESTbucks orders2
2from Jim Webber, REST in Practice: Hypermedia and Systems Architecture
19
RESTful API Design: Example
Exchange of HTTP messages (1): POST request
20
RESTful API Design: Example
Exchange of HTTP messages (2): GET request
21
RESTful API Design: Example
REST Service Interactions
22
Application Web Servers
Dynamic Web Servers
Application Servers: Software listening to web requests, and hosting specific server applications
The application server provides libraries for apps Diversity of servers depending on technology
– Python→Flask,Django,Tornado – JS→node.js
– Java→ApacheTomcat/Glassfish – Ruby→Rubyonrails
– …
23
Application Web Servers
Dynamic Web Server
24
Application Web Servers
Server-side applications are developed for a specific application server
Applications run inside an application server
Applications register server paths / methods to be
handled by specific application code
The application server receives the request, handles the request message to the specific application registered to answer
25
Application Web Servers
Request Handling
26
REST
Example: Mapping in Flask
27