This content is part of the Essential Guide: Guide: When and how to use REST
Problem solve Get help with specific problems with your technologies, process and projects.

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.

"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

Learn about SOAP vs. REST for mobile apps

How developers make an open API easy to use

Incorporating security into RESTful API designs

 

Dig Deeper on Enterprise application integration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close