Web-Services

Web-Services are the medium to communicate between isolated software programs resides on the different machines across the world. Machines use web-services to communicate among them over the internet. Web-Services are the front end interfaces for the applications resides on the end-users devices like: mobiles, tabs, laptops, desktops etc..

When the user wants any data which resides on the server side then the web-services comes into the picture which transmitted the end-user’s request to the server and gets the response to present in-front of the user. These web-services provide the API’s that are responsible for the communication. These API’s can use different architectural style to communicate over the internet. We have basically two different API’s i.e. SOAP and REST. An API receives requests and sends back responses through various internet protocols such as HTTP, SMTP, UDP etc.. Many social media platform provide public APIs for their users, let’s say, Google Maps has a public REST API that lets you customize Google Maps with your own content.

What does REST stand for?

REST is abbreviated as Representational State Transfer. It’s an architectural style that defines a set of recommendations to create loosely coupled applications. This uses the HTTP protocol for data transmission. REST doesn’t prescribe how to implement the principles at a lower level. Instead, the REST guidelines allow developers to implement the details according to their own needs. RESTful web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations. By using a stateless protocol and standard operations, RESTful systems aim for fast performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system as a whole, even while it is running

While creating the Rest web-services API, you need to consider Six guiding constraints define a RESTful system:

Client–server architecture:

The principle behind the client–server constraints is the separation of concerns. Separating the user interface concerns from the data storage concerns improves the portability of the user interface across multiple platforms.

Statelessness:

The client–server communication is constrained by no client context being stored on the server between requests.

Cacheability:

Clients and intermediaries can cache responses.

Code on demand (optional)

Servers can temporarily extend/customize the functionality of a client by transferring executable code: for example, compiled components such as Java applets, or client-side scripts such as JavaScript.

Uniform interface

It simplifies and decouples the architecture, which enables each part to evolve independently.

Why we choose Rest over SOAP?

To build the public API’s Rest is the most democratic choice of the developers. One of the main benefits to build public API’s is that we can integrate different applications in to one. Now days, we can see that there are a lot of social media applications which uses Rest API so that developers from different platform can easily integrate with their platform. These public APIs also come with detailed documentation where you can get all the information you need to pull data through the API.

Let’s say, Facebook/Twitter/LinkedIn has a number of public REST APIs that all serve different purposes, such as a Search API with which you can find historical tweets/messages, a Direct Message API with which you can send personalized messages, and an Ad API with which you can pro-grammatically manage your ad campaigns.

JSON

The REST architecture structure provides the options to API developers to deliver data in multiple formats such HTML, XML, JSON, which is one of the most acceptable feature of Rest. Among the various formats – JSON is most widely used because of its lightweight and readability features. JSON is also easy to parse and can easily be integrated with any other application.

As JSON is the most popular format for data exchange in Rest, we should know more something about this. JSON abbreviated as JavaScript Object Notation. It’s an easy-to-parse and lightweight data-interchange format. Despite of its name, JSON is completely language-independent, so it can be used with any programming language, not just with JavaScript. It follows the Standard of ECMA-262. JSON files consist of collections of name/value pairs and ordered lists of values.

JSON Example:

{
  "menu": {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {
          "value": "New",
          "onclick": "CreateNewDoc()"
        },
        {
          "value": "Open",
          "onclick": "OpenDoc()"
        },
        {
          "value": "Close",
          "onclick": "CloseDoc()"
        }
      ]
    }
  }
}

Same JSON in xml:

<menu id="file" value="File">

  <popup>

    <menuitem value="New" onclick="CreateNewDoc()" />

    <menuitem value="Open" onclick="OpenDoc()" />

    <menuitem value="Close" onclick="CloseDoc()" />

  </popup>

</menu>

What does SOAP stand for?

SOAP (abbreviated as Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML for communication, and uses application layer protocols, most often HTTP, SMTP for message transmission. SOAP works on three major features: extensibility, neutrality and independence.

SOAP allows clients to invoke web services and receive responses independent of language and platforms. It is an XML-based protocol consisting of three parts:

• An envelope, which defines the message structure and how to process it.
• A set of encoding rules for expressing instances of application-defined data-types
• A convention for representing procedure calls and responses.

Some of the main feature of SOAP is Security, authorization, and error-handling which are built in protocol and, on the other hand REST, it doesn’t assume direct point-to-point communication. Hence, SOAP it performs well in a distributed enterprise environment.

SOAP message format:

POST /InStock HTTP/1.1

Host: www.example.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: "http://www.w3.org/2003/05/soap-envelope"

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org">

  <soap:Header>

  </soap:Header>

  <soap:Body>

    <m:GetStockPrice>

      <m:StockName>GOOG</m:StockName>

    </m:GetStockPrice>

  </soap:Body>

</soap:Envelope>

Why we use SOAP, if we have Rest with numerous benefits?

SOAP will continue to be used for the web services that require high security and complex transactions like financial services applications, payment gateways, CRM software, identity management, and telecommunication services some of the commonly used examples of SOAP.

Some of the big giants of the market uses both SOAP and Rest like Salesforce, Facebook, LinkedIn etc..

SOAP can be an excellent solution in situations where you can’t use REST. Although these days, most web service providers want to exchange stateless requests and responses, in some cases, you may need to process stateful operations. This happens in scenarios where you have to make a chain of operations act as one transaction, for instance, in the case of bank transfers.

SOAP vs. REST

SOAP and Rest both are API’s which allows you to create your own API. SOAP is a standard protocol that sends messages using other protocols such as HTTP and SMTP. The SOAP specifications follow the world wide standards as per the World Wide Web Consortium (W3C). On the other hand REST is not a protocol but an architectural style. The REST architecture provides you a set of guidelines you need to follow if you want to provide a RESTful web service, for example, stateless existence and the use of HTTP status codes.

SOAP is an official protocol, it comes with protocols which you must follow and advanced security features such as default ACID compliance and authorization. Due to higher complex structure, it requires more bandwidth and resources which lead to slower page load times. On the Other hand REST came into picture to overcome the SOAP’s concerns. Therefore it has a more flexible architecture. It consists of only loose guidelines and provides the flexibility to developers to implement in their own way. It allows you to different messaging formats, such as HTML, JSON, XML, and plain text, while SOAP only allows XML.

REST is lightweight architecture as compare to SOAP, so RESTful web services have a better performance. Because of that, it has become incredibly popular now days where fraction of times considers in terms of page load.