SOAP is a specification for exposing remote procedure calls via a web service. The client executes a SOAP request by making an HTTP Post request against a URL with an XML request body that specifies what remote procedure to call and what parameters to pass into it. The service, in turn, sends an HTTP response with an XML body that contains the return value from the procedure call.
SOAP services also usually include a WSDL, which is alternately said to stand for Web Service Definition List, Web Service Definition Language, or Web Service Description Language and is meant to define the methods and parameters available to the client.
Because the whole system is so complicated, cumbersome and over-engineered, the normal way to create a WSDL is to do it automatically using tooling. Unfortunately, different frameworks generate different and often mutually incompatible and non-interoperable WSDLs. So, for example, a .NET SOAP client might not be able to consume a WSDL generated by a Java framework.
The S in SOAP originally stood for "Simple", but the protocol is anything but.
Yes that comment really helps but if i am getting it right, it is something like JSON, right? like JSON is used in public API's and all sorts of server-client communication. Any particular reason to take SOAP against something like JSON?
SOAP is a protocol specification for executing remote procedure calls over a network. SOAP uses XML for its message formatting and data serialization, and (usually) HTTP for its network protocol.
JSON, on the other hand, is a data serialization format rather than a remote procedure call format. It is sometimes used in web services - especially services based on Representational state transfer (REST) - to pass structured data between the client and server, but it is not a remote procedure call protocol in itself.
REST, in turn, is a method for designing a web service so that its functionality is accessed the same way that HTTP works. In REST, the service is organized into resources and methods, with resources corresponding to URLs and methods corresponding to the HTTP request methods: chiefly GET, POST, PUT and DELETE.
If you want to access a resource, you issue an HTTP GET request on the URL corresponding to that resource. If you want to create a resource, you issue an HTTP POST request on the URL corresponding to that resource with the data you want to post in the request body. If you want to update an existing resource, you issue an HTTP PUT request on the corresponding URL with the updated data. If you want to delete a resource, you issue an HTTP DELETE request on the corresponding URL.
Recently, many REST web services are designed to accept request data in JSON format and to send responses in JSON as well. Since web services are mainly consumed by client programs (rather than by humans browsing), JSON allows for a generic data structure that the client can consume and parse more easily than HTML, which is designed more specifically to structure documents.
SOAP services also usually include a WSDL, which is alternately said to stand for Web Service Definition List, Web Service Definition Language, or Web Service Description Language and is meant to define the methods and parameters available to the client.
Because the whole system is so complicated, cumbersome and over-engineered, the normal way to create a WSDL is to do it automatically using tooling. Unfortunately, different frameworks generate different and often mutually incompatible and non-interoperable WSDLs. So, for example, a .NET SOAP client might not be able to consume a WSDL generated by a Java framework.
The S in SOAP originally stood for "Simple", but the protocol is anything but.