Comment by jrochkind1 | Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Parent Full thread

> If the get-shit-done crowd wasn’t going to use SOAP, they still needed some standard way of doing things. Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and caching support, the simplest possible thing to do was just rely on HTTP’s existing semantics. So that’s what they did. They could have called their approach Fuck It, Overload HTTP (FIOH)

Having been a developer during that period of history, I'd say OP gets it about right, that's what happened.

For better or worse; it's not obvious to me that it was a poor choice. I do agree it somewhat misappropriated the "REST" term and misrepresented itself as being more "standardized" than it was -- also for more or less the reasons OP suggests: "that would have seemed recklessly blasé next to all the formal specification work that went into SOAP… a veneer of academic respectability".

Although I do recall some people right from the start really were interested in HATEOAS and trying to do it... I think it's practical benefits were somewhat elusive. It reminds me of "semantic web" in some ways, not sure if that makes sense...

I think not only was it a reaction against SOAP, but also against other common API styles like shoving everything into a GET query string or a POST body. Some name had to be attached to it. Simply 'HTTP' couldn't be used as both SOAP and query/POST both used HTTP as well (not to mention WebDAV).

As a young engineer implementing an early, prominent 'REST' service, it was kind of a surprise to me to find these lurking, unused verbs like PUT or DELETE in the spec. But they were there & that style beat the living tar out of SOAP or query string. But, in my memory, rfc2616 was used far more as inspiration and reference than Fielding's dissertation.

>For better or worse; it's not obvious to me that it was a poor choice.

It wasn't a poor choice. It was the least common denominator, and what put it over the top was JSON instead of XML and using URLs for more than the address of the end point to send your RPC to. The problem with SOAP and other APIs of the era was everything was bespoke once you got past transport (and transport often was hard because different systems implemented transport differently). With REST, transport was settled, and at least the URL forced some kind of hierarchy, and you could reason that GET /user/settings would return a settings object for the user.

I remember consulting for a tech company around '07 that needed to send remote (extremely high compute) tasks to a heavy iron server they dedicated to such work. They were using SOAP and having a very difficult time getting all the pieces and parts to work. At the time, Drupal 6 (a PHP web framework that used to be popular) had just released a "Services" module/plugin that enabled one to add a REST Service to any Drupal site.

Working with them to initially understand what the SOAP tooling required, and then comparing that to what that REST Services Module required was a no brainer. They had a team of 11 people working on the SOAP infrastructure, and they were all super happy to ditch it and get back to their real work. Re-writing as a RESTful API using Drupal Services merely as a bureaucrat to communicate with their heavy iron server only required myself and one other programmer I brought with me. About 3 weeks later we completely replaced their SOAP infrastructure. For years afterwards, I'd check in on them and it just worked.

The mistake of SOAP specs was to believe toolmakers were on their side, and tooling would magically solve all problems so that you would never actually have to look at what went down the wire. Whereas toolmaking companies were only on the side of making money, and looking down the wire was often unavoidable. REST went back to basics, simple protocols that humans could work on with little more than a text editor.

I mean, a tool-maker wants to sell you tools. Why wouldn't they want to sell you tools that obviated the need to look down the wire? If customers wanted those tools.

Maybe it was just harder/more expensive to make those tools than the "just solve it with tools" spec-makers anticipated. Rather than it being any particular misalignment of incentives.

It's just that the cross-vendor interop efforts were often skin-deep. They all tried to lock you in one way or another, by implementing this or that spec draft a bit differently and making specs overly-verbose and burdensome to implement for anyone without a big budget. Microsoft had just won the browser wars that way, after all. But hey, if you stuck to one vendor, it all worked like magic.

I see, the interoperability issue makes sense, and now I'm starting to remember it. (I never did THAT much with SOAP).

But you really think the specs-writers (being some of the same people as the tool-makers?) intentionally made the specs overly-verbose and burdensome to implement, to protect their tools businesses? That's different from what you said in your original comment, about spec-makers "believing toolmakers were on their side" -- now you're saying the spec-makers were the tool-makers and not actually on the end-developer-user's side!

I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem, rather than intentionally sabotaging it for profit. But you think I'm too optimistic?

It really depends on your view of W3C as a standard body.

> That's different from what you said in your original comment

SOAP basically started as an attempt to learn from the mistakes of CORBA and RPC, and I think it started with good intentions all around. When complexity hit, however, the original designers basically went "we'll deal with it in the various sub-specs, but don't worry, tooling will take care of this anyway". I do think most of them were not malicious in this approach. Meanwhile, vendors understood where the wind was blowing, and got themselves heavily involved in the various efforts - hence the proliferation of WS-* and incompatibilities.

> I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem

Considering the amount of money and manpower that went into these efforts, ascribing it all to lack of skills would possibly end up being less optimistic - about the state of corporations, the work they produce, and what this means for human progress.

TBH I think the charitable reading is just that there were too many cooks in the WS kitchen. I feel some of them burnt pans on purpose, maybe they didn't, but at this point it doesn't matter much.

Is there an analog here with the recent interest in graphql?

In what way? What is GraphQL competing with? I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip. What preceded GraphQL was REST with a whole lot of inconsistent include_xyz query params.

> I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip

I don't know much about history so that might be a wild guess, but did people try to build SQL directly from the client and send it?

I'm also guessing, but I suspect that the sharp rise of mobile was a contributing factor. Mobile can have good throughput but not so good latency so packing more per request makes a lot of sense.

At one place I worked we actually made two BFF (backend-for-frontend) servers that took one client request, made many within datacenter requests, put a single response together and sent it all back. We had one for mobile and one for web. We only had one datacenter region so made sense for global users regardless of throughput.

That makes a lot of sense, thanks for sharing that.

Odata

There were a couple of additional overlapping factors that contributed to the rise of the FIOH crowd and misinterpretation/misuse of REST and HATEOS:

1. the growing popularity of AJAX and SPA frameworks

2. the rapid growth in mobile clients

We had to make a lot of trade-offs from ideal REST/HATEOS architectures to support these new clients.

Eventually for some it wasn't enough. Facebook launched GraphQL in response to the problems with REST-based APIs they perceived for mobile clients. Fast forward to today and we're walking back to the RPC protocol era.

The problem I have with this advice of, "choosing the right architecture for your application," is that it encourages an ecosystem of competing protocols. Exactly what made the prior RPC-era so annoying... not only was SOAP incredibly bloated and hard to deal with but every services that implemented it also implemented their own snowflake version of it with it's own errors and interpretations. Even if you had a "compliant" SOAP client it was likely that it would be incompatible with your service providers' service in some undocumented way.

At least with FIOH-style APIs you just have to deal with their inane reasoning for return "200 OK: Error" responses and not implementing HATEOS.

Reply on news.ycombinator.com