Web Services - SOAP & REST

 A Web Service is an application deployed on a machine (server). 

 Web services accept incoming requests from client and send response to client in either plain text, JSON or XML format.

web services is they are language independent. So a web service written in Python can be requested from a client written in Java, C#, Ruby etc.

Web services are classified into two categories:

• SOAP – In SOAP-based web services both client and service transfer SOAP messages to communicate.
• REST – While in REST-style services both client and service usually transfer raw XML to communicate.

Java provides API for creating both SOAP and REST-style web services

JAX-WS – JAX-WS (Java API for XML Web Services) is a Java API for creating both SOAP and REST-style web services. There is a common misconception that JAX-WS is only for SOAP-based services, which is not true. Using JAX-WS you can create both SOAP and REST-style services

JAX-RS – JAX-RS (Java API for RESTful Web Services) is a Java API to write RESTful web services easily

===================================================================

SOAP (Simple Object Access Protocol) 

REST (Representation State Transfer)

What is payload?

When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. The header identifies the source and destination of the packet, while the actual data is referred to as the payload. In general, payload is the data that is carried on behalf of an application and the data received by the destination system.

<name>Arin</name>

or

"name": "Arin"

sending data over the network in Json format is cheaper than sending it in Xml format in terms of payload.

Here is the first benefit or advantages of REST over SOAP.

SOAP only support XML, but REST supports different format like text, JSON, XML etc


SOAP supports only XML, but it also has its own advantages.

1. SOAP is a protocol. REST is an architectural style.
2. SOAP stands for Simple Object Access Protocol. REST stands for REpresentational State Transfer.
3. SOAP can't use REST because it is a protocol. REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
4. SOAP uses services interfaces to expose the business logic. REST uses URI to expose business logic.
5. In Java JAX-WS is the java API for SOAP web services. In Java JAX-RS is the java API for RESTful web services.
6. SOAP defines standards to be strictly followed. REST does not define too much standards like SOAP.
7. SOAP requires more bandwidth and resource than REST. REST requires less bandwidth and resource than SOAP.
8. SOAP defines its own security. RESTful web services inherits security measures from the underlying transport.
9. SOAP permits XML data format only. REST permits different data format such as Plain text, HTML, XML, JSON etc.
10. SOAP is less preferred than REST. REST more preferred than SOAP.

=====================================================================

Why Rest?

• Since REST uses standard HTTP it is much simpler in just about ever way.
• REST permits many different data formats where as SOAP only permits XML.
• REST allows better support for browser clients due to it’s support for JSON.
• REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
• If security is not a major concern and we have limited resources. Or we want to create an API that will be easily used by other developers publicly then we should go with REST web services.
• If we need Stateless CRUD operations.

Why SOAP?

• WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
• WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP.
• WS-ReliableMessaging: If your application needs Asynchronous processing and a guaranteed level of reliability and security. Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
• SOAP is highly secure as it defines its own security.
• If the security is a major concern and the resources are not limited then we should use SOAP web services. Like if we are creating a web service for banking related work then we should go with SOAP as here high security is needed.

======================================================================

REST fundamentals

• Everything in REST is considered as a resource.
• Every resource is identified by an URI.
• Uses uniform interfaces. Resources are handled uing POST, GET, PUT, DELETE operations which are similar to Create, Read, update and Delete(CRUD) operations.
• Be stateless. Every request is an independent request. Each request from client to server must contain all the information necessary to understand the request.
• Communications are done via representations. E.g. XML, JSON RESTful Web Services A RESTFul web services are based on HTTP methods and the concept of REST. A RESTFul web service typically defines the base URI for the services, the supported MIME-types (XML, text, JSON, user-defined, ...) and the set of operations (POST, GET, PUT, DELETE) which are supported.

SOAP fundamentals

• WSDL defines contract between client and service and is static by its nature.
• SOAP builds an XML based protocol on top of HTTP or sometimes TCP/IP.
• SOAP describes functions, and types of data.
• SOAP is a successor of XML-RPC and is very similar, but describes a standard way to communicate.
• Several programming languages have native support for SOAP, you typically feed it a web service URL and you can call its web service functions without the need of specific code.
• Binary data that is sent must be encoded first into a format such as base64 encoded.
• Has several protocols and technologies relating to it: WSDL, XSDs, SOAP, WS-Addressing.

SOAP vs REST?

One of the major benefits of SOAP is that you have a WSDL service description. You can pretty much discover the service automatically and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth). Note that with version 2.0, WSDL supports all HTTP verbs and can be used to document RESTful services as well, but there is a less verbose alternative in WADL (Web Application Description Language) for that purpose.

With RESTful services, message security is provided by the transport protocol (HTTPS), and is point-to-point only. It doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

One of the major benefits of RESTful API is that it is flexible for data representation, for example you could serialize your data in either XML or JSON format. RESTful APIs are cleaner or easier to understand because they add an element of using standardised URIs and gives importance to HTTP verb used (i.e. GET, POST, PUT and DELETE).

RESTful services are also lightweight, that is they don’t have a lot of extra xml markup. To invoke RESTful API all you need is a browser or HTTP stack and pretty much every device or machine connected to a network has that.

Advantages of REST

• Since REST uses standard HTTP it is much simpler in just about ever way. Creating clients, developing APIs, the documentation is much easier to understand and there aren’t very many things that REST doesn’t do easier/better than SOAP.
• REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.
• REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
• No expensive tools require to interact with the Web service
• Smaller learning curve
• Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
• Fast (no extensive processing required)
• Closer to other Web technologies in design philosophy

Advantages of SOAP

• WS-Security : While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services have no need for, in fact they are really only needed in a few “enterprise” scenarios.
• WS-AtomicTransaction : Need ACID Transactions over a service, you’re going to need SOAP. While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. Fortunately ACID transactions almost never make sense over the internet. REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps generally don’t need this level of transactional reliability, enterprise apps sometimes do.
• WS-ReliableMessaging : Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
• Language, platform, and transport independent (REST requires use of HTTP)
• Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
• Standardized
• Provides significant pre-build extensibility in the form of the WS standards
• Built-in error handling
• Automation when used with certain language products

Where to use REST

areas where REST works really well for are:

• Limited bandwidth and resources: remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
• Totally stateless operations: if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
• Caching situations: if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.

Where to use SOAP

areas where SOAP works as a great solutionare:

• Asynchronous processing and invocation: if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
• Formal contracts: if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
• Stateful operations: if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

=====================================================================

SOAP

1. SOAP is a protocol.
2. SOAP stands for Simple Object Access Protocol.
3. SOAP can't use REST because it is a protocol.
4. SOAP uses services interfaces to expose the business logic.
5. SOAP defines standards to be strictly followed.
6. SOAP requires more bandwidth and resource than REST.
7. SOAP defines its own security.
8. SOAP permits XML data format only.
9. SOAP is less preferred than REST.

REST

1. REST is an architectural style.
2. REST stands for Representational State Transfer.
3. REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
4. REST uses URI to expose business logic.
5. REST does not define too much standards like SOAP.
6. REST requires less bandwidth and resource than SOAP.
7. RESTful web services inherits security measures from the underlying transport.
8. REST permits different data format such as Plain text, HTML, XML, JSON etc.
9. REST more preferred than SOAP.

==========================================================================