REST vs. SOAP: Choosing the best web service

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;