4 ms·

If anyone was around when SOAP was being pushed on the dev community as the new way of structuring Web-like APIs, you may agree with me that SOAP was a good ide

If anyone was around when SOAP was being pushed on the dev community as the new way of structuring Web-like APIs, you may agree with me that SOAP was a good idea, but too complex and slow to implement - with questionable immediate / long term benefits. I don't think SOAP is in real prod systems much anymore. GraphQL, to me, inherits some issues of SOAP: complexity, non-mainstream terminology ... So, if I develop just fine with REST, moving to GraphQL is an added pain for me, and the dev community picks simple and straight-forward stuff over complex - as the SOAP's history teaches us

trumpeta 7y ago
Out of GraphQL and REST, I'd say REST is much closer to SOAP than GraphQL is. SOAP is essentially the same as REST -- you have request/response for every resource. Its just more verbose and inscrutable thanks to XML and all the schemas. GraphQL on the other hand enables new interactions that were not possible or practical with either of the two.
- smacktoward 7y ago
  Nah, SOAP is fundamentally different from REST in that it’s all organized around procedure calls. A SOAP API tends to be structured as a big bag of functions, whereas a REST API puts resources front and center. REST thinks in nouns, SOAP thinks in verbs.
smacktoward 7y ago
SOAP, itself, wasn’t too bad. What was bad was all the enterprisey architecture-astronaut cruft that people insisted on burying it under. (Kind of the same thing that happened with Java EE.) Beware if your favorite technology catches on in the BigCo world, because when those people fall in love with something they end up hugging it so hard they strangle it.
- barrkel 7y ago
  That stuff buried it, but it was a dead horse already - object RPC is the wrong mindset for internet RPC, doesn't treat latency (and thus async calls) and errors as first-class concerns.
barrkel 7y ago
The core problem with SOAP was that it inherited too much naive RPC mindset - a simple object access protocol encourages you to think in terms of manipulating objects, a bit like COM, DCOM, CORBA encourage you to think of manipulating remote objects via apparently-local proxies. Latency and failure are core to network (and especially internet) RPC though, and something that presents as a method call is too leaky an abstraction. It inhibited people from structuring their network calls as batch operations (the documentation orientation palaver was an attempt to change the conversation) or treating errors in a first class way (errors in RPC are way, way more common than in-process method calls, and require much more attention) or using async calls (don't block the world due to latency, which is rarely a hard requirement locally). All the standardization efforts as the CORBA etc. crowd piled on in and translated IDL (WSDL!), and layered authorization & authentication (rather than use existing HTTP idioms), transactions (WS-AT), etc. etc. just buried the already dying horse.

trumpeta 7y ago

Out of GraphQL and REST, I'd say REST is much closer to SOAP than GraphQL is. SOAP is essentially the same as REST -- you have request/response for every resource. Its just more verbose and inscrutable thanks to XML and all the schemas. GraphQL on the other hand enables new interactions that were not possible or practical with either of the two.

smacktoward 7y ago
Nah, SOAP is fundamentally different from REST in that it’s all organized around procedure calls. A SOAP API tends to be structured as a big bag of functions, whereas a REST API puts resources front and center. REST thinks in nouns, SOAP thinks in verbs.

smacktoward 7y ago

SOAP, itself, wasn’t too bad. What was bad was all the enterprisey architecture-astronaut cruft that people insisted on burying it under. (Kind of the same thing that happened with Java EE.) Beware if your favorite technology catches on in the BigCo world, because when those people fall in love with something they end up hugging it so hard they strangle it.

barrkel 7y ago
That stuff buried it, but it was a dead horse already - object RPC is the wrong mindset for internet RPC, doesn't treat latency (and thus async calls) and errors as first-class concerns.

barrkel 7y ago

The core problem with SOAP was that it inherited too much naive RPC mindset - a simple object access protocol encourages you to think in terms of manipulating objects, a bit like COM, DCOM, CORBA encourage you to think of manipulating remote objects via apparently-local proxies. Latency and failure are core to network (and especially internet) RPC though, and something that presents as a method call is too leaky an abstraction. It inhibited people from structuring their network calls as batch operations (the documentation orientation palaver was an attempt to change the conversation) or treating errors in a first class way (errors in RPC are way, way more common than in-process method calls, and require much more attention) or using async calls (don't block the world due to latency, which is rarely a hard requirement locally). All the standardization efforts as the CORBA etc. crowd piled on in and translated IDL (WSDL!), and layered authorization & authentication (rather than use existing HTTP idioms), transactions (WS-AT), etc. etc. just buried the already dying horse.