My main complaint with SOAP was how leaky an abstraction it inevitably is/was - it can look seductively easy to use but them something goes wrong or you tried to use it across different tech stacks and then debugging would become a nightmare.

When I first encountered RESTful web services using JSON the ability to easily invoke them using curl was such a relief... (and yes, like lots of people, I went through a phase about being dogmatic about what REST actually is, HATEOAS and all the rest - but I've got over that years ago).

NB I also am puzzled as to the definition of "data" used in the article.

▲

2d8a875f-39a2-4 4 days ago | parent | next [-]

Sure, SOAP was often awful, I agree with that. But I can't see any angle where one can credibly assert that a SOAP XML payload isn't equivalent to a REST JSON payload in terms of the operation of a receiving application. Both are a chunk of structured information, your application parses it and operates on the resulting data structures.

	▲	fauigerzigerk 4 days ago \| parent \| next [-]
		>But I can't see any angle where one can credibly assert that a SOAP XML payload isn't equivalent to a REST JSON payload in terms of the operation of a receiving application. I guess the angle is that there was a style of SOAP where the payload was interpreted as a remote procedure call conforming to an interface described in a WSDL document. So there would be a SOAP library or server infrastructure (BizTalk) on the receiving end that would decode the message and turn it into a function call in some programming language. In that sense, the payload would be "data" only for the infrastructure code but not on the application level. And now I'm going to have to spend the rest of the day trying to forget this again :)
	▲	imtringued 4 days ago \| parent \| prev \| next [-]
		SOAP is the 9th circle of hell. Most implementations don't retrieve parameters by tag, they retrieve parameters by order, even if that means the tags don't match at all. This is completely unlike JSON. Also, almost nobody uses REST, so stop calling things REST, when you are talking about HTTP APIs.
	▲	arethuza 4 days ago \| parent \| prev [-]
		Sorry about getting sidetracked there by my SOAP rant - I completely agree with your point.

▲

imtringued 4 days ago | parent | prev | next [-]

>When I first encountered RESTful web services using JSON the ability to easily invoke them using curl was such a relief... (and yes, like lots of people, I went through a phase about being dogmatic about what REST actually is, HATEOAS and all the rest - but I've got over that years ago).

I'm not dogmatic about this. People don't understand what REST is. REST is some completely useless technology that absolutely nobody needs. Using the right words for things isn't dogmatism, it's being truthful. The backlash from most people comes from Fielding's superiority complex where he presents REST as superior, when it is merely different, different in ways that aren't actually useful to most people, and yet people constantly give this guy a platform by referring to his obsolete architecture, earning them the "well actually"s they deserve.

▲

BlackFly 4 days ago | parent | prev [-]

Yeah, a leaky abstraction with abstraction inversion on top of it! So within the actual payload there was a method identifier so you had sub-resource routing on top of the URL routing just so you could have middleware handling things on the payload instead of in the headers... So you had an application protocol (SOAP) on top of an application protocol (HTTP).