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.

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.

I've had both good and bad experiences with SOAP. I remember wasting a few days figuring out how to get a PHP app to authenticate against an ASP.NET SOAP implementation... I did get the auth to work, but then I ran into other problems, and we found these bozos had a competitor that had a simple POX api that took five minutes to get working.

On the other hand, there was the day I pointed Visual Studio at the WSDL file for the Salesforce.com API and was quite astonished to see it build all the stubs for a very complex API with just the click of a mouse and no hitches at all.

I'm not worried about the people who think REST = !SOAP.

I'm worried about the people who think they understand REST, build systems, and discover too late that they've got to rebuild their whole communication protocol because performance and reliability are just a disaster.

So it's not just an academic debate, it's about the difference between systems that work and systems that don't.

By that definision, SOAP is restful.

These days, "REST" is no better than "Web 2.0".

(Okay, it's not as bad as Web 2.0 but it's certainly a buzzword)

http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=0df3b4...

REST-ish = ?

The debate still exists, it's just moved. You're still going to have people calling anything with HTTP in it REST-ish just because it's another nice acronym to pad their resume.

aka "SOAP is RESTful"

- lack of knowledge about REST - poor support (if any) for REST apis compared to SOAP in the vendor tools.

Of course, getting .NET and Java services and clients interoperating with each other using SOAP was always problematic - but the teams I spoke with tended to work within pretty vertical technology stacks and services. So it was Java clients talking to Java services, or .NET clients talking to .NET services. So they saw SOAP as a good, familiar solution.

That's kind of like saying "I can't remember the last hybrid car I saw here in Cuba."