3 ms·

jbooth: Hindsight is a wonderful thing. The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most peop

jbooth: Hindsight is a wonderful thing. The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know. But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons standards is still pretty clear.

jbooth 14y ago
It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful. The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to say that, that arrangement could turn all kinds of great ideas into disasters.
- MichaelGG 14y ago
  >Why would you ever choose SOAP over a simple REST endpoint? I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interoperable stacks. But at least there was a real reason, and serious value for a lot of developers. To compare, JSON doesn't even have a standard date format defined.
  - lucian1900 14y ago
    SOAP implementations are almost always so terrible that XML parsers can't make sense of them. WDSL would be just as useless even with tools.
  - lobster_johnson 14y ago
    SOAP/WSDL has IDE support and various tooling because it would be almost unusable without it. Imagine doing SOAP entirely by hand, with a semi-complicated WSDL. It's a nightmare. Doing a RESTful service based on JSON data is not just not a nightmare, it's a breeze, with no need for any of the tooling you describe and with, in my opinion, absolutely no difference in API richness, interoperability, security, quality etc.

jbooth 14y ago

It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful. The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to say that, that arrangement could turn all kinds of great ideas into disasters.

MichaelGG 14y ago
>Why would you ever choose SOAP over a simple REST endpoint? I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interoperable stacks. But at least there was a real reason, and serious value for a lot of developers. To compare, JSON doesn't even have a standard date format defined.
- lucian1900 14y ago
  SOAP implementations are almost always so terrible that XML parsers can't make sense of them. WDSL would be just as useless even with tools.
- lobster_johnson 14y ago
  SOAP/WSDL has IDE support and various tooling because it would be almost unusable without it. Imagine doing SOAP entirely by hand, with a semi-complicated WSDL. It's a nightmare. Doing a RESTful service based on JSON data is not just not a nightmare, it's a breeze, with no need for any of the tooling you describe and with, in my opinion, absolutely no difference in API richness, interoperability, security, quality etc.