[2015/2016] the rest architectural style

43
Gran Sasso Science Institute Ivano Malavolta REST

Upload: ivano-malavolta

Post on 23-Jan-2017

341 views

Category:

Technology


0 download

TRANSCRIPT

Gran Sasso Science Institute

Ivano Malavolta

REST

Roadmap

The REST Architectural Style

Resources

Representations

Actions

REST

It stands for

REpresentationalState Transfer

Proposed by Roy Fieldingsin his PhD dissertation in 2000

REST rules the architecture ofthe World Wide Web (HTTP)

Major players

REST Architectural Style

REST is neither a technology nor a framework

REST is an Architectural Style

à a set of principles + constraints

Those constraints help us in developing applications that are “easy” to maintain and extend

REST Main Constraints

A RESTful system

• is client-server

• is stateless

– there should be no need for the service to keep users’ sessions

– each request should be independent of others

• has to support a caching system

• has to be uniformly accessible

– each resource must have a unique address and a valid point of access

The (static) Web as a RESTful system

1. you type a URL into your browser to reach a specific HTML page

2. the browser gets and displays the elements of the HTML page

à the browser is getting a representation of the current state of that resource

REST Main Actors

These are the abstractions that make a RESTful system:

• Resources

• Representations

• Actions

Roadmap

The REST Architectural Style

Resources

Representations

Actions

Resources

A resource is “everything” the service can provide

States and functions of a remote application are also considered as resources

Example of resources:

• title of a movie from IMDb

• a Flash movie from YouTube

• images from Flickr

• order info from eBay

• etc.

Resources

In general, a RESTful resource is anything that is addressable

over the Web

Addressable = anything that can be accessed and transferred between client and server

à a resource must have a unique address over the Web

Under HTTP these are URIs

URIs

Uniform Resource Identifier

in a RESTful web service is a hyperlink to a resource

It is the only means for clients and servers to exchange representations of resources

ex.

.../orderinfo?id=123

URIs

The URI is not meant to change over time

à it is the only means to identify a specific resource

URIs are also used to negotiate representations of a given resource

In the URI you give certain parameters that define which information you want the server to return to you (just like giving GET variables to a page)

The server will respond with a resource representation containing the information you’ve asked

Roadmap

The REST Architectural Style

Resources

Representations

Actions

Representations

The representation of resources is what is sent back and forth between clients and servers

So, we never send or receive resources, only their representations

URL

Uniform Resource Locator

A URL is a specialization of URI that defines the network location of a specific resource

Unlike a URI, the URL defines how the resource can be obtained

es.

http://some.domain.com/orderinfo?id=123

URL

URIs and URLs are also used to link resources together

ex.

Representations

The format of the representation is determined by the content-type

The interaction of the representation on the resource is determined by the action (GET, SET, etc.)

Content-types

Since we are using HTTP to communicate, we can transfer any kind of information that can be passed between clients and servers

ex. text files, PDF documents, images, videos, etc.

In any case, the data is streamed over TCP/IP and the browser knows how to interpret the binary streams because of the HTTP protocol response header Content-Type

Representation Formats

Different clients are able to consume different representations of the same resource

A representation can take various forms, such as:

• image

• a text file

• an XML stream

• a JSON stream

but its resource has to be available through the same URI

Representation Formats

For human-generated requests through a web browser, a representation is typically in the form of an HTML page

For automated requests from other web services, readability is not as important and a more efficient representation can be used such as XML or JSON

Roadmap

The REST Architectural Style

Resources

Representations

Actions

Actions

Actions are used to operate on resources

For example, they can be used for

– getting info about a movie

– adding a photo to Flickr

– deleting a file from a folder

The data transmitted to and from the resource is a representation of it

HTTP-based Actions

Under HTTP, actions are standard HTTP request:

GET

POST

PUT

DELETE

They make up the uniform interface used for client/server data transfers

HTTP-based Actions

RESTful web services can also execute logic at the server level, but remember that every result must be a resource representation

HTTP as Uniform Interface

In RESTful systems we focus on resource names, whereas in traditional web systems we focussed on the actions to beperformed on resources

à In RESTful systems we have four specific actions that we can take upon resources — Create, Retrieve, Update, and Delete (CRUD)

In traditional web applications, we could have countless actions with no naming or implementation standards

The Classroom Example

Artificial example of a web service handling students in some classroom

Location of the service = http://restfuljava.com/

Resources are represented as XML streams

The Classroom Example: URIs

Student (identified by name):

http://restfuljava.com/students/{name}

List of students: http://restfuljava.com/students

The Classroom Example: Representations

Student:

<student>

<name>Jane</name><age>10</age>

<link>/students/Jane</link>

</student>

The Classroom Example: Representations

Students List:

<students><student>

<name>Jane</name><age>10</age><link>/students/Jane</link>

</student><student>

<name>John</name><age>11</age><link>/students/John</link>

</student></students>

GET

The method GET is used to RETRIEVE resources

It cannot have side-effects

à it can be done repeatedly without changing the state of the resource

It can also return only parts of the resource

à it can act as both a read operation and a query operation

GET Example

POST

The method POST is used to CREATE resources

Usually, the resource identity/URL is not known at creation time

à The URL of the newly created resource is usually createdautomatically by the server

POST Example

PUT

The method PUT is used to UPDATE resources

Recurrent PUT workflow:

1. we first GET the representation of the resource we need to update

2. in the client we update the resource with the new value(s)

3. we update the resource using a PUT request together with the representation as its payload

PUT Example

The initial GET is omitted here

DELETE

The method DELETE is used to DELETE resources

Similarly to PUT, also in this case we need the URI of the resourcebeing deleted

DELETE Example

A note on PUT and DELETE

PUT and DELETE apply to the entire resource

à when doing a PUT or DELETE operation,

the entire resource is replaced/deleted

The PUT and DELETE operations are atomic

à if two PUT/DELETE operations occur simultaneously,

one of them will win and determine the final state of

the resource

HTTP Status Codes

RESTful services use these codes to return information about the response of the requests

1xx informational message

2xx success message

3xx redirects the client to another URL

4xx client-side error

5xx server-side error

LAB

Extend the app of the previous labs so that products and producers are real data coming from the Loveitaly VM

Another example of Rest API: http://www.nestoria.co.uk/help/apihttp://api.nestoria.it/api?place_name=laquila&encoding=json&pretty=1&listing_type=buy&country=it&action=search_listings

References

http://bit.ly/JA1UPT

Cordova Facebook plugin:

http://goo.gl/7qY54

Facebook login without plugin:

http://github.com/ccoenraets/OpenFB

ContactIvano Malavolta |

Gran Sasso Science Institute

iivanoo

[email protected]

www.ivanomalavolta.com