>And I mean, it's not like SOAP+WSDL actually worked well either, it was always unreliable.

I don't think it ever worked. See this [0]. It's pretty crazy that people build one of the most complex and verbose data exchange formats in the world and then it turns out that duplicating the open and close tag and including the parameter name and type in the attributes bought you nothing, because implementations are treating your SOAP request as an array of strings.

[0] https://snook.ca/archives/other/soap_request_pa

> it's not like SOAP+WSDL actually worked well either, it was always unreliable

This is comparable to saying that "multiplayer distributed architecture at scale" never worked well and was unreliable. All depends what your needs are and how the design and implementation satisfies them. SOAP+WSDL were part or a larger technology vision of Service Oriented Architecture (SOA) with all the complexities of distributed architecture. And the attempt was to make all of that open standards based.

I worked in Print at the time at one of the largest companies (now gone bust), and can confidentally say that SOAP+WSDL worked perfectly for us, and made it way more reliable to tie all these very specialized printing equipment with archaic languages and interfaces together, increasing productivity and efficiency of the entire print process.

SOAP always seemed to mostly work then if something did fail it was an utter nightmare to work out what the problem was - WSDL really wasn't much fun to read.

Whereas when REST APIs came out (using JSON or XML) they were much easier to dive into at the command line with curl and work out how to get things started and diagnose problems when they inevitably came up.

that seems like a particularly bad implementation :) IME things worked ok 70% of the time, but I do recall big matrixes of "does client library X work with server Y" with a lot of red cells.