Professional Documents
Culture Documents
REST comparison
SOAP Web service
SOAP Layers
REST Layers
RESTFull WebServices
1
SOAP
RESTFull WebServices
2
Q3. How would you decide what style of Web Service to use? SOAP WS or REST?
A3. In general, a REST based Web service is preferred due to its simplicity, performance,
scalability, and support for multiple data formats. SOAP is favored where service requires
comprehensive support for security and transactional reliability.
The answer really depends on the functional and non-functional requirements. Asking the
questions listed below will help you choose.
1) Does the service expose data or business logic? (REST is a better choice for exposing
data, SOAP WS might be a better choice for logic).
2) Do consumers and the service providers require a formal contract? (SOAP has a formal
contract via WSDL)
3) Do we need to support multiple data formats?
4) Do we need to make AJAX calls? (REST can use the XMLHttpRequest)
5) Is the call synchronous or asynchronous?
6) Is the call stateful or stateless? (REST is suited for statless CRUD operations)
RESTFull WebServices
3
7) What level of security is required? (SOAP WS has better support for security)
8) What level of transaction support is required? (SOAP WS has better support for
transaction management)
9) Do we have limited band width? (SOAP is more verbose)
10) Whats best for the developers who will build clients for the service? (REST is easier to
implement, test, and maintain)
@Produces to specify the type of output this method (or web service) will produce.
@Consumes to specify the MIME media types a REST resource can consume
@Path to specify the URL path on which this method will be invoked.
@PathParam to bind REST style parameters to method arguments. For example
http://localhost:8080/context/accounting-services/PeterAndCo
@QueryParam to access parameters in query string
(http://localhost:8080/context/accounting-services?accountName=PeterAndCo).
@FormParam to read parameters sent in a POST request. REST resources usaually
consume XML/JSON, but at times you want to read the paramewters in POST.
HTTP methods
The PUT, GET, POST and DELETE methods are typical used in REST based architectures. The following
table gives an explanation of these operations.
GET defines a reading access of the resource without side-effects. The resource is never changed via
a GET request, e.g., the request has no side effects (idempotent).
DELETE removes the resources. The operations are idempotent. They can get repeated without
leading to different results.
RESTFull WebServices
4
WSDL Abstract:
WSDL is an XML based protocol for information exchange in decentralized and distributed environments.
WSDL definition describes how to access a web service and what operations it will perform.
WSDL 2.0
Term
Description
Service
Service
Contains a set of system functions that have been exposed to the Web-based protocols.
Port
Endpoint
Binding
Binding
Specifies the interface and defines the SOAP binding style (RPC/Document) and transport
(SOAP Protocol). The binding section also defines the operations.
PortType
Interface
Defines a Web service, the operations that can be performed, and the messages that are
used to perform the operation.
Operation
Operation
Defines the SOAP actions and the way the message is encoded, for example, "literal." An
operation is like a method or function call in a traditional programming language.
Message
n/a
Types
Types
Describes the data. The XML Schema language (also known as XSD) is used (inline or
referenced) for this purpose.
RESTFull WebServices
5
WSDL Usage:
WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client
program connecting to a web service can read the WSDL to determine what functions are available on the server.
Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then
use SOAP to actually call one of the functions listed in the WSDL.
History of WSDL
WSDL 1.1 was submitted as a W3C Note by Ariba, IBM and Microsoft for describing services for the W3C XML
Activity on XML Protocols in March 2001.
WSDL 1.1 has not been endorsed by the World Wide Web Consortium (W3C), however it has just (May 11th, 2005)
released a draft for version 2.0, that will be a recommendation (an official standard), and thus endorsed by the W3C.
Description:
The WSDL describes services as collections of network endpoints, or ports. The WSDL specifications provides an
XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their
concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address
with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data
being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data
format specifications for a particular port type constitutes a reusable binding, where the operations and messages
are then bound to a concrete network protocol and message format. In this way, WSDL describes the public
interface to the Web service.
The <definition> element must be the root element of all WSDL documents. It defines the name of the web service.
Here is the example piece of code from last session which uses definition element.
1.
2.
<definitions name="HelloWorldService"
targetNamespace="http://www.dineshonjava.com/wsdl/HelloWorldService.wsdl"
RESTFull WebServices
6
3.
4.
5.
6.
7.
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.dineshonjava.com/wsdl/HelloWorldService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
............................................
8.
9.
<definitions>
It also specifies numerous namespaces that will be used throughout the remainder of the document.
The <message> element describes the data being exchanged between the Web service providers and
consumers.
The input describes the parameters for the Web Service and the output describes the return data from the
Web Service.
Each message contains zero or more <part> parameters, one for each parameter of the Web Service's
function.
Each <part> parameter associates with a concrete type defined in the <types> container element.
Lets take a piece of code from the Example Session:
1.
2.
3.
4.
5.
6.
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
Here, two message elements are defined. The first represents a request message SayHelloRequest, and the second
represents a response message SayHelloResponse.
Each of these messages contains a single part element. For the request, the part specifies the function parameters; in
this case, we specify a single firstName parameter. For the response, the part specifies the function return values; in
this case, we specify a single greeting return value.
RESTFull WebServices
7
The <portType> element combines multiple message elements to form a complete oneway or round-trip operation.
For example, a <portType> can combine one request and one response message into a single request/response
operation. This is most commonly used in SOAP services. A portType can define multiple operations.
Lets take a piece of code from the Example Session:
1.
2.
3.
4.
5.
6.
<portType name="HelloWorld_PortType">
<operation name="sayHelloWorld">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
Operation Types
The request-response type is the most common operation type, but WSDL defines four types:
Type
Definition
One-way
Request-response
Solicit-response
The operation can send a request and will wait for a response
Notification
The operation can send a message but will not wait for a
response
One-way :
The service receives a message. The operation therefore has a single input element. The grammar for a one-way
operation is:
1.
2.
3.
4.
5.
6.
Request-response:
The service receives a message and sends a response. The operation therefore has one input element, followed by
one output element. To encapsulate errors, an optional fault element can also be specified. The grammar for a
RESTFull WebServices
8
1.
2.
3.
4.
5.
6.
7.
8.
9.
Solicit-response:
The service sends a message and receives a response. The operation therefore has one output element, followed by
one input element. To encapsulate errors, an optional fault element can also be specified. The grammar for a solicitresponse operation is:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Notification :
The service sends a message. The operation therefore has a single output element. Following is the grammar for a
notification operation:
1.
2.
3.
4.
5.
6.
7.
The <binding> element provides specific details on how a portType operation will actually be transmitted
over the wire.
The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.
The bindings provide concrete information on what protocol is being used to transfer portType operations.
The bindings provide information where the service is located.
RESTFull WebServices
9
For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top
of HTTP protocol.
You can specify multiple bindings for a single portType.
The binding element has two attributes - the name attribute and the type attribute.
<binding name="HelloWorld_Binding" type="tns:HelloWorld_PortType">
The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this
case the "tns:HelloWorld_PortType" port.
SOAP Binding
WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAP specific details,
including SOAPheaders, SOAP encoding styles, and the SOAPAction HTTP header. The SOAP extension elements
include:
soap:binding
This element indicates that the binding will be made available via SOAP. The style attribute indicates the overall style
of theSOAP message format. A style value of rpc specifies an RPC format.
The transport attribute indicates the transport of the SOAP messages. The
value http://schemas.xmlsoap.org/soap/httpindicates the SOAP HTTP transport,
whereas http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.
soap:operation
This element indicates the binding of a specific operation to a specific SOAP implementation.
The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service.
soap:body
This element enables you to specify the details of the input and output messages. In the case of HelloWorld, the
body element specifies the SOAP encoding style and the namespace URN associated with the specified service.
Here is the piece of code from Example section:
RESTFull WebServices
10
The <service> element defines the ports supported by the Web service. For each of the supported protocols,
there is one port element. The service element is a collection of ports.
Web service clients can learn from the service element where to access the service, through which port to
access the Web service, and how the communication messages are defined.
<service name="HelloWorld_Service">
<documentation>WSDL File for HelloWorldService</documentation>
<port binding="tns:HelloWorld_Binding" name="HelloWorld_Port">
<soap:address
location="http://www.dineshonjava.com/SayHelloWorld/">
</port>
</service>
The binding attributes of por element associate the address of the service with a binding element defined in the Web
service. In this example this is HelloWorld_Binding
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
A <port> element defines an individual endpoint by specifying a single address for a binding.
The port element has two attributes - the name attribute and the binding attribute.
RESTFull WebServices
11
The name attribute provides a unique name among all ports defined within in the
enclosing WSDL document.
The binding attribute refers to the binding using the linking rules defined by WSDL.
A port MUST NOT specify any binding information other than address information.
Here is the piece of code from Example session:
1.
2.
3.
4.
5.
6.
7.
<service name="HelloWorld_Service">
<documentation>WSDL File for HelloWorldService</documentation>
<port binding="tns:HelloWorld_Binding" name="HelloWorld_Port">
<soap:address
location="http://www.dineshonjava.com/SayHelloWorld/">
</port>
</service>
Question 4 : Can you tell me which API can be used to develop RESTFul web service in Java?
Answer : There are many framework and libraries out there which helps to develop RESTful web services in
Java including JAX-RS which is standard way to develop REST web services. Jersey is one of the popular
implementation of JAX-RS which also offers more than specification recommends. Then you also have
RESTEasy, RESTlet and Apache CFX. If you like Scala then you can also use Play framework to develop
RESTful web services.
Question 9 : Have you used Jersey API to develop RESTful services in Java?
Answer : Jersey is one of the most popular framework and API to develop REST based web services in Java.
Since many organization uses Jersey they check if candidate has used it before or not. It's simple to answer, say
Yes if you have really used and No, if you have not. In case of No, you should also mention which framework
you have used for developing RESTful web services e.g. Apache CFX, Play or Restlet.
RESTFull WebServices
12
Question 15 : How much maximum pay load you could do in POST method?
Answer : If you remember difference between GET and POST request then you know that unlike GET which
passes data on URL and thus limited by maximum URL length, POST has no such limit. So, theoretically you
can pass unlimited data as payload to POST method but you need to take practical things into account e.g.
sending POST with large payload will consume more bandwidth, take more time and present performance
challenge to your server.
Question 17 : If you have to develop web services which one you will choose SOAP OR RESTful and
why?
RESTFull WebServices
13
Answer : You can answer this question based upon your experience but the key here is if you know difference
between them than you can answer this question in more detail. For example, its easy to develop RESTful web
services than SOAP based web services but later comes with some in-built security features.
That's all in this list of some good RESTful web service interview questions for Java developers. Though
this list is meant for Java developer, you can use this questions to check any candidate's knowledge on REST
style web services independent of programming language because REST doesn't say that you need to
implement web service in Java only. Since it take advantage of ubiquitous HTTP protocol you can build backed
with any web technology stack e.g. Java, .NET or any other.
1.
Interoperability: Web services are accessible over network and runs on HTTP/SOAP
protocol and uses XML/JSON to transport data, hence it can be developed in any
programming language. Web service can be written in java programming and client can be
PHP and vice versa.
Reusability: One web service can be used by many client applications at the same time.
Loose Coupling: Web services client code is totally independent with server code, so we
have achieved loose coupling in our application.
RESTFull WebServices
14
SOAP Web Services: Runs on SOAP protocol and uses XML technology for sending data.
Restful Web Services: Its an architectural style and runs on HTTP/HTTPS protocol almost
all the time. REST is a stateless client-server architecture where web services are resources
and can be identified by their URIs. Client applications can use HTTP GET/POST methods to
invoke Restful web services.
2.
What is SOAP?
SOAP stands for Simple Object Access Protocol. SOAP is an XML based industry standard
protocol for designing and developing web services. Since its XML based, its platform and
language independent. So our server can be based on JAVA and client can be on .NET, PHP
etc. and vice versa.
3.
WSDL document provides contract and technical details of the web services for client
applications without exposing the underlying implementation technologies.
SOAP uses XML data for payload as well as contract, so it can be easily read by any
technology.
SOAP protocol is universally accepted, so its an industry standard approach with many
easily available open source implementations.
RESTFull WebServices
15
Only XML can be used, JSON and other lightweight formats are not supported.
SOAP is based on the contract, so there is a tight coupling between client and server
applications.
SOAP is slow because payload is large for a simple string message, since it uses XML
format.
Anytime there is change in the server side contract, client stub classes need to be generated
again.
What is WSDL?
WSDL stands for Web Service Description Language. WSDL is an XML based document
that provides technical details about the web service. Some of the useful information in
WSDL document are: method name, port types, service end point, binding, method
parameters etc.
xsd:import namespace and schemaLocation: provides WSDL URL and unique namespace
for web service.
What is UDDI?
RESTFull WebServices
16
UDDI is acronym for Universal Description, Discovery and Integration. UDDI is a directory of
web services where client applications can lookup for web services. Web Services can
register to the UDDI server and make them available to client applications.
RESTFull WebServices
17
Supports multiple technologies for data transfer such as text, xml, json, image etc.
Since there is no contract defined between service and client, it has to be communicated
through other means such as documentation or emails.
RESTFull WebServices
18
REST
technical details.
details.
WSDL contract
client
contract.
RESTFull WebServices
19
RESTFull WebServices
20
Content-Type header is used to tell server what is the format of data being sent in the
request. If Content-Type header is application/xml then server will try to parse it as XML
data. This header is useful in HTTP Post and Put requests.
Do you know your web service clients beforehand? If Yes, then you can define a contract
before implementation and SOAP seems better choice. But if you dont then REST seems
better choice because you can provide sample request/response and test cases easily for
client applications to use later on.
How much time you have? For quick implementation REST is the best choice. You can
create web service easily, test it through browser/curl and get ready for your clients.
What kind of data format are supported? If only XML then you can go with SOAP but if you
think about supporting JSON also in future then go with REST.
RESTFull WebServices
21
@WebService
@SOAPBinding
@WebMethod
package com.journaldev.jaxws.service;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.ws.Endpoint;
RESTFull WebServices
22
@WebService
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class TestService {
@WebMethod
public String sayHello(String msg){
return "Hello "+msg;
}
When I run above program and then access the WSDL, it gives me below XML.
rpc.xml
<?xml
version='1.0' encoding='UTF-8'?>
<definitions xmlns:wsu="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://service.jaxws.journaldev.com/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://service.jaxws.journaldev.com/"
name="TestServiceService">
<types/>
<message name="sayHello">
<part name="arg0" type="xsd:string"/>
</message>
<message name="sayHelloResponse">
<part name="return" type="xsd:string"/>
</message>
<portType name="TestService">
<operation name="sayHello">
<input
wsam:Action="http://service.jaxws.journaldev.com/TestService/sayHel
loRequest" message="tns:sayHello"/>
<output
wsam:Action="http://service.jaxws.journaldev.com/TestService/sayHel
loResponse" message="tns:sayHelloResponse"/>
</operation>
RESTFull WebServices
24
</portType>
<binding name="TestServicePortBinding" type="tns:TestService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="rpc"/>
<operation name="sayHello">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"
namespace="http://service.jaxws.journaldev.com/"/>
</input>
<output>
<soap:body use="literal"
namespace="http://service.jaxws.journaldev.com/"/>
</output>
</operation>
</binding>
<service name="TestServiceService">
<port name="TestServicePort" binding="tns:TestServicePortBinding">
<soap:address location="http://localhost:8888/testWS"/>
</port>
</service>
</definitions>
RESTFull WebServices
25
Notice that types element is empty and we cant validate it against any schema. Now just
change theSOAPBinding.Style.RPC to SOAPBinding.Style.DOCUMENT and you will get below
WSDL.
document.xml
<?xml
version='1.0' encoding='UTF-8'?>
RESTFull WebServices
26
<message name="sayHello">
<part name="parameters" element="tns:sayHello"/>
</message>
<message name="sayHelloResponse">
<part name="parameters" element="tns:sayHelloResponse"/>
</message>
<portType name="TestService">
<operation name="sayHello">
<input
wsam:Action="http://service.jaxws.journaldev.com/TestService/sayHel
loRequest" message="tns:sayHello"/>
<output
wsam:Action="http://service.jaxws.journaldev.com/TestService/sayHel
loResponse" message="tns:sayHelloResponse"/>
</operation>
</portType>
<binding name="TestServicePortBinding" type="tns:TestService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="sayHello">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
RESTFull WebServices
27
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="TestServiceService">
<port name="TestServicePort" binding="tns:TestServicePortBinding">
<soap:address location="http://localhost:8888/testWS"/>
</port>
</service>
</definitions>
Open schemaLocation URL in browser and you will get below XML.
schemaLocation.xml
<?xml
version='1.0' encoding='UTF-8'?>
RESTFull WebServices
28
<xs:complexType name="sayHello">
<xs:sequence>
<xs:element name="arg0" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="sayHelloResponse">
<xs:sequence>
<xs:element name="return" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
So here WSDL document can be validated against the schema definintion.
RESTFull WebServices
29
sun-jaxws.xml
<?xml
version="1.0" encoding="UTF-8"?>
<endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
version="2.0">
<endpoint
name="PersonServiceImpl"
implementation="com.journaldev.jaxws.service.PersonServiceImpl"
url-pattern="/personWS"/>
</endpoints>
Jersey: Jersey is the reference implementation provided by Sun. For using Jersey as our
JAX-RS implementation, all we need to configure its servlet in web.xml and add required
dependencies. Note that JAX-RS API is part of JDK not Jersey, so we have to add its
dependency jars in our application.
2.
RESTFull WebServices
30
We can use wsimport utility to generate the client stubs. This utility comes with standard
installation of JDK. Below image shows an example execution of this utility for one of JAXWS project.
3.
@Path: used to specify the relative path of class and methods. We can get the URI of a
webservice by scanning the Path annotation value.
@GET, @PUT, @POST, @DELETE and @HEAD: used to specify the HTTP request type for a
method.
@PathParam: used to bind the method parameter to path value by parsing it.
RESTFull WebServices
31
RESTFull WebServices
32
Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport
protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.
SOAP enables client applications to easily connect to remote services and invoke remote methods.
Other frameworks, including CORBA, DCOM, and Java RMI, provide similar functionality to SOAP, but SOAP
messages are written entirely in XML and are therefore uniquely platform- and language-independent.
Why SOAP?
It is important for application development to allow Internet communication between programs.
Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA,
but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers
will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers
and servers. SOAP was created to accomplish this.
SOAP provides a way to communicate between applications running on different operating systems, with different
technologies and programming languages.
History
SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen AlGhosein for Microsoft, where Atkinson and Al-Ghosein were working at the time. The SOAP specification is currently
maintained by the XML Protocol Working Group of the World Wide Web Consortium.
SOAP originally stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the
standard. Version 1.2 became a W3C recommendation on June 24, 2003. The acronym is sometimes confused with
SOA, which stands for Service-oriented architecture, but the acronyms are unrelated.
After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on
Web Services Description Language (WSDL) and Universal Description Discovery and Integration (UDDI). These
services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete
understanding of the expected role of SOAP compared to how web services have actually evolved.
RESTFull WebServices
33
Envelope: ( Mandatory )
Defines the start and the end of the message.
Header: ( Optional )
Contains any optional attributes of the message used in processing the message, either at an intermediary point or at
the ultimate end point.
Body: ( Mandatory )
Contains the XML data comprising the message being sent.
Fault: ( Optional )
An optional Fault element that provides information about errors that occurred while processing the message
All these elements are declared in the default namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and the default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding
NOTE: All these specifications are subject to change. So keep updating yourself with the latest specifications
available W3 website.
Syntax Rules
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
RESTFull WebServices
34
5.
6.
7.
8.
9.
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
10.
11.
<SOAP-ENV:Body>
12.
13.
14.
15.
16.
17.
18.
19.
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
20.
21.
</SOAP_ENV:Envelope>
RESTFull WebServices
35