RESTful services

RESTful Web Services

By Pedram Bashiri

University of North Carolina at Charlotte

Spring 2015

1

Web Server

• Software designed to serve web pages/web sites/web services. Examples are IIS, Apache, etc.

Web Service

• Application run by a web server, performing tasks and returning structured data to a calling program, rather than html for a browser.

• Publicly available and standardized for use by all programmers

2

Types of Web Services

3

Service-Oriented Web Services

• Based on “services”

• “Big” Web Services

• JAX-WS = JAVA-API for XML-based Web Services, mainly using WSDL/SOAP

Resource-Oriented Web Services

• Based on “resources”

• RESTfulWeb Services

• JAX-RS = JAVA-API for RESTful Web Services, using only HTTP

4

REST= REpresentational State Transfer

5

What REST is not !

6

REST is not

A framework

7

REST is not

A technology

8

REST is not

A standard specification

9

REST is an architecture style

10

architecture style

An architecture style is a coordinated set of architectural constraints thatrestricts the roles and features of architectural elements, and the allowedrelationships between those elements within any architecture that conformsto that style

●A style can be applied to many architectures

●An architecture can consist of many styles

11

Principles of REST(Architectural Constraints)

• Statelessness (HTTP)

• Specified Cacheability

• Interface Uniformity (URI)

• Addressability (URI)

• Connectedness (Hypermedia)

12

Statelessness

No Client State

13

Statelessness

Each request from client to server must contain all of the information necessary to understand the request and cannot take any advantage of any

stored context on the server.

and

Each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have

preceded it

14

Statelessness

• Improved visibility since a monitoring system does not have to look beyond a single request

• Improved reliability due to easier recoverability from partial failures

• Improved scalability due to not having to allocate resources for storing state

• Server does not have to manage resource usage across requests

15

Statelessness

Tradeoff

• Reduced Network Performance

• Reduced server control over application consistency

16







17

Specified Cacheability

• Data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable

• If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests

18

Specified Cacheability

• Improves efficiency, scalability and user perceived performance

• Tradeoff : Reduced Reliability

19







20

Interface Uniformity

• The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.

21


Uniform Operations

22

In REST over HTTP these are

• GET= "give me some info" (Retrieve)

• POST= "here's some info to update” (Update)

• PUT= "here's some new info" (Create)

• DELETE= "delete some info" (Delete)

23

Those are the only verbs you need

• Simplifies semantics

• Simplifies client complexity

• Simplifies application model

24


• Tradeoff : Degrades efficiency

• Since Information is transferred in a standard form rather than one which is specific to application's needs

25







26

Addressability through URIs

27

Resources

• Every distinguishable entity is a resource.

• A resource may be a Web site, an HTML page, an XML document, a Web service, an image, a video etc.

28

Addressability

• Every resource is uniquely identified by a URI.

• The URI should generally carry no meaning to the client except as a resource locator

29

Addressability

• Good, clean, structured URIs are helpful for developers

• If you are naming a specific single resource all the information to locate the resource should be in the URI itself and not through additional parameters

30

Addressability

eg. Choose

http://informationbase/locationdb/citiestable/pune

not

http://informationbase/locator?type=city&name=pune

31







32

Connectedness

• RESTful services representations are hypermedia documents.

• These are documents that contain not just data, but links to other resources by serving “hypermedia”:

• The quality of having links is called “connectedness”. Resources should link to each other in their representations.

• Hence, why the human web is easy to use because it is well connected.

33

Representations

• Resources have Representations

• A representation captures the current or intended state of a resource

• Representations are transferred between the client and the server

34

http://www.boeing.com/aircraft/747

<?xml version="1.0"?> <aircraft><model>747</model><mfgYr>2000</mfgYr></aircraft>

35

http://www.boeing.com/aircraft/747/maintenanceSchedule

<?xml version="1.0"?> <aircraft><model>747</model><mfgYr>2000</mfgYr><lastMntc>02-02-02<lastMntc><nextMntc>12-12-12<nextMntc></aircraft>

36

Why is it called "Representational State Transfer?"

• The Client references a Webresource using a URL.

• A representation of the resource is returned.

• The representation (e.g., Boeing747.html) places the client in a new state.

• When the client selects a hyperlink in Boeing747.html, it accesses another resource.

• The new representation places the client application into yet another state.

• Thus, the client application transfers state with each resource representation.

37

Representations

• A particular resource may have multiple representations

• Commonly used representation formats are html, xml and json

• however they could also be pdf, png etc.

38

Representations

• When multiple resource formats are supported by the server, the actual resource format returned is subject to content negotiation between the client and the server

39

Representations

This should ideally happen through control data i.e. By using HTTP “Accept” headers and not by appending additional information to the URL.

Prefer

Accept: text/xml;q=0.5, application/json

http://infobase/cities/pune

to

http://infobase/cities/pune.json

40

The Biggest RESTful system?!

ReST extends the very capabilities that made WWW successful into application design and architecture

What are these characteristics of static WWW and ReST?

41

WWW and ReST

You can connect to any web server if you know the home page URL

You can connect to ReST application if you know the starting URI

42

WWW and ReST

On the home page you can view the content along with the appropriate hyperlinks which suggest appropriate paths for you to traverse

The response will provide you important initial content along with hyperlinks which describe their nature to navigate to other resources

43

WWW and ReST

You can save the hyperlink URL, bookmark it or email it to you boss or tweet it to your friends

A ReST client can store a URI for future use or embed it as a foreign key in other resources that it maintains

44

WWW and ReST

You can save the contents of any page by saving its HTML representation

You can save the representation of any resource into a XML / Document database

45

WWW and ReST

You can modify the contents of the web pages by entering data in forms (and even full page content in blogs, Wikis etc.) and POSTing them.

You can perform PUT, POST and DELETE operations on resources to modify them

46

WWW and ReST

The server retains no information about the pages you've traversed

The server retains no information about you or the resources you've used

47

WWW and ReST

Did you notice there is no global internet registry for website discovery ?

There is no registry required for ReST applications

48

REST and Security

This is one area where I choose to be non-ReSTful

49

REST and Security

• Sometimes the deliberate requirements of security and transparency of ReST don't cooperate well

50

REST and Security

• Cookies can help in user identification (other options being Basic HTTP authentication)

• Basic HTTP Authentication is weak while cookies are strictly used for user identification only

• But cookies break the statelessness model!

51

Designing RESTful applications

• Tools

• .NET

• Windows Communication Services (WCF)

• Java

• Spring MVC

• JAX-RS: RESTEasy, RESTLet

52


• Using a ReST supportive framework does not make your application ReSTful

53


• You need to model your application interfaces as a set of resources

• And basic CRUD operations on these resources

54


• Answer these questions in order:

1. What are the resources of your application? What Are the URIs?

2. What is the representational format for the resources?

3. What methods are supported at each URI?

4. What status code could be returned for each method?

55


56

• As you move from an action oriented design towards resource oriented design, thinking of everything as nouns is one of the early challenges to overcome

Transaction.approve becomes TransactionApproval

Account.pay becomes AccountPayment.create

etc.

57

A look forward to increasing ReST popularity

ReST already is starting to dominate the internet space and there's a good likelihood it could dominate enterprise architectures as well.

58

59

References and Sources

• REST Explained Representational State Transfer: presentation by Dhananjay Nene

• RESTful Web Services: presentation by Imran M Yousuf

• Restful web services: presentation by Angelin

• RESTful Web Services: presentation by Christopher Bartling, Nick Spilman, Kevin Hakanson

• www.slideshare.com

• www.whatisrest.com

• www.Wikipedia.com

• www.stackoverflow.com

• www.filecatalyst.com/the-connectedness-principle-in-rest/

60

http://www.slideshare.com/

http://www.whatisrest.com/

http://www.wikipedia.com/

http://www.stackoverflow.com/

http://www.filecatalyst.com/the-connectedness-principle-in-rest/

61