In the last lecture we have discussed about the different possible solutions for remote service invocation and have chosen to spend some more time on Web services. Lets start our discussion of web services.
Web services are like online apis which are available for clients to invoke. Typically clients invoke web services via http as a protocol. Some of the popular examples of online apis are api.twitter.com (web services twitter provides using which clients can post tweets, fetch tweets etc). Similarly facebook provides some web services using which one can query profile information, friends list, recent posts etc.
These days you find very less amount of development happening over desktop applications. Almost all the development is around trying to build products/services which are to be hosted on the cloud and be accessible over the web. This is one of the primary reason for increased popularity of web services and the demand for people who can develop them.
SOAP Web Services:
SOAP stands for Simple Object Access Protocol. A protocol is a set of rules to be used for communication between two parties. If your client and service provider are communicating via SOAP protocol they are called SOAP Services. SOAP is an xml based protocol i.e the request and responses are xml based and these are called SOAP request and SOAP response.
Lets say if the method signature of a web service is as below soap request and response would like below.
Method Signature
int getEmployee ( int employeeId );
Request
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getEmployee
xmlns:ns1="urn:EmployeeServices">
<param1 xsi:type="xsd:int">123</param1>
</ns1:getEmploye>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Response
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body>
<ns1:getEmployeeResponse xmlns:ns1="urn:EmployeeServices"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
<return xsi:type="xsd:int">246</return>
</ns1:getEmployeeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP services have to follow the protocol for successful service invocation. Typically SOAP services use http as the underlying data transfer protocol. The steps involved in the communication are
SOAP was widely used sometime back and is still in use by some systems. The biggest problem with SOAP services is they consume lot of n/w bandwith due to the envelop size. This is one of the reasons for REST web services to be more popular than SOAP web services.
HTTP fundamentals
URL: Uniform Resource Locator. This is the fundamental way to refer to anything over the web via http. No two webpages in the web will have same url. It is like an address to the web page. The web is not just made up of web pages. It is made up of services, java script files amd many more collectively called as Resources. The idea of URL is applicable to all these resource types.
E.g
http://localhost:8000/myWebApp/index.html is the url for the home page of your webapp you are developing locally
http://yourbansite/checkBalance.do?accountId=1234
Above is the url for the struts action class which is used to check the account balance.
The point to remember is in the web each resource can be accessed via a url.
HTTP methods:
Below are the most commonly used methods in http protocol
HTTP Headers
Content-type The MIME type of the body of the request (used with POST and PUT requests)
E.g : Content-Type: application/x-www-form-urlencoded
b Content-Types that are acceptable for the response
E.g: Accept: text/plain
HTTP Status codes:
The most commonly used http status code are as below
Successful 2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred.
Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is having an error condition.
REST Web Services
You might think REST is also a protocol like SOAP. It is not a protocol and rather it is an architectural style of writing services. If that style of writing services is applied to web services they are called REST Web services. We will discuss about that style shortly.
REST webservices typically are accessed using plain http protocol. Compare this with SOAP where on top of http you have another protocol. REST services make clever use of the strenghs of http protocol and allow communication.
If you observe closely each SOAP envelope is having all the information required for the server like which class to load which method to invoke, which parameters to pass. In REST services there is no envelope or something we only have http protocol. All the information related to the service like which method to call which class to load everything has to be specified in the single http request. This is where the cleverness in REST idea becomes clear.
REST makes use of the URI and http methods combination to get the communication done.
Let's say we have a EmployeeService class as below
public class EmployeeService {
public List<Employee> getEmployees(){
}
public Employee createEmployee(Employee e){
}
public Employee updateEmployee( Employee e){
}
public void deleteEmployee(Employee e){
}
}
In REST each service class is referred to as a Web resource. Given that each web resource has to have a url we wil have a unique url for each resource in the system. Let us say the url for the employee service is http://MyWebSite/employees
Also let say we have configured some how that when ever a http GET call is made to the url above getEmployees() is called. Similarly we have configured the other http methods as well. Summarizing all the http invocations on the url below
If you take any resource in the web the valid actions on the resource are always CRUD operations. Once you have mapped the http methods to these resource operations essentially you have covered all. Basically using a combination of url and method type we can do the CRUD operations. This is the idea behind REST services. This same problem of CRUD operations is solved by SOAP using a new protocol where as REST does it cleverly.
Web services are like online apis which are available for clients to invoke. Typically clients invoke web services via http as a protocol. Some of the popular examples of online apis are api.twitter.com (web services twitter provides using which clients can post tweets, fetch tweets etc). Similarly facebook provides some web services using which one can query profile information, friends list, recent posts etc.
These days you find very less amount of development happening over desktop applications. Almost all the development is around trying to build products/services which are to be hosted on the cloud and be accessible over the web. This is one of the primary reason for increased popularity of web services and the demand for people who can develop them.
SOAP Web Services:
SOAP stands for Simple Object Access Protocol. A protocol is a set of rules to be used for communication between two parties. If your client and service provider are communicating via SOAP protocol they are called SOAP Services. SOAP is an xml based protocol i.e the request and responses are xml based and these are called SOAP request and SOAP response.
Lets say if the method signature of a web service is as below soap request and response would like below.
Method Signature
int getEmployee ( int employeeId );
Request
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getEmployee
xmlns:ns1="urn:EmployeeServices">
<param1 xsi:type="xsd:int">123</param1>
</ns1:getEmploye>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Response
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body>
<ns1:getEmployeeResponse xmlns:ns1="urn:EmployeeServices"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
<return xsi:type="xsd:int">246</return>
</ns1:getEmployeeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP services have to follow the protocol for successful service invocation. Typically SOAP services use http as the underlying data transfer protocol. The steps involved in the communication are
- Client prepares a SOAP envelop containing the SOAP body, SOAP headers and sends it to the server.
- This envelop is embedded in a http data packet and sent as a http request. The request will be Post always. The request will have information about which class and in that class which method to invoke.
- On the server side from the http request the SOAP envelop is extracted.
- From the SOAP envelop the server understands which service class to load and in that class which method to call.
- The service will be invoked and the response is again sent as a SOAP envelop over http protocol to the client
SOAP was widely used sometime back and is still in use by some systems. The biggest problem with SOAP services is they consume lot of n/w bandwith due to the envelop size. This is one of the reasons for REST web services to be more popular than SOAP web services.
HTTP fundamentals
URL: Uniform Resource Locator. This is the fundamental way to refer to anything over the web via http. No two webpages in the web will have same url. It is like an address to the web page. The web is not just made up of web pages. It is made up of services, java script files amd many more collectively called as Resources. The idea of URL is applicable to all these resource types.
E.g
http://localhost:8000/myWebApp/index.html is the url for the home page of your webapp you are developing locally
http://yourbansite/checkBalance.do?accountId=1234
Above is the url for the struts action class which is used to check the account balance.
The point to remember is in the web each resource can be accessed via a url.
HTTP methods:
Below are the most commonly used methods in http protocol
- GET: The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
- POST: A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.
- PUT: Replaces all current representations of the target resource with the uploaded content.
- DELETE: Removes all current representations of the target resource given by a URI.
- HEAD: Same as GET, but transfers the status line and header section only. Typically used to see if the service is available before invoking GET.
HTTP Headers
Content-type The MIME type of the body of the request (used with POST and PUT requests)
E.g : Content-Type: application/x-www-form-urlencoded
b Content-Types that are acceptable for the response
E.g: Accept: text/plain
HTTP Status codes:
The most commonly used http status code are as below
Successful 2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
- 200 OK - Succesful http request and response
- 201 - New resource is created on the server side.
Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred.
- 400 - Bad request due to some syntax errors
- 401 - Unauthorized access
- 403 - Forbidden request. Even authorized users wont be able to access the url
- 404 - Not found. The requested resource is not avaialble at the url
- 408 - client timeout. The client did not respond in time
- 415 - unsupported media type. The client send a diffrent data format from what is expected from the server
Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is having an error condition.
- 500 - Internal server error. Some exception happened at the server while processing the requestBad request due to some syntax errors
- 501 - Not implemented. The server side resource does not have the method client requested
REST Web Services
You might think REST is also a protocol like SOAP. It is not a protocol and rather it is an architectural style of writing services. If that style of writing services is applied to web services they are called REST Web services. We will discuss about that style shortly.
REST webservices typically are accessed using plain http protocol. Compare this with SOAP where on top of http you have another protocol. REST services make clever use of the strenghs of http protocol and allow communication.
If you observe closely each SOAP envelope is having all the information required for the server like which class to load which method to invoke, which parameters to pass. In REST services there is no envelope or something we only have http protocol. All the information related to the service like which method to call which class to load everything has to be specified in the single http request. This is where the cleverness in REST idea becomes clear.
REST makes use of the URI and http methods combination to get the communication done.
Let's say we have a EmployeeService class as below
public class EmployeeService {
public List<Employee> getEmployees(){
}
public Employee createEmployee(Employee e){
}
public Employee updateEmployee( Employee e){
}
public void deleteEmployee(Employee e){
}
}
In REST each service class is referred to as a Web resource. Given that each web resource has to have a url we wil have a unique url for each resource in the system. Let us say the url for the employee service is http://MyWebSite/employees
Also let say we have configured some how that when ever a http GET call is made to the url above getEmployees() is called. Similarly we have configured the other http methods as well. Summarizing all the http invocations on the url below
- GET - > getEmployees()
- POST -> createEmployee()
- PUT -> updateEmployee()
- DELETE ->deleteEmployee()
If you take any resource in the web the valid actions on the resource are always CRUD operations. Once you have mapped the http methods to these resource operations essentially you have covered all. Basically using a combination of url and method type we can do the CRUD operations. This is the idea behind REST services. This same problem of CRUD operations is solved by SOAP using a new protocol where as REST does it cleverly.
No comments:
Post a Comment