3 ms·

SOAP is officially dead, long live REST

5 points by tswicegood 16y ago

canterburry 16y ago
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 16y ago
  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 16y ago
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 16y ago
  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 16y ago
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.

5 points by tswicegood 16y ago

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 16y ago
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 16y ago

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 16y ago
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 16y ago

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.