Web Services

Ever always, whenever I come across this topic/question, I don’t have a very appropriate answer to it. So here I am summarizing my understanding of web services.

A Web service is a method of communication between two applications or electronic devices over the World Wide Web (WWW).

Two types to access web services: Simple Object Access Protocol (SOAP) and Representational State Transfer (REST).

SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use.

REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services.

However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.

Both SOAP and REST share similarities over the HTTP protocol; however, SOAP has a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information.

Let us get to know these types in further detail.


  • SOAP relies exclusively on XML to provide messaging services.
  • SOAP defines a standard communication protocol (set of rules) for this XML-based message exchange.
  • Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process.
  • One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work.
  • 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 middle-ware technologies like CORBA or ICE due to its verbose XML format.



  • Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.
  • REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases.
    • In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.
  • Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.
  • REST describes a set of architectural principles by which data can be transmitted over a standardized interface (such as HTTP).
  • 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.
  • OData (Open Data Protocol) is an OASIS standard that defines a set of best practices for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. .


The Bottom Line: When to Use SOAP Or REST

Some people say that one process is better than the other, but this statement is incorrect. Each protocol has definite advantages and equally problematic disadvantages. You need to select between SOAP and REST based on the programming language you use, the environment in which you use it, and the requirements of the application. Sometimes SOAP is a better choice and other times REST is a better choice. In order to avoid problems later, you really do need to chart the advantages and disadvantages of a particular solution in your specific situation.

However, having said that REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve and is always faster. Hence, when a complex application program interface (API) is being published to the outside world, SOAP will be more useful. For rest of the situation, REST will work.

Hope this gives a fair explanation to the topic.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s