Essential Guide

Guide: When and how to use REST

A comprehensive collection of articles, videos and more, hand-picked by our editors

REST vs. SOAP: Choosing the best web service

SOAP and REST offer different methods to invoke a web service. Learn the variations between the two approaches, including integration concerns and client choices.

FROM THE ESSENTIAL GUIDE:

Guide: When and how to use REST

+ Show More

"I need to update the local inventory database with the inventory information from multiple suppliers. The suppliers...

provide a web service-based interface. As the application does not have any server side component (the application is a fat client talking directly to the database), is it possible to consume these web services directly from my application database?"

Do similar questions trouble you? Ever wondered what could be the solution to such an issue?

For a different perspective, the databases can act as the service consumer in contrast to the norm of acting as a service provider. Here is how you can invoke a web service via database-stored procedures -- and in explaining so, I'll address the differences of REST vs. SOAP.

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 proxies without 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

There are significant differences between SOAP and RESTful web services. The bullets below break down the features of each web service based on personal experience.

REST

  • RESTful web services are stateless. You can test this condition by restarting the server and checking if interactions survive.
  • For most servers, RESTful web services provide a good caching infrastructure over an HTTP GET method. This can improve the performance if the information the service returns is not altered frequently and is not dynamic.
  • Service producers and consumers must understand the context and content being passed along as there is no standard set of rules to describe the REST web services interface.
  • REST is useful for restricted-profile devices, such as mobile, for which the overhead of additional parameters are less (e.g., headers).
  • REST services are easy to integrate with existing websites and are exposed with XML so the HTML pages can consume the same with ease. There is little need to refactor the existing site architecture. As such, developers are more productive because they don't need to rewrite everything from scratch; instead, they just need to add on the existing functionality.
  • A REST-based implementation is simple compared to SOAP.

SOAP

  • The Web Services Description Language (WSDL) describes a common set of rules to define the messages, bindings, operations and location of the service. WSDL is akin to a contract to define the interface that the service offers.
  • SOAP requires less plumbing code than REST services design (e.g., transactions, security, coordination, addressing and trust). 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 don't need to write plumbing code into the application layer.
  • SOAP web services, such as JAX-WS, are useful for asynchronous processing and invocation.
  • SOAP supports several protocols and technologies, including WSDL, XSDs and WS-Addressing.

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. 

REST or SOAP: Which is best for me?

Proponents on both sides of the REST vs. SOAP discussion can be fervent in their advocacy for their web service architecture of choice. Both SOAP and RESTful architectures have proven themselves to be reliable, successful and capable of scaling infinitely, so the decision to use REST or SOAP has less to do with their efficacy and more to do with how either approach fits in with an organization’s software development culture and project needs.

Both SOAP web services and RESTful web services have proven their ability to meet the demands of the largest enterprise organizations in the world, while at the same time being able to service the smallest internet of things devices or embedded applications in production.

When choosing between REST and SOAP, two of the key topics to factor into the decision are:

  1. The types of clients that will be supported. For example, REST services offer an effective way for interacting with lightweight clients, such as smartphones.
  2. How varying degrees of flexibility and standardization will be either rebuffed or accepted by the organization’s corporate culture.

Keeping these factors in mind will go a long way in helping organizations to choose between SOAP and RESTful web services.

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.

Problem 1: Getting "ORA-25293 : HTTP request failed" error during procedure compilation.

Solution: Follow the steps below to rectify this.

  • Log in through sys user as sysdba.
  • View the privileges to the selected schema to use the utl_HTTP package by using the command as follows:
    • select grantee, table_name, privilege
      from dba_tab_privs
      where table_name = 'UTL_HTTP';

  • The grant will be provided to all the public users by default.
  • Revoke execute grant on utl_http from public and provide it explicitly to the specific schema from which the Web service needs to be invoked.
    • revoke execute on utl_http from public;

    • grant execute on utl_http to BTFT2;
    • select grantee, table_name, privilege
      from dba_tab_privs
      where table_name =  'UTL_HTTP';

Problem 2: If the stored procedure calling the Web service gives "Network access denied" during the call of Web service.

Solution: Add the Web service url to the access control list by following the steps below.

  • Login through sys as sysdba.
  • Execute the following procedure to create ACL.
    • BEGIN
      DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
           acl          => '<name of the acl file>.xml',
           description  => 'Permissions to access the web service url',
           principal    => '<Schema name>',
           is_grant    => TRUE,
           privilege    =>
      'connect');
      COMMIT;         
      END;         
      /

  • Create a role and then grant connect to this role on the ACL by using the steps below:
    • create role role1;

    • BEGIN

             DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE (
                                acl          => '<name of the acl file>.xml',               
                                principal   => 'role1',
                                is_grant     => TRUE,
                                privilege 
         => 'connect',
                                position     => null);
      COMMIT;
      END;

  • Assign the host names to the ACL to open all the related links in the host.
    • BEGIN
      DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
           acl          => '<name of the acl file>.xml',               
      host         => '*.<host name of the webservice url>');
      COMMIT;  
      END;  
      /

Or

    • BEGIN
      DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
            acl          => '<name of the acl file>.xml',               
      host         => '<ip>’);
      COMMIT;   
      END;

  • Confirm whether the domain has been added in the ACL using ACL_UTILITY package.
    • SELECT * FROM
      TABLE
      (DBMS_NETWORK_ACL_UTILITY.DOMAINS('www.ajax.googleapis.com'));
    • selectacl , host , lower_port , upper_port from DBA_NETWORK_ACLS;
    • selectacl , principal , privilege , is_grant from BA_NETWORK_ACL_PRIVILEGES;

Next Steps

SOAP vs. REST for mobile apps

Ask the expert: How can developers make an open API easy to use?

Incorporating security into RESTful API designs

 

This was last published in November 2016

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

Guide: When and how to use REST

Join the conversation

91 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Restful is easier to integrate and an API very well documented is better than wsdl
Cancel
I need some guidance and cmplete material on RestFul services
Cancel
SOAP
Cancel
REST - lightweight, use this for all communication between Mobile apps and Server.
Cancel
Configuration-related issues abound with SOAP. Is REST easier to debug?
Cancel
What a terrible, terrible article.
Incorrect in so many ways, and doesn't even come close to the stated title of when to use REST or SOAP.

Basically thesedays, the only reasons to use SOAP are if:
- it's the only thing provided by your tools
- it's all you know
- you don't like learning (even easy) things
- you have some fetish for outdated over-engineered tech
Cancel
SOAP is more secure than REST but the latter is light and can be easily handled
Cancel
Investigating
Cancel
still learning :)
Cancel
till now used SOAP more
Cancel
SOPA is on going process and REST services are need and requirement based.
Cancel
Want to more dig into it.
Cancel
It depends of the work needs to be done. In case of transactional work SOAP web services needs to be used where on other hand REST web services provides simplicity.
Cancel
correction in SOAP: JMS is not a protocol. it is an API. I think it is a typo.
Cancel
this is the best overview i have found. nice job
Cancel
Good one, I must say short & crisp.
It give me a short kind of revision & clarity in concepts after studying so much theory in details about WebServices.
Cancel
Its simple to use
Cancel
Is there any other type of services like these SOAP and REST??
Cancel
I havent used RESTful yet
Cancel
1. Light weight
2. Performance
3. Now as the world is moving from Heavy weight applications to apps and multiple devices support (Smart Phone, Tablet etc). REST opens up lot more client for the exposed WebService than SOAP.
Cancel
1 Light weight
2 Performance
3 Now as the world is moving from Heavy weight applications to apps and multiple devices support that is Smart Phone Tablet etc REST opens up lot more client for the exposed WebService than SOAP
Cancel

1. Light weight
2. Performance
3. Now as the world is moving from Heavy weight applications to apps and multiple devices support, i.e. Smart Phone Tablet etc. REST opens up lot more client for the exposed WebService than SOAP

Cancel
Because the data we are handling is not very complex and we are using the JSON for data transferring. JSON is more efficient than XML as it will be parsed faster than XML(JSON is already in the form of Javascript and all the browsers will understand ).
Ans also some of the browsers have inbuilt support for JSON
Cancel
unfamiliar with REST
Cancel
yes, it is easy to use and also doesn't have any restriction on using xml you can use json,csv and many more.
Cancel
easy to code and Rapid application development, management is also very easy.
security and other related stuff is no big deal.
Cancel
REST is flexible in terms of usage, can be used in mobile apps. fast execution.
Cancel
Rest
Cancel
In a lengthy business transaction, using REST is very difficult and required two much development effort.
Using SOAP, it is easy to develop and manage using the tools available in the market and make monitoring the lengthy process easy
Cancel
I didnt get chance to use rest services. Thats why i want to learn difference between these two.
Cancel
Soap is a standard structured web service.
Cancel
speed
Cancel
learning
Cancel
Because the most of our partners use SOAP. We are a service company in insurance field.
Cancel
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features..
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries
Cancel
It is easy to use. Support xml as well as json, lightweight. Also, REST is well documented which makes development easy.
Cancel
It's includes a well-defined self-documenting contract which reduces the need for external documentation and in many cases, depending on the soap server, provides automatic error checking with soap faults.
Cancel
Till now used SOAP and learning about REST.
Cancel
I am ready for some REST!
Cancel
Hiii " i recently used SOAP web services for accessing wcf services from android"
,but nw i'm porting to HTML5,now "how can i access those services"???
Cancel
Mostly working on Complex App, and Web Application only.
Cancel
REST is not reliable because HTTP DELETE can return OK status even if a resource is not deleted .where as SOAP is secured and Reliable
Cancel
Security is not an issue;Protocol is HTTP;Some of the web services were provided;Didn't have to learn a 3rd party WSDL, and the web service client would have to change if the WSDL changes.
Cancel
WSDL saves a lot time while service consumers. REST requires word documents to explain what operations are available what parameters to pass.
Cancel
It sounds like a lot of people are gravitating towards SOAP!
Cancel
soap services
Cancel
Because i am new to web services and for a starter REST is good
Cancel
legacy services were all developed as SOAP/HTTPS. All new services are being developed as REST/HTTPS - many legacy SOAP/HTTPS services are being reimplemented as REST/HTTPS
Cancel
While using REST my application performence is very good compare to SOAP.
Cancel
know less on REST.
Cancel
Hi kamprk,

Here is a link to some recent articles we published on REST. I hope it helps! http://ow.ly/u3Bio 
Cancel
Speed will better than SOAP
Cancel
its simple structure and simple to learn. and it's caching abilities
Cancel
Rest is faster, lightweight and easy to implement.
Cancel
because i don't think SOAP is difficult to learn or use if you're not trying to learn what you may not needed.
Cancel
SOA is a like tortoise, lots of shell and slow to develop.
REST is like a rabbit, bounce around a lot and you have to catch it 1st.
I prefer REST hands-down over SOA.
Cancel
Till production move...management asked us to go for SOAP. But when the test results came out, it was REST who won the battle.
Cancel
Yes,
Mr. ashrafwg say right,
In a lengthy business transaction, using REST is very difficult and required two much development effort.
Using SOAP, it is easy to develop and manage using the tools available in the market and make monitoring the lengthy process easy.

And another thing are
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
so seems all these reasons, I think SOAP is better than REST.
Cancel
Rest is new to me. I'm doing my first REST project now. Seems pretty easy. I may stop using soap all together after this project.
Cancel
Keep us posted on your project, mscrom! It's always nice when a different approach proves to work well.
Cancel
Easy to use
Cancel
Formal contract with external partners.
Cancel
In my experience, consuming SOAP service is extremely providing that you use the right tools. The WSDL is a data contract that allows you to programatically generate the classes you need to access the methods on the service. This means that passing or receiving complex types is simple, a benefit that REST does not enjoy. REST also requires that the service is adequately documented, whereas a WSDL serves as accurate documentation for any SOAP web service. If you are planning on consuming a SOAP service, make sure you use a code generation tool such as SvcUtil.exe (built into Visual Studio when you select "Add Service Reference") in order to make your life easier. Anyone who tells you that code generation tools are proof that SOAP is harder to use than REST is overlooking the fact that in a REST service I have no way of knowing what data the service expects or will return unless the developer has documented it. Try consuming a REST service with no documentation - you can't use a code generation tool because there is no data contract. Now try doing the same with SOAP - no problem, the WSDL is your documentation, so you know exactly how to interact with the service.
Cancel
easy to learn and start development
Cancel
A dedicated adapter is required to consume REST services and less secure than SOAP.
Cancel
Keep it simple. If RESTful web services are designed and documented well, they simply work.
Cancel
Json format
Cancel
It is more easy to use.
Cancel
My applications require more context to be maintained to facilitate collaberation. I would use REST if pushing my apps onto mobile architectures though.
Cancel
Several reasons, main reason easier to maintain. Change the back end anytime, easy to version. No WSDL worries.
Cancel
It sounds like whether REST or SOAP should be used depends on the project at hand.
Cancel
It is light weight, easy to maintain and easily scalable.
Cancel
DON'T HAVE THE CHOICE IN our current SAP version!?
Cancel
Fast & Flexible & Time-efficient development
Cancel
can u please share with me the related topics for both soap and REST .I am a beginner in this PF .
Cancel
Hi Sibaram! We have a lot of articles posted on REST and other integration methods here:  http://ow.ly/wukZt. I hope this helps!
Cancel
Currently i am working on SOAP . The reason is i don't have much knowledge on Restful web services.
Cancel
REST is a still new cup of coffee and need to explore
Cancel
Sundeepelec, I like the way you phrased your experience with REST!
Cancel
Easy to implement
Cancel
Project basis on rest
Cancel
we used earlier SOAP Model... currently migrating to RESTful services
Cancel
Sorry to tell you this, But the definition of web services itself is wrong..
Web services are mainly used for cross platform communication in distributed technologies, because the old distributed technologies like CORBA, RMI uses binary code, so which always uses the same technology across client and server. But whereas web-services uses neutral language called XML, which can be understood by any technology. that’s why web-services provides interoperability, and supports cross platform communications
Cancel
REST - lightweight, use this for all communication between Mobile apps and Server.
Cancel
Architectural decision
Cancel
I recently got to know about REST
Cancel
Pashamshaik, what are your thoughts on working with REST so far?
Cancel
I am using SOAP WSDL webservice using Axis framework [even though is not being updated from 2012] in my application from the past 5+ years.
Cancel
I've been on the receiving end of both as a tester, and while Soap's defined model may be easier to report, I've long wondered if REST is better, because APIs with better documentation (rather than relying on the discovery service) are actually better in the long run, and more maintainable.
Cancel
Rest is easier than SOAP.REST uses standard HTTP it is much simpler. Creating clients, developing APIs, the documentation is much easier to understand and there aren’t very many things that REST doesn’t do easier than SOAP.
Cancel
Do you more frequently use REST or SOAP Web services?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close