HTTP Vs SOAP
SOAP : Simple Object Access Protocol is a message protocol(format of the message) to describe how we can transport messages over network(a data exchange used protocol putting soap message inside the http body). More about a format. This is an xml format that looks little complex than that of HTTP message.SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages. It is a protocol for accessing web services which supports web service security features such as Reliable messaging, assertion and so on which http won’t. SOAP typically sent over HTTP, but could be sent over SMTP or even FTP(transoport protocol)
Http (HyperText Transfer Protocol) is a transfer used protocol, which called a stateless protocol. It is majorly a transport protocol that describes the way of tranporting the messages over network. It may use HTTP message format or SOAP message format or JSON or anyother.
SOAP Services & Rest services :
Imagine you are developing a web-application and you decide to decouple the functionality from the presentation of the application, because it affords greater freedom.
You create an API and let others implement their own front-ends over it as well. What you just did here is implement an SOA methodology, i.e. using web-services.
Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages.
So, you design an interchange mechanism between the back-end (web-service) that does the processing and generation of something useful, and the front-end (which consumes the data), which could be anything. (A web, mobile, or desktop application, or another web-service). The only limitation here is that the front-end and back-end must “speak” the same “language”.
That’s where SOAP and REST come in. They are standard ways you’d pick communicate with the web-service. In One word to describe the difference, we can put it as Operation based Soap Service vs Resource based Rest service.
SOAP internally uses XML to send data back and forth. SOAP messages have rigid structure and the response XML then needs to be parsed. WSDL is a specification of what requests can be made, with which parameters, and what they will return. It is a complete specification of your API.
whereas REST just uses XML or JSON to send and receive data. WSDL Defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It’s highly dynamic unlike WSDL.
Problems with SOAP
The SOAP offered an excellent way of transferring the data between the applications. but the problem with SOAP was that along with data a lot of other meta data also needs to get transferred with each request and response. This extra information is needed to find out the capabilities of the service and other meta data related to the data that is being transferred coming from the server. This makes the payload heavy even for small data. Also, Web services needed the clients to create the proxy on their end. These proxies will do the marshaling and un-marshaling of SOAP WSDL and make the communication between the application and the web service possible. The problem with this proxy is that if the service is updated and the proxy on the
client is not then the application might behave incorrectly.
REST is a design concept. REST doesn’t add any specific functionality to HTTP but is an architectural style that was developed alongside HTTP and most commonly uses HTTP for its application layer protocol.The main idea behind REST is that we should treat our distributed services as a resource and we should be able to use simple HTTP protocols to perform various operations on that resource.
The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.
It isn’t as rigid as SOAP. RESTful web-services use standard URIs and methods to make calls to the webservice. When you request a URI, it returns the representation of an object, that you can then perform operations upon (e.g. GET, PUT, POST, DELETE). You are not limited to picking XML to represent data, you could pick anything really (JSON included)
Now the basic CRUD operations are mapped to the HTTP protocols in the following manner:
- GET: This maps to the R(Retrieve) part of the CRUD operation. This will be used to retrieve the required data (representation of data) from the remote resource.
- PUT: This maps to the U(Update) part of the CRUD operation. This protocol will update the current representation of the data on the remote server.
- POST: This maps to the C(Create) part of the CRUD operation. This will create a new entry for the current data that is being sent to the server.
- DELETE: This maps to the D(Delete) part of the CRUD operation. This will delete the specified data from the remote server.
Flickr’s REST API goes further and lets you return images as well.
JSON and XML, are functionally equivalent, and either could be chosen. XML is thought of as being too verbose, and harder to parse, so many-a-times, data is more adequately represented using JSON. (E.g. serialization)
If you are looking for the most significant constraints of REST that distinguish a RESTful application from just any HTTP application, I would say the “self-description” constraint and the hypermedia constraint (aka Hypermedia as the Engine of Application State (HATEOAS)) are the most important.
The self-description constraint requires a RESTful request to be completely self descriptive in the users intent. This allows intermediaries (proxies and caches) to act on the message safely.
The HATEOAS constraint is about turning your application into a web of links where the client’s current state is based on its place in that web. It is a tricky concept and requires more time to explain than I have right now.
||SOAP is a protocol.
||REST is an architectural style.
||SOAP stands for Simple Object Access Protocol.
||REST stands for REpresentational State Transfer.
||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.
||SOAP uses services interfaces to expose the business logic.
||REST uses URI to expose business logic.
||SOAP defines standards to be strictly followed.
||REST does not define too much standards like SOAP.
||SOAP requires more bandwidth and resource than REST.
||REST requires less bandwidth and resource than SOAP.
||SOAP defines its own security.
||RESTful web services inherits security measures from the underlying transport.
||SOAP permits XML data format only.
||REST permits different data format such as Plain text, HTML, XML, JSON etc.
||SOAP is less preferred than REST.
||REST more preferred than SOAP.