Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari
Join our communityTop Pro
•••Top Pro
•••Top Pro
•••Top Pro
•••Top Pro
•••
REST's benefits require strict adherance to constraints that are difficult to statically determine, which has resulted in many web services which intend to be RESTful, but fail, and as such fail to receive the benefits of REST. This can have some particularly negative effects: Content may be cached that should not be, leaving clients with stale data. Media types may be insufficiently specified, leaving clients coupled to the server and unable to discover new features. This is particularly common, as a content type of JSON or XML is generally of insufficient specificity to fully describe the media type and the relationships of links. Clients assuming a stateless server with idempotent GET/PUT/DELETE methods may make multiple requests to a server under these assumptions, causing adverse effects to the server state, or over-utilizing server resources. A service implemented over HTTP that fails to meet REST's requirements gains very little over SOAP, while losing many of its benefits. See More
SOAP's flexibility stems much from its simplicity. As an example, REST requires services to be organized around a Resource Oriented Architecture (ROA) in order to realize a set of benefits specific to HTTP. SOAP, on the other hand, does not heavily constrain the architecture of services built on it, as it is intended to work across a variety of protocols. This means that SOAP is an excellent solution for services that do not map well to ROA, such as those that require transaction semantics, those that would not likely make much use of HTTP specific features (e.g., cacheing and content-type negotiation) such as those that expose a computational resource (RPC), or for integrating multiple systems, which would benefit more from asynchronous messaging/callback semantics. See More
While SOAP is commonly implemented over HTTP, SOAP messages do not rely on features of any particular protocol. This means that SOAP services can be tunnelled over a variety of transport protocols aside from HTTP, such as SMTP. Beyond this, SOAP is not restricted to client-server architectures, and so may be used to implement services such as push notifications when used outside of HTTP. See More
SOAP services use a standard format (XML), are generally well typed, and can be described thoroughly with WSDL (Web Services Definition Language). This means that boilerplate code for interacting with a service can often be automatically generated from its descriptions, dramatically reducing time needed to implement a service endpoint. Contrast this with REST, where media types my be highly variable, and interfaces highly generic, and so much focus is on understanding a service's architecture as a whole, and implementing support for a particular media type. See More
Standardizing around XML, even as opposed to other popular formats such as JSON, brings serveral benefits to SOAP - primarily, it has widespread support, not only for parsing in different languages, but also for decoupled validation logic through DTDs and XML-schema, decoupled translation through XSLT, and querying through XPath. XML is also a hypermedia format, which brings with it implicit understanding of links. At a more general level, choosing a standard parent format decreases the likelyhood that highly divergant formats will need to be supported by any service provider or consumer in order to achieve interoperability. See More