3 ms·

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucki

Can we just have back SOAP/WSDL and return to rational design and interoperability, or at least limit "REST" to a web facade? I think after 10-15 years of mucking around with "REST" (or what people think it is, as rightfully pointed out in TFA) it's very clear that there's not going to be a common understanding, let alone standard for it. As a freelancer having worked on maintaining many "REST" trainwrecks, I can tell you that naive REST spaghetti is absolutely much worse than any SOA design ever was. The technical debt and high maintenance might not be apparent while you happily code away your new "microservice"; but I can assure you you've just traded a tiny bit of upfront design for a long-term puzzle you're leaving behind. Did you know WSDL has supported "REST"-like encoding of parameters in URLs and operations as HTTP verbs since 2001?

unscaled 8y ago
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.
pbreit 8y ago
I had to support a SOAP-based API (PayPal v1) and it was horrific.
- tannhaeuser 8y ago
  OTOH, I've worked with EBICS and other ISO 20012 stuff, and while very intense and XML-heavy, it felt like adequate and robust in a way that JSON and schemaless simply doesn't for the task at hand (talking about representing very complex inter-banking businesses on stocks/derivatives with multi-leg deals, foreign exchanges and currencies, IBANs, ISINs, sub-second trading dates, etc.). Even used SOAP/MTOM in 2017, and it worked well enough.
whynotminot 8y ago
The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs. Why the hell would you wish that pain on anyone.
- tannhaeuser 8y ago
  > The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs. Except for undocumented "REST" APIs with totally arbitrary encodings of parameters into URL path steps and query parms, and needless excessive network roundtrips. Frameworks such as JAX-RS, Spring, and Swagger/Open API even invite you to use "subresources" as out-of-band agreed URL schemes ("lousy coupling"), totally missing the entire point of REST: that you dynamically learn interactions on "resources" via hyperlink URLs as a means for loose coupling.
lttlrck 8y ago
OpenAPI is gaining momentum. 3GPP for example have adopted it for several interfaces inside the 5G core network. https://en.m.wikipedia.org/wiki/OpenAPI_Specification https://en.m.wikipedia.org/wiki/OpenAPI_Specification

unscaled 8y ago

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.

pbreit 8y ago

I had to support a SOAP-based API (PayPal v1) and it was horrific.

tannhaeuser 8y ago
OTOH, I've worked with EBICS and other ISO 20012 stuff, and while very intense and XML-heavy, it felt like adequate and robust in a way that JSON and schemaless simply doesn't for the task at hand (talking about representing very complex inter-banking businesses on stocks/derivatives with multi-leg deals, foreign exchanges and currencies, IBANs, ISINs, sub-second trading dates, etc.). Even used SOAP/MTOM in 2017, and it worked well enough.

whynotminot 8y ago

The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs. Why the hell would you wish that pain on anyone.

tannhaeuser 8y ago
> The worst developer hell I've ever been through was fighting through figuring out poorly documented SOAP APIs. Except for undocumented "REST" APIs with totally arbitrary encodings of parameters into URL path steps and query parms, and needless excessive network roundtrips. Frameworks such as JAX-RS, Spring, and Swagger/Open API even invite you to use "subresources" as out-of-band agreed URL schemes ("lousy coupling"), totally missing the entire point of REST: that you dynamically learn interactions on "resources" via hyperlink URLs as a means for loose coupling.

lttlrck 8y ago

OpenAPI is gaining momentum. 3GPP for example have adopted it for several interfaces inside the 5G core network. https://en.m.wikipedia.org/wiki/OpenAPI_Specification https://en.m.wikipedia.org/wiki/OpenAPI_Specification