Hacker News Reader

Comment by maxpert | Hacker News Reader

Web has come a full circle. First we disgust and hate SOAP XML and friends. Then we go to REST and realize of it's too loose! Then we invent stuff like Swagger and JSONAPI in order to put some interfacing in place. And then we bring in cripples that give similar but water downed features of SOAP, GRPC, GraphQL and more friends.

Edit: I know I might get downvotes but think for a second we could have just taken some good parts from SOAP to begin with and have all the goodness.

View on HN

Yes, it has come full circle - but SOAP XML and friends were rightfully despised. The spec is a mess and there are so many broken implementations all over the place. I have fond memories of debugging the PHP SOAP client in order to build a bug-by-bug compatible Python version :-)

gRPC and other modern RPC protocols/SOA frameworks are basically "the good parts from SOAP".

I feel that the difference is that SOAP was a proper spec made by multiple parties, for better or worse. And GRPC is just a published spec from Google with code from Google. Of course it won't be such a mess and it will be good enough. Is it good to rely on Google adopting its tech as an industry standard? That's a philosophical question.

I personally use this rule to decide whether I should use a Google service/library: it has to have more than 1 billion active users or it's an important part of such services. gRpc more specifically protobuf, imo, is very important to Google. So I won't be worried about its future.

gRPC was contributed by Google to CNCF. Google remains extremely engaged in its ongoing development.

https://www.cncf.io/projects/

You might also be interested that Google is hosting the first ever gRPC Conf, which is being organized by CNCF the gRPC community: https://events.linuxfoundation.org/events/grpconf-2019/

(Disclosure: I'm executive director of CNCF.)

From a philosophical point of view, it seems like a design critique should be focused more on the design and less about where it came from? (Assuming it's open source and there aren't intellectual property issues.)

Industry standards tend to take on a life of their own, even if they came from one company. (Consider Docker.)

> I have fond memories of debugging the PHP SOAP client

It's no better now :) I use it frequently with SOAP endpoints from various companies (all with varying authentication measures/encodings/versions) and it's a nightmare.

Unfortunately the travel industry hasn't gone for anything else yet...

I used to use https://github.com/econea/nusoap back in the day, take a look

The SOAP specs do not even make sense. What doesn't make much of a difference, because the only player I've seen even trying to follow them is Microsoft (go figure...).

SOAP has a broken type system that can not be extended (leading to many extension standards for things like lists (go figure, again) and complex formats that people didn't want to convert from and into). It had horrible error handling, with problems only becoming visible at the application layer. It inherited the XML's property vs. contents problem. It inherited the XML's bad DTD format.

Soap deserves to die. Taking the good parts of it would be good, but there was nobody in a position to do that, so we settled on fixing the problems and patching the good parts back with time. With gRPC, I think we are there.

We did REST but we completely skipped over "just using HTTP correctly." E.g. using media types in the Content-Type and Accept fields to specify that you're sending a "application/vnd.foo.myapp.myfooreq.v1+json" and looking for either a "application/vnd.foo.myapp.myfooresp.v1+json" or "application/vnd.foo.myapp.knownerror.v1+json" in response.

Then, HTTP itself does the RPC message type management. Request message the server didn't expect? 406 error.

SOAP had a lot of the right ideas. It didn't fail because the concept behind it was bad. The main reason it failed was that, although the "S" stands for "simple", it wasn't. Maybe it was simple compared to CORBA or something.

http://harmful.cat-v.org/software/xml/soap/simple is a fun read.

> Maybe it was simple compared to CORBA or something.

Hell no! CORBA was a binary protocol, but it was much easier to reason about and debug than SOAP.

Somebody put that "simple" there with no concern about semantics.

At one point during grad school (after far too much RPC middleware implementation work) I was able to decode hex dumps of CORBA packets in my head

I was sure able to write them.

I was never able to write a complete SOAP response, and I don't think I was once able to predict one without running first (parsing after the fact is easier, that I can do).

It would be probably more accurate to call GraphQL the XSLT of our time.

But really, all this serialization crap is what programmers are legendary for: trading one form of busywork (reading bytes into object fields) for an even more obscure form of busy work (specifying a generator of the process).

This is how tech works. The old things are new again. (Let's not forget about CORBA, Sun RPC, and others.)

Well, if data serialization, transfer and deserialization with protobuf is faster then that's a big improvement over SOAP and XML.

Reply on news.ycombinator.com