SOAP vs REST differences

Question

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 to create and update UDDI Universal Description  Discovery  and Integration   REST is not restricted to only XML format  RESTful web services can send plain text JSON XML    But SOAP is more standardized  E g   security    So  am I correct in these points

User · Answer

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.

User · Answer

Although SOAP and REST share similarities over the HTTP protocol  SOAP is a more rigid set of messaging patterns than REST  The rules in SOAP are relevant because we can   t achieve any degree of standardization without them  REST needs no processing as an architecture style and is inherently more versatile  In the spirit of information exchange  both SOAP and REST depend on well-established laws that everybody has decided to abide by  The choice of SOAP vs  REST is dependent on the programming language you are using the environment you are using and the specifications

User · Answer

Addition for       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

User · Answer

Among many others already covered in the many answers  I would highlight that SOAP enables to define a contract  the WSDL  which define the operations supported  complex types  etc   SOAP is oriented to operations  but REST is oriented at resources   Personally I would select SOAP for complex interfaces between internal enterprise applications  and REST for public  simpler  stateless interfaces with the outside world

User · Answer

Unfortunately  there are a lot of misinformation and misconceptions around REST  Not only your question and the answer by  cmd reflect those  but most of the questions and answers related to the subject on Stack Overflow   SOAP and REST can t be compared directly  since the first is a protocol  or at least tries to be  and the second is an architectural style  This is probably one of the sources of confusion around it  since people tend to call REST any HTTP API that isn t SOAP   Pushing things a little and trying to establish a comparison  the main difference between SOAP and REST is the degree of coupling between client and server implementations  A SOAP client works like a custom desktop application  tightly coupled to the server  There s a rigid contract between client and server  and everything is expected to break if either side changes anything  You need constant updates following any change  but it s easier to ascertain if the contract is being followed   A REST client is more like a browser  It s a generic client that knows how to use a protocol and standardized methods  and an application has to fit inside that  You don t violate the protocol standards by creating extra methods  you leverage on the standard methods and create the actions with them on your media type  If done right  there s less coupling  and changes can be dealt with more gracefully  A client is supposed to enter a REST service with zero knowledge of the API  except for the entry point and the media type  In SOAP  the client needs previous knowledge on everything it will be using  or it won t even begin the interaction  Additionally  a REST client can be extended by code-on-demand supplied by the server itself  the classical example being JavaScript code used to drive the interaction with another service on the client-side   I think these are the crucial points to understand what REST is about  and how it differs from SOAP    REST is protocol independent  It s not coupled to HTTP  Pretty much like you can follow an ftp link on a website  a REST application can use any protocol for which there is a standardized URI scheme  REST is not a mapping of CRUD to HTTP methods  Read this answer for a detailed explanation on that  REST is as standardized as the parts you re using  Security and authentication in HTTP are standardized  so that s what you use when doing REST over HTTP  REST is not REST without hypermedia and HATEOAS  This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow  Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely  They are not only documenting something that s supposed to be following the standard  but when you do that  you re coupling the client to one particular moment in the evolution of the API  and any changes on the API have to be documented and applied  or it will break  REST is the architectural style of the web itself  When you enter Stack Overflow  you know what a User  a Question and an Answer are  you know the media types  and the website provides you with the links to them  A REST API has to do the same  If we designed the web the way people think REST should be done  instead of having a home page with links to Questions and Answers  we d have a static documentation explaining that in order to view a question  you have to take the URI stackoverflow com questions  lt id gt   replace id with the Question id and paste that on your browser  That s nonsense  but that s what many people think REST is    This last point can t be emphasized enough  If your clients are building URIs from templates in documentation and not getting links in the resource representations  that s not REST  Roy Fielding  the author of REST  made it clear on this blog post  REST APIs must be hypertext-driven    With the above in mind  you ll realize that while REST might not be restricted to XML  to do it correctly with any other format you ll have to design and standardize some format for your links  Hyperlinks are standard in XML  but not in JSON  There are draft standards for JSON  like HAL   Finally  REST isn t for everyone  and a proof of that is how most people solve their problems very well with the HTTP APIs they mistakenly called REST and never venture beyond that  REST is hard to do sometimes  especially in the beginning  but it pays over time with easier evolution on the server side  and client s resilience to changes  If you need something done quickly and easily  don t bother about getting REST right  It s probably not what you re looking for  If you need something that will have to stay online for years or even decades  then REST is for you

User · Answer

What is REST REST stands for representational state transfer  it s actually an architectural style for creating Web API which treats everything data or functionality  as recourse  It expects  exposing resources through URI and responding in multiple formats and representational transfer of state of the resources in stateless manner  Here I am talking about two things   Stateless manner  Provided by HTTP  Representational transfer of state  For example if we are adding an employee    into our  system  it s in POST state of HTTP  after this it would be in GET state of HTTP  PUT and DELETE likewise   REST can use SOAP web services because it is a concept and can use any protocol like HTTP  SOAP SOAP uses services interfaces to expose the business logic  REST uses URI to expose business logic  REST is not REST without HATEOAS  This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow  Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely  They are not only documenting something that s supposed to be following the standard  but when you do that  you re coupling the client to one particular moment in the evolution of the API  and any changes on the API have to be documented and applied  or it will break  HATEOAS  an abbreviation for Hypermedia As The Engine Of Application State  is a constraint of the REST application architecture that distinguishes it from most other network application architectures  The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers  A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia  By contrast  in some service-oriented architectures  SOA   clients and servers interact through a fixed interface shared through documentation or an interface description language  IDL   Reference 1 Reference 2

User · Answer

First of all  officially  the correct question would be web services   WSDL   SOAP vs REST  Because  although the web service  is used in the loose sense  when using the HTTP protocol to transfer data instead of web pages  officially it is a very specific form of that idea  According to the definition  REST is not  quot web service quot   In practice however  everyone ignores that  so let s ignore it too  There are already technical answers  so I ll try to provide some intuition  Let s say you want to call a function in a remote computer  implemented in some other programming language  this is often called remote procedure call RPC   Assume that function can be found at a specific URL  provided by the person who wrote it  You have to  somehow  send it a message  and get some response  So  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  For the first question  the official definition is WSDL  This is an XML file 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  An example WSDL here shows that the file is human-readable  but not easily   For the second question  there are various answers  However  the only one used in practice is SOAP  Its main idea is  wrap the previous XML  the actual message  into yet another XML  containing encoding info and other helpful stuff   and send it over HTTP  The POST method of the HTTP is used to send the message  since there is always a body  The main idea of this whole approach is that you map a URL to a function  that is  to an action  So  if you have a list of customers in some server  and you want to view update delete one  you must have 3 URLS   myapp read-customer and in the body of the message  pass the id of the customer to be read  myapp update-customer and in the body  pass the id of the customer  as well as the new data myapp delete-customer and the id in the body  The REST approach sees things differently  A URL should not represent an action  but a thing  called resource in the REST 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 REST approach  customer number 12 would be found on URL myapp customers 12  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

User · Answer

REST REpresentational State Transfer  REpresentational State of an Object is Transferred is REST i e  we don t send Object  we send state of Object  REST is an architectural style  It doesn   t define so many standards like SOAP  REST is for exposing Public APIs i e  Facebook API  Google Maps API  over the internet to handle CRUD operations on data  REST is focused on accessing named resources through a single consistent interface    SOAP Simple Object Access Protocol  SOAP brings its own protocol and focuses on exposing pieces of application logic  not data  as services  SOAP exposes operations  SOAP is focused on accessing named operations  each operation implement some business logic  Though SOAP is commonly referred to as web services this is misnomer  SOAP has a very little if anything to do with the Web  REST provides true Web services based on URIs and HTTP     Why REST      Since REST uses standard HTTP it is much simpler in just about ever way   REST is easier to implement  requires less bandwidth and resources    REST permits many different data formats where as SOAP only permits XML     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   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   If we need Stateless CRUD operations then go with REST  REST is commonly used in social media  web chat  mobile services and Public APIs like Google Maps  RESTful service return various MediaTypes for the same resource  depending on the request header parameter  Accept  as application xml or application json for POST and  user 1234 json or GET  user 1234 xml for GET  REST services are meant to be called by the client-side application and not the end user directly  ST in REST comes from State Transfer  You transfer the state around instead of having the server store it  this makes REST services scalable     Why SOAP       SOAP is not very easy to implement and requires more bandwidth and resources   SOAP message request is processed slower as compared to REST and it does not use web caching mechanism   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   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 payment gateways  financial and telecommunication related work then we should go with SOAP as here high security is needed      source1 source2

User · Answer

REST vs SOAP is not the right question to ask   REST  unlike 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 XML  JSON  and 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  GET  PUT  POST  DELETE    Abdulaziz s question does illuminate the fact that REST and 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 Communication  Client-server architectures have a very distinct separation of concerns  All applications built in the RESTful style must also be client-server in principle   Stateless  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   Cacheable  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   Uniform Interface  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

User · Answer

IMHO you can t compare SOAP and REST where those are two different things    SOAP is a protocol and REST is a software architectural pattern  There is a lot of misconception in the internet for SOAP vs REST    SOAP defines XML based message format that web service-enabled applications use to communicate each other over the internet  In order to do that the applications need  prior knowledge of the message contract  datatypes  etc     REST represents the state as resources  of a server from an URL It is stateless and clients should not have prior knowledge to interact with server beyond the understanding of hypermedia

User · Answer

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    lt name gt Arin lt  name gt    or    name    Arin    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    Really  How   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

[rest] SOAP vs REST (differences)

Examples related to rest

Examples related to web-services

Examples related to http

Examples related to soap

Examples related to definition