RESTful services
-
Upload
pedram-bashiri -
Category
Software
-
view
68 -
download
1
Transcript of RESTful services
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
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
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(Architectural Constraints)
• Statelessness (HTTP)
• Specified Cacheability
• Interface Uniformity (URI)
• Addressability (URI)
• Connectedness (Hypermedia)
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(Architectural Constraints)
• Statelessness (HTTP)
• Specified Cacheability
• Interface Uniformity (URI)
• Addressability (URI)
• Connectedness (Hypermedia)
20
Interface Uniformity
• The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.
21
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
Interface Uniformity
• 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(Architectural Constraints)
• Statelessness (HTTP)
• Specified Cacheability
• Interface Uniformity (URI)
• Addressability (URI)
• Connectedness (Hypermedia)
26
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
Principles of REST(Architectural Constraints)
• Statelessness (HTTP)
• Specified Cacheability
• Interface Uniformity (URI)
• Addressability (URI)
• Connectedness (Hypermedia)
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
• 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
Designing RESTful applications
• Using a ReST supportive framework does not make your application ReSTful
53
Designing RESTful applications
• You need to model your application interfaces as a set of resources
• And basic CRUD operations on these resources
54
Designing RESTful applications
• 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
• 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
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