Table of content

1. What are Web Services?
2. What are SOAP web services?
   • Roles in SOAP web services
   • Main Operations in SOAP web services
   • Standards/Components in SOAP web services
3. What are REST web services?
   • What is a resource in REST?
   • When is a service considered RESTful?
4. Conclusion

Web applications we create have always been heterogeneous. We use different programming languages, frameworks, platforms, and third-party services. Some languages provide speed, and some provide access to the machine level. Some services offer better plans, and some frameworks may better suit the requirements.

Whatever is the reason, we need a common medium to establish communication and interoperability between components of our application. For such situations, we use web services.

What are Web Services?

Web Service is a collection of open protocols and standards that creates a system for data exchange and interoperability between web applications. Web services are usually based on:

1. SOAP web services (based on XML protocol)
2. REST web services (based on RESTful architecture)

In most books and articles, web services are strongly associated with XML-based technologies only because the idea of using XML tech for this purpose precedes RESTful architecture. But in this article, we are taking it as a general concept of a standardized system only that helps in data exchange and interoperability.

Web services generally place themselves in between client and server. The client invokes the services it needs through a series of request messages and server responses with appropriate data. Web services use different protocols (HTTP, SMTP), and data formats (XML document, JSON) to facilitate this communication. Web services are also often referred to as SOA (Service-Oriented Architecture).

What are SOAP web services?

SOAP (Simple Object Access Protocol) web services are standardized XML-based messaging protocol that uses HTTP or SMTP for transmission. It means such SOAP web services primarily use XML to describe and standardize their data and documents.

Roles in SOAP web services

1. Service Provider: Platform that host the services or web applications.
2. Service Registry: Logically centralized directory where the service provider can publish their service description to be discovered and used by the service requestor. It is also called UDDI (Universal Description, Discovery, and Integration)
3. Service requestor: Platform that consumes the provided services or web applications.

Main Operations in SOAP web services

1. Publish: A service provider publishes its service description in a service registry. WSDL (XML-based language) is used as a standard format to describe the services or web applications.
2. Find: The service requestor retrieves the service description. It is performed either during design time or during runtime invocation.
3. Bind: The service requestor initiates an interaction with the service provider using the information found in the service registry. This information helps to locate, contact, and invoke the web applications hosted by the service provider.

Standards/Components in SOAP web services

1. UDDI (Universal Description, Discovery, and Integration)
   UDDI is an XML-based framework functioning like a directory that provides a mechanism for describing, registering, and discovering web services on the internet. It is platform-independent.

2. WSDL (Web Services Description Language)
   WSDL is an XML-based language used by a service provider for describing web service interfaces. It describes how to access a service, the parameters needed by the services, and what operations it will perform.

3. SOAP (Simple Object Access Protocol)
   SOAP is an XML-based standard communication protocol for creating messages and communicating over an HTTP or SMTP network. A service requestor creates a SOAP request packet and invokes a web application method. Then the service provider responds to the method call by creating a SOAP response packet.

Below is an example of a SOAP request and response message for a book price. It has a predefined structure that it follows.

• <soap:Envelope> tag marks the xml file as a SOAP message
• optional <soap:Header> tag gives application specific information like transactional, authentication, payment.
• <soap:Body> tag represents actual SOAP message. Generally, it describes the application method name, argument name, and its values.

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
  <soap:Header>
    <t:Transaction xmlns:t="some-URI" soap:mustUnderstand="1">
    </t:Transaction>
  </soap:Header>

  <soap:Body>
    <m:GetBookPrice xmlns:m="http://www.example.com/book">
      <title>Indian Cook Book</title>
      <author>John Doe</author>
    </m:GetBookPrice>
  </soap:Body>
</soap:Envelope>

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
  <soap:Body xmlns:m="http://www.example.com/book">
    <m:GetBookPriceResponse>
        <m:Price>25.5</m:Price>
    </m:GetBookPriceResponse>
  </soap:Body>
</soap:Envelope>

What are REST web services?

REST (REpresentational State Transfer) is a faster, scalable, and lightweight alternative to SOAP. It is an architectural approach that provides guidelines and constraints on how to design a network-based system, and represent data and services for that system.

What is a resource in REST?

Data like files, images, databases, etc are represented logically as a resource. The resource creates an abstraction layer to simplify representations of data. Resource maintains its unique URI (Uniform Resource Identifier) on the web. A resource can be requested using URI and be manipulated using standard HTTP methods/operations such as GET, POST, PUT, and DELETE. Response to such a request will represent the state of the resource. This representation can be in any possible standard format like JSON (most preferred), XML, text, or HTML.

When is a service considered RESTful?

REST defines some criteria to consider a service or an API RESTful:

• Client-server architecture

The system follows the separation of concerns principle. It separates into a client (UI), server, and resources (data storage concern). Such a system simplifies each component, improves scalability, and most importantly, allows components to evolve independently

• Statelessness

This constraint indicates stateless communication protocols where no client information is stored between requests and each request is separate, self-contained, and unconnected. It makes a suitable use case for high-volume transactional applications, increasing performance.

• Catchability

The response should implicitly or explicitly define itself as either cacheable or non-cacheable to prevent stale or inappropriate data in the client's response. This will streamline client-server interactions.

• Layered system

Hidden from the client, a server can be maintained in layers. Each layer can perform extra functionality such as proxy, load-balancer, and security. Each layer retrieves requested information to perform respective operations.

• Code on demand (optional)

A server can maintain layers where each layer performs extra functionality such as proxy, load-balancer, and security. Each layer retrieves requested information to perform respective operations.

• Uniform interface

  • Resource identification in requests: A unique URI identifies a resource in every request. The resources are conceptually different from the representation returned to the client.
  • Resource manipulation through representations: Resources can be manipulated by the client via the representation in response. It holds enough information to do so.
  • Self-descriptive messages: The response message includes enough information that helps to process the message. E.g: which parser to invoke, the data type of message, etc.
  • HATEOAS (Hypermedia as the engine of application state): After accessing a resource (like the homepage to a website), the REST client should be able to use hyperlinks dynamically and recursively discover all the available resources it needs.

Conclusion

SOAP web services are suitable for enterprise solutions and distributed systems. It is heavily standardized and is strict in that sense. It works with both HTTP and SMTP protocols. It offers you many open pre-build extensible modules. It also supports built-in error handling.

SOAP has a steep learning curve, and may not suit faster, and lighter builts and projects. Following standards is often difficult and time-consuming. So be wise with what modules you use in your SOAP systems.

REST on the other handle is lightweight, scalable, and faster. You can learn, and implement REST in less time and steps. It doesn't have standards to follow which is flexible but you may waste time figuring out the "best practices".