REST vs (sort of) SOAP: How to choose?

Summary: REST supports request/response (client/server) interactions best, message passing systems support asynchronous and peer-to-peer message communication systems best.

The first architectural constraint applied to derive REST is client/server. I don't think this can be understated, everything that follows tunes the architecture to provide an elegant request/response system with fantastic results. Many, many, systems are client/server - and those should take advantage of REST (and often HTTP).

Message passing systems involve sending a message (headers + body) to a destination. That may not involve a response message, or may involve a sophisticated set of response messages from various other parties to the originator. HTTP always pairs a request message with a response message; solidifying the client/server interaction.

SOAP (without WSDL and WS-*) is just a message container, and can be used to implement asynchronous and P2P message passing systems. See MEST and SSDL for good examples of using SOAP infrastructure without the WSDL and WS-* cooked right in.

Another useful message passing system I've recently began studying is AMQP. This standard is designed to provide the building blocks for message passing systems, an efficient binary protocol for low latency operations, and a protocol based interaction (instead of programming API). Implementations include: Qpid (Java, C++ and more clientes) and RabbitMQ (Erlang).

Of course, request/response can be built on message passing:

• like most WSDL services that expose RPC
  
• like many JMS systems with replyTo
  
• everything gets shipped over IP (Internet Protocol) anyway, so everything is message based at the bottom
  

and message passing can be built on client/server:

• an HTTP server can be bundled into a client (two inverted client/server relationships form a P2P connection)
• an HTTP server can be polled to simulate a peer message send

but in both of these situations it would be better to pick an architecture that actually matches the problem. (If you can)

Finally, when working on the public internet, it is often not the case that remote machines can listen for P2P messages (because of firewalls and and NAT). STUN is a notable exception, but requires programming on top of UDP (shouldn't there be some library support for this?).

My conclusion: inside the enterprise pick the right architecture, on the internet expose only a client/server RESTful architecture.