In an article on IBM’s developerworks:

Proponents of the REST-based pattern often point to its architectural simplicity compared to the complexities inherent in the broad collection of SOAP-related Web service specifications as being the key to why REST is the superior approach. This argument has flaws in that, as I have illustrated, the two approaches are looking to solve different types of problems. Web-based application services, such as Bloglines, Amazon, flikr, del.icio.us, and so forth, face a different set of issues than say, a hospital looking to automate their internal processes for order procedures and writing prescriptions and therefore demand a different architectural approach. That’s why design patterns exist — different approaches to solve different problems.

I don’t believe he’s successfully illustrated any flaws at all, particularly not with those two examples. Both order procedures and writing prescriptions can fit just as comfortably within a REST paradigm as they can SOAP.

For example, it’s easy to envisage POSTing to a prescription resource such as:

/health/services/prescription

which creates a new prescription identifier (for example, P1RA43) and adds the items in the prescription request. The identifier is returned to the caller by way of the Location header:

Location: http://somehealthprovider.com/health/services/prescription/P1RA43

The prescription could then be viewed in a web browser by calling that URI and specifying a content type of text/html, or used by a pharmacy computer during the fulfillment stage, by requesting text/xml instead. An HTTP DELETE against the URI would get rid of the prescription, a PUT would replace the contents, and subsequent POSTs add to the contents.

It seems to me this looks hellaciously (love that word) more elegant than the equivalent CreatePrescription, GetPrescription, AddToPrescription, ReplacePrescription, DeletePrescription, etc that I assume would be the SOAP equivalents.