“There is, I think, lots that REST doesn’t try to do”. I fully agree, but I took your comment that I quoted to suggest that REST couldn’t be extended, i.e. that something about REST *prevented* scaling to large scale m2m.

Also, your concerns seem to be more with HTTP and other Web technologies than with the REST architectural style itself. For example, message-level security done right is more RESTful than transport level security because it would be completely stateless.

Anyhow, just wanted to clarify. Thanks.

I guess what I’d say is: REST has lots of advantages and I’m not trying to say otherwise,. There are indeed many scenarios where it’s a good answer.

There is, I think, lots that REST doesn’t try to do, and some of these things might be important in particular scenarios. To pick a few, not necessarily in priority order:

* Application, as opposed to transport-level security. Yes, you can layer it on, but there mostly aren’t standards today. Used RESTfully, application/soap+xml is a standard for doing just that.

* Durable queueing a la JMS, MQSeries/WebSphereMQ, etc.

* Various sorts of full duplex asynchronous streaming (in many, many cases, it’s not needed, but one can certainly envision process control, telemetry, or perhaps high-end video applications in which it is…though I’ll admit that SOAP is a stretch for doing video for other reasons)

To pick another example of something REST doesn’t do directly: I don’t think you’d want to build bittorrent out of HTTP. You might well want to layer a REST service on top of Bittorrent, but that’s different. I’m making the point that there are a variety of useful qualities of service that you might want, for which REST itself isn’t the right building block. For some of those, SOAP messages might be.

Noah

D’em’s fightin’ words!

Interested to hear why you believe that. I’ve been doing Web-scale m2m integration for several years now, and haven’t run into any big problems with it.