Why did you vote for REST?
Extensibility and Discoverability
Ease of Testing/Portability
Add Another Pro
Extensibility and DiscoverabilityA RESTful web service is able to be extended dynamically, with minimal coordination between the client and server, because resources are discovered dynamically by clients. This is particularly a benefit over most RPC implementations, as even small changes in the interface to an RPC API can break clients.This is achieved through the use of hypermedia formats - formats that contain links. If clients don't rely on being able to parse or compose URIs, and instead, sufficiently descriptive hypermedia formats are used, a server can add new features (resources) by simply describing and linking to them.Similarly, as HTTP provides content negotiation, a RESTful API is able to support multiple representations of a resource - this allows for clients and servers to add and deprecate formats as they please, without breakage, so long as they continue to share at least one common media type. This is particularly useful for extending beyond the capabilities provided by a particular media type.
ScalabilityA RESTful web service is able to scale well partially because it can take advantage of the caching by clients and intermediate nodes that is provided out of the box by HTTP.This caching can only be achieved by requiring cacheable request types to be idempotent (produce the same result when called multiple times), and by requiring that the server be stateless (i.e., not generate responses based on session/per-connection state). When these constraints apply, all information that determines a response is contained in the request, and so intermediate nodes such as proxies can safely return cached results, provided that the request is the same, without knowing anything else about the end server. Similarly, idempotence allows for actions be performed multiple times, such as in the case of a failed connection, without fear of adverse effects. This is particularly useful not only for GET requests, but for PUT and DELETE requests, which allow for clients to predictably re-request for a change on the server.A RESTful web service, by virtue of not generating responses based on per-connection state, also only needs to scale its usage of hardware resources with the data provided by the service, not based on the number of concurrent connections.
Ease of Testing/PortabilityBecause clients and servers need to know nothing of eachother aside from a shared media type, they are completely decoupled from eachother, and so development of alternative clients is simplified - new clients need only support a shared media type. Servers may do their part in making client development easier by providing commonly implemented or well-specified media types that are easy to consume.RESTful web services are also particularly easy to test. As with in purely functional programming, the removal of a degree of side effects provides for much more testable interfaces, as output is predictable, consistent, and requires no set-up.Additionally, all RESTful web services can be tested at a high level with the same tools (e.g., curl). This benefit is primarily derived from resource-based addressing (URIs), and the fact that HTTP provides a standard generic interface for operating on those resources (HTTP verbs).
Why did you vote for SOAP?
Advantages over REST
Benefits of XML
Add Another Pro
PortabilityWhile 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.
Advantages over RESTREST'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.
Code GenerationSOAP 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.
Help make this question more complete.