3 ms·

Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any bet

Even assuming we'd want XML as the message/schema format back (with all the security, performance and readability issues it entails), SOAP/WSDL/WS-* was any better than rest in standardization back in the day. For instance, there were multiple different ways you could format your message (RPC/encoded, RPC/literal, Document/encoded, Document/literal, Document/literal wrapped) and different implementations supported different formats. There were all kinds of extra features that were never supported across board like multi-part messages etc. Before WS-I there was practically zero guarantee that two SOAP implementations would ever be able to interoperate (and please remember, while REST has no standard in practice, it's dead simple to implement REST by hand - the same couldn't be say about SOAP!). WS-I only came out in 2004 or so, and by then it was already too late. I'd say the SOAP ecosystem is the definitive case study for trainwrecks. If you really want a standard method for RPC then you're much better off with a modern implementation like gRPC or Thrift or Cap'n proto. Please don't go back to the nightmare called SOAP.

organsnyder 8y ago
It's almost like interoperability is hard or something.
dfox 8y ago
I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interactions onto simple modification of something that can be meaningfully described as "resource". For typical application that implements non-trivial bussines processes this means that you either expose low-level implementation details (ie. how you internally represent progress of some process) in your API or you implement "REST" API that is sufficiently far from what REST is supposed to mean that it stops to make sense to use that moniker. On the other hand SOAP is good match for such applications because it is simply an RPC mechanism, albeit with unnecesarily complex marshalling and transport layers underneath.

organsnyder 8y ago

It's almost like interoperability is hard or something.

dfox 8y ago

I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interactions onto simple modification of something that can be meaningfully described as "resource". For typical application that implements non-trivial bussines processes this means that you either expose low-level implementation details (ie. how you internally represent progress of some process) in your API or you implement "REST" API that is sufficiently far from what REST is supposed to mean that it stops to make sense to use that moniker. On the other hand SOAP is good match for such applications because it is simply an RPC mechanism, albeit with unnecesarily complex marshalling and transport layers underneath.