REST

A brief presentation by Pradeep

1
 Table of contents

• 1. Title Page

• 2. Table of Contents

• 3. History

• 4. Overview

• 5. Overview(continued)

• 6. Web sphere commerce[example of how REST works]

• 7. Characteristics

• 8. REST constraints

• 9. Types of constraints

• 10. Advantage over SOAP technology

• 11. References

2
 History
• REST is basically a network architectural style.
• It was coined by Roy Fielding in his Ph.D. dissertation in 2000.

3
 Overview
• Resources are clearly defined and addressed.
• Domain specific data is transmitted by REST over HTTP.
• REST does not have any SOAP messaging layer or HTTP cookies.
• The web is comprised of resources e.g. BMW cites Z4 Coupe as a resource
• A representation is returned e.g. Z4Coupe.html
• Such a representation puts the client application in a state.
• Accessing another hyperlink, e.g. accessories transfers the client application into another state.

4
 Overview (continued)
• There is no W3C specification[EDIT: There is an XML case that has such an API: eXist].
• REST is built on the following concepts:
• HTTP(transferring mechanism)
• URL(resource address)
• XML/HTML/GIF/JPEG(Resource representations)
• Text/XML, text/HTML, image.gif, image/jpeg, (MIME types)

5
Web sphere commerce[example of how
REST works]

6
 Characteristics
• Traversing links pull representations(pull based client server interaction)
• Each request must be self-sufficient, not taking advantage of any storage resource(stateless)
• Capability of storing responses to frequent requests (cacheable or non-cacheable)
• Resources are access via (HTTP) GET, POST, PUT, DELETE(uniform interface)
• Every resource is named using an URL(named resource)
• Resources are interconnected using URLs(interconnected resource representations)
• Intermediate components, e.g. proxy servers, gateways, firewalls, etc. can be inserted between clients and resources for performances, security(layered
components)

7
 REST constraints
• Client/Server constraints
• Separation of Concerns
• Independent Evolution of components
• Stateless Constraints
• Single request reveals everything
• Easier to recover from failures
• Server does not commit resources to each request
• May degrade network performance when having large requests
• Coaching constraint
• Eliminates interactions
• Clients have the “right” to reuse cacheable data
• May degrade reliability due to stale data

8
 Types of constraints
• Uniform interface constraint
• Implementation decoupled from interfaces
• Adapting degrades constraint
• Layered system constraint
• Architecture can be built hierarchically
• Added Overhead
• Code-on-demand(inactive code is executed on the client when the user requests it)

9
Advantage over SOAP technology

Structure Accessibility Extensibility Performance Security

REST Inter-connections GET, PUT, POST and Yes, through links GET based URIs Can apply
(hyperlinks) DELETE(uniform are cacheable {GET,PUT,
interface) POST,
DELETE}
permissions to a
data object

SOAP RPC CO paradigm of Specific and numerous Cannot refer to Not cached by Have to
encapsulating data methods other objects existing implement
outside the technology suitable strategy
system

10
 REFERENCES
• www.wikipedia.com
• https://en.wikipedia.org/wiki/SOAP
• http://xfront.com/REST-Web-Services.htm
• https://www.ibm.com/support/knowledgecenter/en/SSZLC2_8.0.0/com.ibm.commerce.webservices.doc/concepts/cwvrest.htm

11