I agree with the "it's just a tool" sentiment in general, but what other great alternatives are there? I haven't had a favorable experience with SOAP, so I can understand why people think REST The Best Thing Evar. This is based on my own experiences, so I may have used SOAP wrong, misunderstood its intentions, etc. Do you have any examples of when SOAP (or another technology) is preferable to REST?
You can write RESTful SOAP, I don't think the two ideas are perpendicular. The problem with SOAP is more implementation than spec - PHP SOAP is different from .NET SOAP which is (slightly) different from Java SOAP, which leads to headaches.
REST is just a style of API. You can write a JSON API that isn't RESTful just as easily, and in some cases a RESTful API is not warranted.
Do you have an example of RESTful SOAP? I think SOAP's lack of situational HTTP method adoption (i.e. it uses GET or POST for everything, vs DELETE/PUT/etc. when appropriate), and the fact that it wraps another envelope around an already available HTTP envelope makes is hard to deem any SOAP implementation as RESTful. I'm not trying to prove you wrong, I'd just like to see an example (a quick google search yielded nothing for me).
REST was initially described in the context of HTTP, but is not limited to that protocol. You could write a RESTful SAML in SOAP in JSON API, if you desired.
Fox Sports has a pretty restful XML API. I can't remember if it's SOAP specifically, though.
Nope. Guy's got it right. 'Perpendicular' (or 'orthogonal' if you prefer), meaning that the concerns are on separate axes, and thus independent of each other.
SOAP is a bit weird because it's both an envelope/delivery mechanism as well as a discovery/interface negotiation methodology.
REST is just straight up a set of interface design principles. It doesn't care what you're delivering, it doesn't care about the channel you deliver it through.
That doesn't make it impossible to do. REST is traditionally implemented on HTTP, but the core goals and methodologies could be implemented over any protocol.
The "other thing" for us is is RPC and PUB/SUB patterns over sockjs (which wraps Websockets+fallbacks).
REST is a tool. But given an engineer a tool like a hammer and pretty soon everything will look like a nail. Sometimes you need a screwdriver when you actually have screws. Hammering them in will work but it is ugly.
Yeah I considered PUB/SUB as another alternative, and it makes sense to use it for realtime applications, but I'm not sure what else (due to my ignorance, not necessarily PUB/SUB limitations). As for RPC, isn't SOAP the successor to that?
