Service Oriented Computing

Akshaya Ganesan
Assistant Professor[Off-Campus]
BITS-Pilani
 Precap
Contact Session 2
• Service Terminology- Service, Service capability, Service contract, composition
• Service Models and Layers- Utility, Task, Entity
• Service-Related Granularity- Service, capability, Data, Constraint
• Service Orientation Design principles
• Service Orientation Goals and Benefits
• ESB and SOA
Agenda

• Introduction to REST (Representational State Transfer)

• REST architectural style
• REST constraints
• Goals of the REST architectural style
Module 4: REST based services
Contact Session 3
 REST - Concepts
REST stands for REpresentational State Transfer
• REST is an architectural style.
• REST was defined by Roy Fielding, a computer scientist
 The REST principles n his PhD dissertation in 2000

• A RESTful web service

 exposes information about itself in the form of information about its resources
 enables the client to take actions on those resources, such as
 create new resources (i.e. create a new user)
 update existing resources (i.e. edit a post)
• Resource
 Can be anything(docs, data, media, images) the web service can provide information about
 In Twitter's API, a resource can be a tweet and the user
 In Instagram’s API, a resource can be a user, a photo, a hashtag
 Each resource has a unique identifier - can be a name or a number
When a RESTful API is called, the server will transfer to the client a representation of the state of
the requested resource!
REST - example

• When a developer calls Instagram API to fetch a specific user (the resource)
 the API will return the state of that user, including
 their name
 the number of posts that user posted on Instagram so far
 how many followers they have
 and more

• The representation of the state can be in a JSON format

 probably for most APIs this is indeed the case
 but can also be in XML or HTML format
 Resources
The main building blocks of a REST architecture are the resources
• Representations: It can be any way of representing data (binary, JSON, XML, etc.). A single
resource can have multiple representations.
• Identifier: A URL that retrieves only one specific resource at any given time.
• Metadata: Content type, last-modified time, and so forth.
• Control data: Is-modifiable-since, cache-control.
REST – Server Working

• Server needs to know about 2 things, based upon which it takes some action and return the
response
 An identifier for the resource you are interested in
 URL for the resource, also known as the endpoint
 URL stands for Uniform Resource Locator
 The operation you want the server to perform on that resource
 in the form of an HTTP method, or verb
 common HTTP methods are GET, POST, PUT, and DELETE

• For example,
 fetching a specific Twitter user, using Twitter’s RESTful API, will require a URL that identify that user
and the HTTP method GET

 Twitter URL: www.twitter.com/jk_rowling has the unique identifier for J. K. Rowling’s Twitter user, which
is her username, jk_rowling
 Twitter uses the username as the identifier
 The HTTP method GET indicates that we want to get the state of that user
 REST and HTTP
REST is an architectural style and not a programming language or technology
• The fundamental principle of REST is to use the HTTP protocol for data communication.
• RESTful web service makes use of HTTP for determining the action to be carried out on the particular
resources
• REST gets its motivation from HTTP, therefore, it can be said as structural pillar of the REST

• HTTP is a document-based protocol, in which the client puts a document in an envelope and sends it
to the server.
• The server returns the favor by putting a response document in an envelope and sending it to the
client.
Basic HTTP features for REST

• HTTP is a protocol that

 permits to send and receive files over the internet
 Uses client-server architecture

• The essential features of HTTP are:

 HTTP is stateless because both the server and the client does not keep track of the last request
 Any data can be transmitted and received via the HTTP protocol, hence type-independent
 For identifying any resources implemented using REST or in general, as well as establishing any
connection, HTTP makes use of the Uniform Resource Identifier (URI)

• HTTP's request and response consist of the following four items:

 A starting line
 One or more headers
 A blank line that indicates the finish of the header field(s)
 And finally an optional message body
 HTTP Get Request
Image Ref: Book T2: Restful Web services Leonard Richardson and Sam Ruby

An HTTP GET request for http://www.oreilly.com/index.html The response to an HTTP GET request for http://www.oreilly.com/index.html
GET /index.html HTTP/1.1 HTTP/1.1 200 OK
Date: Fri, 17 Nov 2006 15:36:32 GMT
Host: www.oreilly.com
Server: Apache
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)... Last-Modified: Fri, 17 Nov 2006 09:05:32 GMT
Accept: Etag: "7359b7-a7fa-455d8264
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,... Accept-Ranges: bytes
Accept-Language: us,en;q=0.5 Content-Length: 43302
Accept-Encoding: gzip,deflate Content-Type: text/html
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 X-Cache: MISS from www.oreilly.com
Keep-Alive: 300 Keep-Alive: timeout=15, max=1000
Connection: keep-alive Connection: Keep-Alive

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
...
<title>oreilly.com -- Welcome to O'Reilly Media, Inc.</title>
-----
Standard HTTP Methods

• Commonly Used ones

 GET - to read (or retrieve) a representation of a resource
 POST - utilized to create new resources
 PUT - to update a resource
 PATCH - to modify a resource - only needs to contain the changes to the resource, not the complete
resource
 DELETE - to delete a resource identified by a URI.

• Rarely Used ones

 Head – requests the headers
 Options - requests permitted communication options for a given URL or server
 Method Information
How the client can convey its intentions to the server? In a SOAP, REST, RPC
• How does the server know a certain request is a request to retrieve some data, instead of a
request to delete that same data or to overwrite it with different data
• One way to convey method information in a web service is to put it in the HTTP method
A sample SOAP RPC call
POST search/beta2 HTTP/1.1
Host: api.google.com
Content-Type: application/soap+xml
SOAPAction: urn:GoogleSearchAction
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<gs:doGoogleSearch xmlns:gs="urn:GoogleSearch"> Part of the WSDL description for Google’s search
<q>REST</q> service
... <operation name="doGoogleSearch">
</gs:doGoogleSearch> <input message="typens:doGoogleSearch"/>
</soap:Body> <output message="typens:doGoogleSearchResponse"/>
</soap:Envelope> </operation>
XML-RPC Example

POST /rpc HTTP/1.1 Example 1-12. An XML document describing

Host: www.upcdatabase.com an XML-RPC request
User-Agent: XMLRPC::Client (Ruby 1.8.4) <?xml version="1.0" ?>
Content-Type: text/xml; charset=utf-8 <methodCall>
Content-Length: 158 <methodName>lookupUPC</methodName>
Connection: keep-alive <params>
<?xml version="1.0" ?> <param><value><string>001441000055</string></v
<methodCall> alue></param>
<methodName>lookupUPC</methodName> </params>
... </methodCall>
</methodCall>
 Scoping Information
how the client tells the server which part of the data set to operate on? In REST, SOAP, RPC
• http://flickr.com/photos/tags/penguin
• http://api.flickr.com/services/rest/?method=flickr.photos.search&tags=penguin

• One obvious place to put it is in the URI path.

• A RESTful, resource-oriented service exposes a URI for every piece of data the client might
want to operate on.
RESTful Webservices

• In RESTful web service, the method information goes into the HTTP method.
• The scoping information goes into the URI.
• Given the first line of an HTTP request to a RESTful web service
• (“GET /reports/open-bugs HTTP/1.1”),
• you should understand basically what the client wants to do.
• If the HTTP method doesn’t match the method information, the service isn’t RESTful.
• The service is not resource-oriented if the scoping information isn’t in the URI.

• http://www.upcdatabase.com/upc/00598491'
REST Constraints

• For an web service to be RESTful, it has to adhere to 6 constraints:

 Uniform interface
 Client - Server separation
 Stateless
 Layered system
 Cacheable
 Code-on-demand (Optional)

Image ref: Book Hands-on Restful api

Client - Server separation

• The client and the server act independently, each on its own
 Interaction between them is only in the form of
 requests initiated by the client only
 responses, which the server send to the client only as a reaction to a request

• The server just sits there waiting for requests from the client to come
 doesn’t start sending away information about the state of some resources on its own
 Responds only when request comes in
 Stateless
The statelessness constraint helps services to be more scalable and reliable.
• Stateless means the server does not remember anything about the user who uses the service
 doesn’t remember if the user already sent a GET request for the same resource in the past
 doesn’t remember which resources the user of the API requested before
 and so on...

• Each individual request contains all the information the server needs to perform the request and
return a response, regardless of other requests made by the same user.
• The client is responsible for sending any state information to the server whenever it's needed.
• No session stickiness or session affinity on the server for the calling request
 Cacheable

Explicit labelling of resource as cacheable or non-cacheable

• Data the server sends contain information about whether or not the data is cacheable

• If the data is cacheable, it might contain some sort of a version number

 version number is what makes caching possible

• client knows which version of the data it already has (from a previous response)
 the client can avoid requesting the same data again and again
• client should also know if the current version of the data is expired,
 will know it should send another request to the server to get the most updated data about the state of a
resource
 Uniform interface
The intention of a uniform interface is to retain some common vocabulary across the internet.
• There are four guiding principles suggested by Fielding that constitute the necessary constraints to
satisfy the uniform interface
• Identification of resources
• Manipulation of resources
• Self-descriptive messages
• Hypermedia as the engine of application state
• The request to the server has to include a resource identifier
• Each request to the web service contains all the information the server needs to perform the request
 Each response the server returns contain all the information the client needs to understand the response
• The response the server returns include enough information so the client can manipulate the
resource
• Hypermedia as the engine of application state
 Application mean the web application that the server is running
 Hypermedia mean the hyperlinks, or simply links, that the server can include in the response
 means that the server can inform the client , in a response, of the ways to change the state of the web
application
 HATEOS
Hypermedia as the Engine of Application State
Layered system

• Between the client who requests a representation of a resource’s state, and the server who
sends the response back
 there might be a number of servers in the middle
 servers might provide a security layer, a caching layer, a load-balancing layer etc.,
 layers should not affect the request or the response

• The client is agnostic as to how many layers, if any, there are between the client and the actual
server responding to the request.
Code-on-demand (Optional)

• Is optional — a web service can be RESTful even without providing code on demand

• The client can request code from the server

 response from the server will contain some code
 when the response is in HTML format, usually in the form of a script
• The client then can execute that code
REST- Example

• Lets say we have two resources

 Student
 Course

• URI for a particular student with ID 123

 http://localhost/institute/students/123
• URI for a particular course with ID 999
 http://localhost/institute/courses/999
 Example - CREATE
POST – to create a new resource

HTTP Method URI Operation

POST http://localhost/institute/students To create a new entry

Body
{
“Name” : “XYZ”,
“ Year” : “First”,
“DOB” : “25-04-1998”
}
 Example - GET
GET – retrieve the resource

HTTP Method URI Operation

GET http://localhost/institute/students For fetching information for all

students
GET http://localhost/institute/students/123 For fetching the student having
ID 123
 Example - Update
PUT– update the resource

HTTP Method URI Operation

PUT http://localhost/institute/students/123 For update the student record

having ID as 123
Body
{
“Name” : “XYZ”,
“ Year” : “Second”,
“DOB” : “25-04-1998”,
“Registered” : “Yes”
}
 Example - DELETE
DELETE– delete the resource

HTTP Method URI Operation

DELETE http://localhost/institute/students/123 For removing the student

record having ID number 123
Using HTTP Methods for RESTful Services

Entire Collection (e.g. Specific Item (e.g.

HTTP Verb CRUD /customers) /customers/{id})
POST Create 201 (Created), 'Location' 404 (Not Found), 409
header with link to (Conflict) if resource
/customers/containing new already exists..
ID.
GET Read 200 (OK), list of customers. 200 (OK), single customer.
Use pagination, sorting and 404 (Not Found), if ID not
filtering to navigate big found or invalid.
lists.
PUT Update/Replace 405 (Method Not Allowed), 200 (OK) or 204 (No
unless you want to Content). 404 (Not Found),
update/replace every if ID not found or invalid.
resource in the entire
collection.
PATCH Update/Modify 405 (Method Not Allowed), 200 (OK) or 204 (No
unless you want to modify Content). 404 (Not Found),
the collection itself. if ID not found or invalid.
DELETE Delete 405 (Method Not Allowed), 200 (OK). 404 (Not Found),
unless you want to delete if ID not found or invalid.
the whole collection—not
often desirable.
Architectural goals of REST

• Performance
• Scalability
• Simplicity
• Modifiability
• Visibility
• Portability
• Reliability
• Testability
References

1) Restful Web services, Leonard Richardson and Sam Ruby, 1 st edition published by O'Reilly
Media, May 2007 , Chapter 4, 8
Thank You!
In our next session: