web-services - webservices - when to use soap and rest web services
SOAP vs REST(differences) (8)
I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are:
REST is more dynamic, no need for creating and updating UDDI.
REST is not restricted to XML format. REST web services can send plain text, JSON, and also XML.
But SOAP is more standardized (Ex; security).
So, am I correct in these points?
- SOAP is a protocol whereas REST is architecture.
- SOAP exposes behavior which represent logic whereas REST exposes resources which represent data.
- In terms of consumption REST service is much simpler than SOAP. With REST overhead of handling XML envelops is eliminated which makes it more fast as compare to SOAP.
- SOAP provided good security options as compared to REST.
- For machine to machine interaction & enterprise solutions SOAP is preferable but for public facing API’s REST is best option almost 70% public API’s are REST.
- REST is lightweight, maintainable & scalable.
- REST is device independent i.e. client consuming REST API can be anything like Mobile devices, Notebooks, TV etc.
- With the cloud coming in action. Application is slowly moving to cloud based systems such as Azure, Amazon AWS. These systems are build and exposing REST API’s. Hence it is a good move to build application on the top of the REST API.
SOAP is not the right question to ask.
SOAP is not a protocol.
REST is an architectural style and a design for network-based software architectures.
REST concepts are referred to as resources. A representation of a resource must be stateless. It is represented via some media type. Some examples of media types include
RDF. Resources are manipulated by components. Components request and manipulate resources via a standard uniform interface. In the case of HTTP, this interface consists of standard HTTP ops e.g.
@Abdulaziz's question does illuminate the fact that
HTTP are often used in tandem. This is primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles.
Fundamental REST Principles
Client-server architectures have a very distinct separation of concerns. All applications built in the RESTful style must also be client-server in principle.
Each client request to the server requires that its state be fully represented. The server must be able to completely understand the client request without using any server context or server session state. It follows that all state must be kept on the client.
Cache constraints may be used, thus enabling response data to be marked as cacheable or not-cacheable. Any data marked as cacheable may be reused as the response to the same subsequent request.
All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!
The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service.
See this blog post on REST Design Principles for more details on REST and the above stated bullets.
EDIT: update content based on comments
A lot of these answers entirely forgot to mention hypermedia controls (HATEOAS) which is completely fundamental to REST. A few others touched on it, but didn't really explain it so well.
This article should explain the difference between the concepts, without getting into the weeds on specific SOAP features.
++ A mistake that’s often made when approaching REST is to think of it as “web services with URLs”—to think of REST as another remote procedure call (RPC) mechanism, like SOAP, but invoked through plain HTTP URLs and without SOAP’s hefty XML namespaces.
++ On the contrary, REST has little to do with RPC. Whereas RPC is service oriented and focused on actions and verbs, REST is resource oriented, emphasizing the things and nouns that comprise an application.
Difference between Rest and Soap
- SOAP is a protocol.
- SOAP stands for Simple Object Access Protocol.
- SOAP can't use REST because it is a protocol.
- SOAP uses services interfaces to expose the business logic.
- SOAP defines standards to be strictly followed.
- SOAP requires more bandwidth and resource than REST.
- SOAP defines its own security.
- SOAP permits XML data format only.
- SOAP is less preferred than REST.
- REST is an architectural style.
- REST stands for Representational State Transfer.
- REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
- REST uses URI to expose business logic.
- REST does not define too much standards like SOAP.
- REST requires less bandwidth and resource than SOAP.
- RESTful web services inherits security measures from the underlying transport.
- REST permits different data format such as Plain text, HTML, XML, JSON etc.
- REST more preferred than SOAP.
For more Details please see here
First of all: In the loose sense, web service means using the HTTP protocol to transfer data instead of web pages. However, in the strict sense, a web service, as defined by W3C is a very specific form of that idea. So, when people talk about SOAP vs. REST, they actually mean web services vs. REST (where "web services" refers to the official definition, since, in practice, REST services are also called web services by everyone).
So, let's say you want to call a function in a remote computer, implemented in some other programming language (remote procedure call/RPC). You have to (somehow) send it a message, and get some response. First, that function can be found at a specific URL, provided by its creator. Then, there are two main questions to consider.
- what is the format of the message you should send
- how should the message be carried back and forth
According to the official definition, the answer to the first question is the WSDL, an XML which describes, in detailed and strict format, what are the parameters, what are their types, names, default values, the name of the function to be called, etc. To the second question, there are various answers. The most popular (by far) is SOAP. Its main idea is: wrap the previous XML (the actual message) into yet another XML, and send it over HTTP (although, in theory, it can be used with other protocols, but noone ever does it). The POST method of the HTTP is used to send the message, since there is always a body.
So, by the approach (widely, but erroneously) called SOAP, you map a URL to a function, that is an action. The RESTful approach is: instead of the URL representing an action, it should represent a thing (called resource in the RESTful lingo). Since the HTTP protocol (which we are already using) supports verbs, use those verbs to specify what actions to perform on the thing.
So, with the SOAP (again, wrong term) approach, if you have a list of customers, and you want to view/update/delete one, you will have 3 URLS:
myapp/read-customerand in the body of the message, pass the id of the customer to be read.
myapp/update-customerand in the body, pass the id of the customer, as well as the new data
myapp/delete-customerand the id in the body
While, with the REST approach, you would only have
3 is the id of a specific customer). To view the customer data, you hit the URL with a GET request. To delete it, the same URL, with a DELETE verb. To update it, again, the same URL with a POST verb, and the new content in the request body.
For more details about the requirements that a service has to fulfil to be considered truly RESTful, see the Richardson maturity model. The article gives examples, and, more importantly, explains why a (so-called) SOAP service, is a level-0 REST service (although, level-0 means low compliance to this model, it's not offensive, and it is still useful in many cases).
SOAP (Simple Object Access Protocol) and REST (Representation State Transfer) both are beautiful in their way. So I am not comparing them. Instead, I am trying to depict the picture, when I preferred to use REST and when SOAP.
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, the payload is the data that is carried on behalf of an application and the data received by the destination system.
Now, for example, I have to send a Telegram and we all know that the cost of the telegram will depend on some words.
So tell me among below mentioned these two messages, which one is cheaper to send?
I know your answer will be the second one although both representing the same message second one is cheaper regarding cost.
So I am trying to say that, sending data over the network in JSON format is cheaper than sending it in XML format regarding 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. And we already know, if we use Json then definitely we will be in better place regarding payload.
Now, SOAP supports the only XML, but it also has its advantages.
SOAP relies on XML in three ways Envelope – that defines what is in the message and how to process it.
A set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered.
This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed, and the envelope is returned with information in an XML formatted document.
The important point is that one of the advantages of SOAP is the use of the “generic” transport but REST uses HTTP/HTTPS. SOAP can use almost any transport to send the request but REST cannot. So here we got an advantage of using SOAP.
As I already mentioned in above paragraph “REST uses HTTP/HTTPS”, so go a bit deeper on these words.
When we are talking about REST over HTTP, all security measures applied HTTP are inherited, and this is known as transport level security and it secures messages only while it is inside the wire but once you delivered it on the other side you don’t know how many stages it will have to go through before reaching the real point where the data will be processed. And of course, all those stages could use something different than HTTP.So Rest is not safer completely, right?
But SOAP supports SSL just like REST additionally it also supports WS-Security which adds some enterprise security features. WS-Security offers protection from the creation of the message to it’s consumption. So for transport level security whatever loophole we found that can be prevented using WS-Security.
Apart from that, as REST is limited by it's HTTP protocol so it’s transaction support is neither ACID compliant nor can provide two-phase commit across distributed transnational resources.
But SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
I am not drawing any conclusion, but I will prefer SOAP-based web service while security, transaction, etc. are the main concerns.
Here is the "The Java EE 6 Tutorial" where they have said A RESTful design may be appropriate when the following conditions are met. Have a look.
Hope you enjoyed reading my answer.
The decision between the two will be your first choice in designing a web service, so it is important to understand the pros and cons of the two. It is also important, in the sometimes heated debate between the two philosophies, to separate reality from rhetoric.
- Everything in REST is considered as a resource.
- Every resource is identified by a URI.
- Uses uniform interfaces. Resources are handled using 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.
- WSDL defines the 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 for 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, XSD, 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 standardized 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 every 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 whereas 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 been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to its support for JSON.
- REST has better performance and scalability. REST reads can be cached; SOAP-based reads cannot be cached.
- No expensive tools require interacting 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 do not need for, in fact, they are 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 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)
- 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 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 a bonus of AJAX.
- 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 stateless operation of the REST approach, this is perfect.
Where to use SOAP
areas where SOAP works as a great solution:
- 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.