5 ms·

> advocating abandoning it completely in favor of RPC-over-HTTP It surprises me that the author didn't go one step further and ask us to return to SOAP :)

• dragonwriter 12y ago
  I think that we're only a few years away from someone reinventing SOAP but with JSON playing the role of XML.
  • xienze 12y ago
    And a hip name, like Dove or Ivry.
    • bebop 12y ago
      I hope all the backends are written in JS and run in the browser.
  • lmorchard 12y ago
    I take it that no one's seen JSON-RPC? http://json-rpc.org/ http://json-rpc.org/
• lmm 12y ago
  Other than XML Schema, and XML namespaces, what was wrong with SOAP? Serious question. I genuinely think it had big advantages over REST.
  • namdnay 12y ago
    I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't even know what operations are being called. Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. And take testing - you need to pull out the heavy artillery (SOAP UI is very good) to test a SOAP service. Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script. Not huge issues, and if you're working on a big project it won't make a big difference. But still a PITA, in my opinion
    • lmm 12y ago
      > Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. Fair enough. I always preferred to log at the "middleware" level but I guess that's a use case. > Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script. GET for everything is a large part of what the article is advocating. Once you get into "true REST" (using PATCH/DELETE/etc., maybe content negotiation) then you quickly move out of what you can test with the browser. As for Python that was one of the things I loved about SOAP - plug the .wsdl into suds and you can test it from your Python script and you don't even need a separate doc, you can just use Python's built-in dir() and help().
      • namdnay 12y ago
        Yes I definitely agree with your last point - one of the nice things with SOAP is the autogeneration side. Same thing with Java CXF - import your wsdl and boom you have an interface with all the right methods etc, whether on client or server side.
  • deleted 12y ago
    [deleted]
  • lerno 12y ago
    The "point" of SOAP is to have an autogenerated API layer + objects on client and server side. The problem is that this does not actually help much in validating data sent or received. In addition, the client side SoapFooData you might receive is unlikely to be something that you want to pass around, so you still need wrappers for most complex structures. Working with SOAP is complex even for extremely simple APIs, and for complex ones you will end up NOT using the generated objects anyway. Finally implementations are generally buggy and incompatible with each other. And generated code is something that should be strongly avoided. So in short: SOAP is complex and in return you get something that's pretty much useless (generated objects)