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

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

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 that
restricts the roles and features of architectural elements, and the allowed
relationships between those elements within any architecture that conforms
to that style
● A style can be applied to many architectures
● An architecture can consist of many styles
11

Principles of REST
(ArchitecturalConstraints)
• 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

Principles of REST
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

Principles of REST
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

Principles of REST
26

Addressability through URIs
27

Resources
• Every distinguishable entity is a resource.
• A resource may be aWeb site, an HTML page, an XML document, aWeb
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

Principles of REST
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 StateTransfer?"
• The Client references aWebresource 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 becomesTransactionApproval
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

References and Sources
• REST Explained Representational StateTransfer: presentation by Dhananjay Nene
• RESTfulWeb Services: presentation by Imran MYousuf
• Restful web services: presentation by Angelin
• RESTfulWeb 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

RESTful services

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to RESTful services

Similar to RESTful services (20)

Recently uploaded

Recently uploaded (20)

RESTful services

Editor's Notes