
SOAP is officially dead, long live REST - tswicegood
http://reinout.vanrees.org/weblog/2010/11/11/soap-is-dead-long-live-rest.html
======
canterburry
I may agree that for most types of online APIs currently made available by so
many SaaS and web companies, there is probably little use for the WS-* stack.
However, corporate America I think will keep relying on SOAP for a long time
since it's the only way (that I know of) to get distributed transactions,
federated security and other enterprise type features required using web
services. The WS-* stack is there for a reason and it's because big business
requires it.

~~~
randall
So big broadcast uses this standard called MOS to interoperate between say a
video server and a switcher. I've always thought REST would be entirely
appropriate, since they're simply exchanging messages. I'm wondering if you
have any insight into SOAP vs REST in this situation. I mean would SOAP
provide some level of confidence in message transmission that REST would not?

------
phamilton
A comment on the page asks if there are REST libraries available. They really
aren't needed in most cases. With a url lib and json/xml parser, you've got
the libraries you need. It's easier to write an abstraction layer for your
particular application than it is to adapt a library for your application.

~~~
DougWebb
I agree with your comment, but this is a big impediment for a lot of
developers. I think it's partly conceptual. SOAP libraries will grab a wsdl
file and generate a class with methods for each procedure the service exposes.
That makes a lot of developers think something has been made easy for them,
but they still have to understand the class interface to know how to talk to
the service. REST is the same; you have to understand the interface (resource
representations) to know how to talk to the service. REST just skips that
middle code generation part where you tightly couple your code to a particular
version of the service api. The developers who are looking for a library just
want the code generation.

I tell people that they've already got the communication stack in place and
don't need code generation; what they need is to understand the api and design
the classes on their side that will _use_ the api. The http and json stuff
gets buried there, not in a client-side facade class.

------
teilo
I will be very happy to see SOAP go away forever. A GET/POST with a JSON or
XML response is just so much easier to deal with.

However, the reality is that there are many enterprise tools that only work
via SOAP. Standards organization or not, SOAP will be with us for a long time.

