0% found this document useful (0 votes)
71 views3 pages

SOAP Defines A Standard Communication Protocol (Set of Rules) Specification

Web services can be SOAP or REST. SOAP defines standard rules for XML-based message exchange using protocols like HTTP. REST describes principles for transmitting data over standardized interfaces like HTTP using operations like GET and POST. Whether to use SOAP or REST depends on factors like complexity of operations and need for formal contracts.

Uploaded by

Sahira Ira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
71 views3 pages

SOAP Defines A Standard Communication Protocol (Set of Rules) Specification

Web services can be SOAP or REST. SOAP defines standard rules for XML-based message exchange using protocols like HTTP. REST describes principles for transmitting data over standardized interfaces like HTTP using operations like GET and POST. Whether to use SOAP or REST depends on factors like complexity of operations and need for formal contracts.

Uploaded by

Sahira Ira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Web services overview

A Web service, in very broad terms, is a method of communication between two


applications or electronic devices over the World Wide Web (WWW). Web services
are of two kinds: Simple Object Access Protocol (SOAP) and Representational State
Transfer (REST).
SOAP defines a standard communication protocol (set of rules) specification
for XML-based message exchange. SOAP uses different transport protocols, such
as HTTP and SMTP. The standard protocol HTTP makes it easier for SOAP model to
tunnel across firewalls and proxieswithout any modifications to the SOAP protocol.
SOAP can sometimes be slower than middleware technologies
like CORBA or ICE due to its verbose XML format.
REST describes a set of architectural principles by which data can be transmitted
over a standardized interface (such as HTTP). REST does not contain an additional
messaging layer and focuses on design rules for creating stateless services. A client
can access the resource using the unique URI and a representation of the resource
is returned. With each new resource representation, the client is said to transfer
state. While accessing RESTful resources with HTTP protocol, the URL of the
resource serves as the resource identifier and GET, PUT, DELETE, POST and HEAD
are the standard HTTP operations to be performed on that resource.
REST vs. SOAP
Multiple factors need to be considered when choosing a particular type of Web
service, that is between REST and SOAP. The table below breaks down the features
of each Web service based on personal experience.
Pro+
Features
Enjoy the benefits of Pro+ membership, learn more and join.

E-Handbook

Embedded software, IoT development demand careful scrutiny

E-Handbook

Analytics, cloud services refashion business process management

E-Handbook

A new take on application integration and development


REST

The RESTful Web services are completely stateless. This can be tested by
restarting the server and checking if the interactions are able to survive.

Restful services provide a good caching infrastructure over HTTP GET method
(for most servers). This can improve the performance, if the data the Web
service returns is not altered frequently and not dynamic in nature.

The service producer and service consumer need to have a common


understanding of the context as well as the content being passed along as
there is no standard set of rules to describe the REST Web services interface.

REST is particularly useful for restricted-profile devices such as mobileand


PDAs for which the overhead of additional parameters like headers and other
SOAP elements are less.

REST services are easy to integrate with the existing websites and are
exposed with XML so the HTML pages can consume the same with ease.
There is hardly any need to refactor the existing website architecture. This
makes developers more productive and comfortable as they will not have to
rewrite everything from scratch and just need to add on the existing
functionality.

REST-based implementation is simple compared to SOAP.

SOAP

The Web Services Description Language (WSDL) contains and describes the
common set of rules to define the messages, bindings, operations and
location of the Web service. WSDL is a sort of formal contract to define the
interface that the Web service offers.

SOAP requires less plumbing code than REST services design, (i.e.,
transactions, security, coordination, addressing, trust, etc.) Most real-world
applications are not simple and support complex operations, which require
conversational state and contextual information to be maintained. With
the SOAP approach, developers need not worry about writing this plumbing
code into the application layer themselves.

SOAP Web services (such as JAX-WS) are useful in handling asynchronous


processing and invocation.

SOAP supports several protocols and technologies, including WSDL, XSDs,


SOAP, WS-Addressing

In a nutshell, when you're publishing a complex application program interface (API)


to the outside world, SOAP will be more useful. But when something with a lower

learning curve, and with lightweight and faster results and simple transactions
(i.e., CRUD operations) is needed, my vote goes to REST.
Invoking Web service via Oracle database stored procedure
Consuming a Web service via a database stored procedure allows users to straight
away update a database with information from different sources. Users can also
schedule a job at regular intervals to get data updated periodically in the database.
Oracle provides a "utl_http" utility to help achieve this. Below is sample code for the
Oracle package for a customer where the Web service call is made from the
database.
Common problems faced when invoking Web services and solutions
Sometimes, even after doing everything as expected in the stored procedure to call
the Web service, the procedure doesn't get compiled. The following is a compilation
of runtime errors faced during stored procedure execution to invoke a Web service
and their solutions.

You might also like