SOAP and REST At Odds (2017) | Hacker News Reader

SOAP and REST At Odds (2017)

thehistoryoftheweb.com

20 pointspjmlp18 comments

I used SOAP a lot. One day I tried to recompile my old WSDL using a newer version of Java. Now the old client couldn’t talk to the new server. Or was it the other way?

Anyway now I use JSON over HTTP and I don’t care if it’s REST or not.

I didn't realise anyone preferred Soap, even 4 years ago.

You'll be surprised that a lot of what blogs and online communities peddle as cool or not cool doesn't reflect the actual industry and professional preferences at all.

REST is trendy because everyone sells imaginary features like self-discovery, performance and universal clients, while actually shipping random ad-hoc JSON snippets over "pretty" URLs.

REST is cool because it doesn't actually exist, so there's nothing specific to criticize about it that sticks. Any attempt at REST critique is quickly drown out by the noise of thousands of REST fans saying "but this is not REST".

I've somehow managed to not run into SOAP despite having done backend exclusively for a while. From the perspective of someone who's totally naïve to it, the technology sounds like it introduces more friction to the developer than the common JSON over HTTP approach. I'd appreciate someone who favours SOAP explaining what the advantages are, I'm genuinely curious because I've never worked with it first hand.

One advantage is that there's a schema describing service that can be used to automatically generate the client code. However, getting data in and out of the auto-generated objects doesn't seem any easier than getting it in and out of JSON, so I'm not sure that's much of an advantage.

Recently I ran into an issue where the SOAP client library I was using escaped values like you normally would in XML: <xml>1 < 2 &amp cetera</xml> ... but the SOAP server required CDATA syntax, like this: <xml><![CDATA[1 < 2 & cetera]]></xml>, so the schema didn't help much there either.

We had this problem with JSON in the first few years. Various ad-hoc JSON parsers that are not in fact compliant parsers, but mix-in various JSON-like features in the syntax and have specific expectations about formatting.

The reason JSON got past this stage is that the JSON spec is sufficiently simple that when a popular JSON parser for every platform/language got established, people just used it.

XML on the other hand is a nightmare of complexity and it even had the occasional remote code execution vulnerabilities in some parsers (they're that complex). Which means many applications would "handroll" something that amounts to a child's interpretation of what XML is and expect that. Truly unfortunate.

I wonder if SOAP based on JSON would be more successful. Probably yes. But we didn't have it back then.

KISS

Oof, that last part sounds like a faff to deal with!

REST is a software architectural style and SOAP is a protocol.

Lots of people argue over whether or not their API is RESTful.

Use of HTTP verbs is only one method of metadata intent of an operation ; but it often gets watered down to this.

Yup.

Every single REST API in the world has been a part of at least one "is this RESTful" argument.

Exactly zero (zilch, nada) SOAP APIs in the world have been a part of a "is this SOAPful" argument.

Similarly there's no such arguments when using GraphQL or gRPC.

Therefore all conversations about "REST vs. GraphQL/SOAP/gRPC" make no sense, it's like comparing apples and recipe books.

Eager to see what a RESTful SOAP API would look like.

Lots of people argue over whether or not their [REST] API is RESTful.

I continue to be surprised how easy it can be to consume a SOAP API with the right client libraries. Such as https://docs.python-zeep.org/en/master/ for Python. Now that's not to say it will always work, you can design a terrible API with any mechanism, no SOAP or REST client will help you if the other end has desided to succumb to madness and done something like turn their entire API into just "two endpoints" and driven by the payload content you post to the inbound endpoint, and you have to sit there polling the outbound endpoint with the inbound endpoints response ID to find out what the eventual response is...

But horror story aside, consuming a decent SOAP endpoint with a good client library can be practically magical.

Between attrs (https://www.attrs.org/), cattrs (https://cattrs.readthedocs.io/), and the aforementioned zeep soap client I've got a serialisation pipeline from soap endpoint into an attrs dataclass with type hints and basic type validation down to a snippet so small it fits right here (type hints removed to minimise size).

  from zeep import helpers
  from cattr import structure

  def zeep_to_attrs(zeep_object, attrs_class):
      """Serialize zeep objects to native python data structures"""
      return structure(helpers.serialize_object(zeep_object, target_cls=dict), attrs_class)

Waiting for the HATEOAS zealots to arrive, then the real fight can begin.

REST has lost a bit of steam in recent years. You still see everyone blogging about it, but the REST chat channels and forums are empty.

Probably the slow realization most of REST's promises were just vapor, and all we need is ad-hoc JSON HTTP APIs.

Waiter, there appears to be a WSDL in my REST!

TL;DR SOAP is complex and REST is simple, people argue about which one is “best”

CORBA is complex and SOAP is simple, people argue about which one is “best”

there is no new thing under the sun

Here I am writing stuff in REST, GraphQL and gRPC, while remembering that my first distributed computing projects were based in Novel Netware, Sun RPC and PVM.

Rince and repeat, while selling a couple of books and conference tickets I guess.

Reply on news.ycombinator.com