Hacker News Reader

> everything defined up front between parties, out of band and then the enterprise companies started selling "tooling" to over-engineer and "manage" this nonsense.

This pattern has come up again and again. There's a centralized, orderly, Le Corbusier-style planned system. Everyone hates it and avoids using it in favor of a ramshackle schema-less system re-purposed from something else, which has no other advantages other than actually working.

See e.g.: circuit-switched networks, guaranteed QoS systems, centralised PKI, the more esoteric parts of XML vs the simplicity of JSON, one-directional hypertext, and the Internet itself vs telcos.

I'm an "infrastructure guy" that has just spent the better part of the last 8 hours of my working day talking to a developer trying to stand up some microservices, or whatever the kids are calling it these days.

Every few minutes, they started a sentence with "I just want to...", which I now mentally translate to "... ignore everything like security, reliability, or anything else that doesn't get me a checkbox tick for my assigned task."

Their "REST" API? It uses a HTTP GET to post a response, using an intermediate -- unauthenticated -- storage blob to stage the data.

"It worked in dev" came the reply to my probing questions.

Look, back in the "horrible old days of WS-*", when I still used to wear a developer hat, I could crack open Visual Studio in the morning and simply add a web service dependency to my project. In a matter of milliseconds -- seconds at worst -- it would automatically cough up a C# client for whatever it is that I wanted to talk to, and I could immediately start coding some actual business logic.

Today I watched a grown man type in the boilerplate code that the machine used to generate for me.

Apparently, this is better because it is "simple".

So simple that a programmer using HTTP GET for posting a reply can understand it.

Schema languages for "REST" exist (OpenAPI, RAML), and many people use them, but they certainly haven't taken off to the extent that WSDL did. I find that odd.

The new hotness is gRPC, which is based on protocol buffers, which uses an out-of-band schema file (you can do a certain amount with protobufs without a schema file, but nothing very useful). People appear to be happily adopting that, and aren't complaining about the need for a schema.

Your experience with SOAP is vastly different than mine to the point where I almost laughed out loud at your anecdote about adding a new web service dependency in a few seconds. SOAP is inherently complex, and needlessly so in my opinion. I've got personal battle-scars from trying to make Apache Axis and .NET play nice with all the various WS-* extensions needed for our use case.

There are always going to be people who, for lack of time, effort, education, whatever, use simple tools wrong. That's not an argument against simplicity. It is a recurring and false hubris to think we can fully specify any system and be "done." In the real world the are always confounding factors that violate the assumptions and constraints of any system we design. When that happens, I vastly prefer the more adaptable, less codified, simple system.

The fact that even those people above can still get stuff done even when using the tools "incorrectly" is an argument for the simple approach, in my view.

> trying to make Apache Axis and .NET play nice

That's key. If client and server were both .NET or both Axis, things were easier. As soon as they differed -- prepare for long-term pain such as restricting the data types you want to use to string and int. Limited interoperability.

> The fact that even those people above can still get stuff done even when using the tools "incorrectly" is an argument for the simple approach, in my view.

Spot on.

> I could crack open Visual Studio in the morning and simply add a web service dependency to my project. In a matter of milliseconds -- seconds at worst -- it would automatically cough up a C# client for whatever it is that I wanted to talk to, and I could immediately start coding some actual business logic

Visual Studio is a vastly underrated tool. If you're doing something it supports within the Microsoft ecosystem it can just plough through all of it for you. Doubly so if you add Jetbrains Rider.

The thing is, whenever we see something like this, it's because it's either easier to reimplement the thing from scratch than work out what the correct already-implemented solution should be, OR the already-implemented solution simply doesn't work in your environment because it's not supported.

It is sometimes depressing to watch the Javascript ecosystem try to build standard workflows only to knock them over again once they've managed to place one brick upon another, but Microsoft are quite capable of doing the same thing of their own accord (I say as someone surveying the wreckage that is WinUI3)

The only factor here is that the developer you were talking to here appears to be an idiot. They’d fuck it up in any stack. The technology is immaterial.

There's such a thing as falling into the pit of success.

A successful REST implementation using hand-rolled JSON protocols is in the middle of a vast field with hidden man traps full of sharpened bamboo spikes.

Equally vile is the majority of applications reliant on WS-* based protocols, their appalling lack of semantic consistency, cross-vendor incompatibilities, byzantine failure modes, and grotesquely siloed enterprise runtimes.

Equating certain technologies with incompetence, especially coupled to a blinkered misrepresentation of how to use them, remains a wholly unjustifiable misattribution. What's more, doing so with a reference to "the kids" further indicates a poor grasp of programmer demographics, and especially the denizens of this forum.

To sum up: most software is shit. Any correlations to variations in the uniformity of the shit that you may have observed are globally unsupportable.

Funnily enough I've found the opposite to be true nowadays. When someone offers a WS-* API all you need is the URL of the WSDL and you can start calling it, from whatever language and framework you like. When someone offers a "REST" API you have to spend hours just figuring out what specific stack of stuff they've actually done.

> from whatever language and framework you like

Eh, not really. Python SOAP clients are bad and have always been. In reality, SOAP works well only when using platforms sold by commercial vendors, who invested heavily in producing tools for it in an attempt to generate lock-in for their tools. Which means interop issues between platforms, for anything beyond the trivial case, are rife.

Whereas REST is so basic that you literally need nothing more than a standard HTTP client (and a JSON parser, these days; back then it would be some hand-rolled XML or even just encoded form-like data).

One of my favorite tricks with REST is sending a complete, bug-reproduction to a vendor as a simple one-line curl command. No arguing back and forth, just tell me when this curl command works properly.

Not a SOAP advocate by any means, but there's nothing stopping you from sending a curl command with an xml payload to a soap endpoint

Spose you're right, but I've never tickled a SOAP interface with curl. I fire up a python script when I need to do even the most basic interaction with a SOAP endpoint because, as Dustin Hoffman says in Hook, "Brace yourself lad, because this is really going to hurt."

I tend to go with RPC style apis with JSON/Protofbuf payloads for most things these days. IMHO it's the best of both worlds.

Python is actually where most of my experience with SOAP was. Import suds, point it at the WSDL, get on with your program. I had far fewer interop issues with that than with all the different ways people implement "REST".

Import suds, ditto.

Try doing that with NetSuite's WSDL in any non-Microsoft language and get back to me.

To do it in Java you need a custom-patched obsolete version of Apache Axis which you must compile and run under Java 6, and you must pass a very specific set of options to Axis when you run it. If you can manage all that, it does work.

The available SOAP libraries for Python are, AFAIK, not capable of ingesting the WSDL at all without crashing, though perhaps it would work if you had more than 16GB of RAM.

I really like rest. But, the 3 day php hack I built 10 years ago still brings in the cash. I must admit, it's not a service called by arbitrary clients. But the WSDL was text book and I have only one document that I generally need to refer to.

> About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that.

I would disagree. HTTP with REST is half a communications protocol. The server can't push data. There are hacks around this but it's not REST as defined by the dissertation. HTTP and REST took sockets and lobotomized them. They work well where you don't need duplex communication but the tragedy is that they have been forced into solutions where they don't fit because lowest common denominator. Think of how much simpler and more flexible a world we would live in if every web server behaved similarly to a message broker, for example. (GraphQL does this, so there is hope).

Web sockets are used now to push data to clients. REST+WS is a good combo.

Yes, and that's REST+..., not REST. If you've got a websocket, you're explicitly making the design choice that client-side application state can live outside the HTTP payload.

The key question is this: given a link and some subsequently-received websocket data, could a second client reconstruct the same application state given only a link? If the answer to that is "no", then what you have is not a system which supports HATEOAS. It's just not something people pay attention to once websockets are in the mix. Granted, you might get there by accident, depending on what you're doing with them, but I don't often see that as a design goal.

HTTP-Kit in Clojure-land has solved this beautifully with a unified interface for handling both WebSocket messages and HTTP requests, so using one function you receive requests/messages that you can act on, and responding to those also have the same interface.

http://http-kit.github.io/http-kit/org.httpkit.server.html#v...

I'm sure similar things exist in other ecosystems too, so it's not impossible.

I'm not sure I see how that solves the problem, beautifully or otherwise. How are links constructed?

https://http-kit.github.io/

The homepage is probably better to understand the project than the API reference provided above.

web sockets are used to push messages, but the messages end up being half-assed representations of what should be media types.

There's no reason that REST can't be bi-directional, but it means that each client is also a server. Most people don't write code like that.

In REST terminology, there's nothing particular special about a "client" or a "server". Clients make requests, servers respond.

There's nothing to stop the "server" connecting to the "client" and making requests to it to "push" data.

REST as a style is not particularly well suited to streams of data, which is what web sockets sort of solve in an unstructured way.

My favorite WS-* is WS-I, a bunch of guidelines about which versions/subsets of the other standards to use, if you actually want to talk to someone else.

(As someone who once had to implement a SOAP server supporting diverse clients, I'll never pass up a chance to get a dig in)

I remember the time someone told me what the "S" in SOAP stood for. They were clearly pranking me; I refused to believe it.

And to this day, nobody will give me the real answer! Whole world is in on this prank, and I've given up trying to find out.

Obligatory reference “S Stands For Simple:

http://harmful.cat-v.org/software/xml/soap/simple

The "S" stands for "Complex". It's in the spec.

While I agree with your premise that SOAP and WS-* is over-engineered, at the basic (simple SOAP + WSDL) I quite like it. There's a defined contract and you can generate strong-typed clients. I haven't checked in a while, but how is Swagger/OpenAPI in that regard?

I basically loathe code generators in general. :)

JSON Schema gives you the equivalent of WSDL. There are various libraries that will take a schema and create the strongly typed objects in the language of your choice.

Theoretically, if you have "Code on Demand", your client can ask the server for the code to handle a media type :)

JSON schema describes the format, more like XSD. WSDL is a lot more with definitions of operations, bindings etc.

REST's fundamental pitch is that for a large class of problems, a good format solves problems more easily than a rich set of operations.

Things like grpc and GraphQL seem to be the descendants of SOAP/WSDL.

GraphQL is quite nice as it kind of has the best of both worlds: a strongly typed schema for data and operations, while being fairly close to a simple JSON/HTTP API.

What I find a bit funny is that everything people write about WS/SOAP would be applicable to GraphQL as well.

For instance modifying your comment to: GraphQL services introduced resource addressing over JSON over HTTP that overloaded the equivalent of a URL.

It's always a pendulum. When we're lucky it's a "spiral", where when we swing back to the first pole we do it better than the time before. We're not always lucky.

You needed the tooling because the specs were so complicated and the output so verbose.