Fing "Enterprise". Beam me up Scotty, there's no intelligent life here.
IBM and Microsoft drop the SOAP, and we get stuck picking it up. I hate* implementing SOAP clients for random SOAP server implementation of the day..
I'm sorry, Rob will be back shortly. We apologize for the outburst :-) ...
Boy, you NAILED it exactly, though.
REST sure seems simpler: define the document/content types, or schema, and just use links to GET things. Save POST for the few things that actually change state, then document carefully how the content is to be sent back up.
It turns out a good deal of services really are READ-ONLY anyway.
Making the simple things simple: give me my damn document! Let's keep it encrypted, and I'll prove I'm authorized to see it:
https:/acme.com/service?acct=xxx&pass=yyy&item_key=123 ... Content: binary/what-you-wanted blah blah blah...
Painfully easy vs just freaking painful tweaking of SOAP nonsense. Die, SOAP, die!
If you want to make it look like you have an open API, while only having to do enough work to expose the way your two predefined systems already communicate, SOAP is the answer.
SOAP it is for us and I do have to say that I'm rather relaxed. For us it's just one way (Java services, Java generated WSDL, we just consume/use the stuff), but it works rather well.
Unless you don't know about 3.5/WCF/Service References and try to do it the old-fashioned "Web Reference" ASP.Net way: That's a royal pain and just plain doesn't work at all for some (valid) SOAP things (some sequences of alternating complex types a la [Key, Value, Key, Value,...] for example cannot be mapped). Guess how I found out..
Sure, I am not supporting or detracting from SOAP, just highlighting the trending I am seeing in the SaaS space and I used Salesforce as an example because it is one that has made huge inroads into the enterprise space. It is the champion that got business executives looking at the advantages of SaaS. It is a logical conclusion that Accounting, HR, etc. will be adopted by the enterprise once someone mixes the formular right for SaaS in those spaces.
SOAP is just plain awful, though.
The enterprise of the future looks like an ESB that brokers data to and fro an assortment of SaaS, with some core in-house systems in the mix. It makes sense for companies whose bread and butter is not technology and places economies of scale on the SaaS providers. Many of those SaaS are opting for REST only implementations.
In a way it makes sense, for alot of the integrations you are wanting to pull data from the system for analytics, trending and reporting along side an aggregate of other data sources. REST make sense because it (loosely) acts like SQL which despite it's problems is a good data manipulating language.
The thing about REST is that someone needs to come up with a uniform and simple authentication and authorization mechanism that is seamless across the board.