ECS781P

CLOUD COMPUTING
RESTful API

Lecturer: Dr. Sukhpal Singh Gill

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: standard for designing an XML document to
describe a web service1
- SOAP: an XML based messaging protocol to communicate
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!
1
web 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
- Request body is empty
- Information can be encoded in the request path
- Server returns a representation of the state of the resource
- e.g.: GET /modules
GET /modules/<module-id>
➢ 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)
- Request body contains the representation of the resource to
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
- Request body contains the representation of the resource to
be stored instead.
- If the Request-URI refers to an already existing resource,
then an update operation will happen, otherwise create
operation should happen if Request-URI is a valid resource
URI.
- e.g. PUT /modules/<module-id>
➢ DELETE request method: Delete the identified resource
- Request body is empty.
- e.g. DELETE /modules/<module-id>

8
REST Style

Similarity with CRUD operations in persistent storage interfaces:

REST action Similar function in persistent storage

POST Create
GET Read (Retrieve)
PUT Update (Modify)
DELETE 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 /modules as opposed to
PUT /modules/ECS781P
➢ PUT (update)method is idempotent but POST (create)
is not: if a request is retried multiple times, that should be
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.
A cacheable response is an HTTP response that can be cached, that is stored to be retrieved and used later, saving a new request to the server.
10
Idempotent is where you call the same function with the same value and the result is exactly the same, that is the mathematically definition
REST methods, Example

Method URI Action

GET /modules ?
POST /modules ?

GET /modules/<module-id> ?
PUT /modules/<module-id> ?
DELETE /modules/<module-id> ?

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: the client and the server are decoupled

(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: whenever applicable, resources must declare

themselves cacheable.
- Caching improves performance for client side and enables
better scalability for a server (because of the reduced load).
► Layered system: The design should allow intermediaries
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

► Uniform Interface: “Once a developer becomes familiar with

one of your API, he should be able to follow the similar approach
for other APIs.”
- Each resource has a URI and the URI is in the requests
- The resource states can be represented in standard formats,
e.g. HTML, XML, JSON – the messages are self-descriptive,
e.g. they include a media-type to tell which parser to invoke.
- The resources can be manipulated through state
representation and HTTP methods (GET, POST, PUT,
DELETE) in predictable ways.
- Hypermedia As The Engine Of Application State
(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

17
RESTful API Design: Example

Sample REST interface: RESTbucks orders2

2
from 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 → Apache Tomcat / Glassfish
- Ruby → Ruby on rails
- ...

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