[cyberax]

> There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards

Care to list them? REST mania started around early 2000-s, and at that time there was only CORBA available as a cross-language portable RPC. Microsoft had DCOM.

And that was it. There was almost nothing else.

It was so bad that ZeroC priced their ICE suite based on a PERCENTAGE OF GROSS SALES: https://web.archive.org/web/20040603094344/http://www.zeroc.... Their ICE suite was basically an RPC with a human-designed IDL and non-crazy bindings for C/C++/Java.

Then the situation got WORSE when SOAP came.

At this point, anything, literally anything, that didn't involve XML was greeted with enthusiasm.

[jerf]

I don't just mean the ones that existed at the time of the start of REST. I mean all the ones that have come up since then as well and failed to displace it.

Arguably the closest thing to a prescriptive winner is laying OpenAPI on top of REST APIs.

Also, REST defined as "A vaguely HTTP-ish API that carries JSON" would have to be put later than that. Bear in mind that even after JSON was officially "defined" it's not like it instantly spread everywhere. I am among the many people that reconstructed something like it because we didn't know about it yet, even though it was nominally years old by that point. It took years to propagate out. I'd put "REST as we are talking about it" as late 200xs at the earliest for when it was really popular and only into the 2010s as to when you started expecting people to mean that when they said "Web API".

[cyberax]

> I mean all the ones that have come up since then as well and failed to displace it.

They won inside large companies: Coral in Amazon, Protobufs/gRPC in Google, Thrift in Facebook, etc. And they are slowly spreading outside of them.

OpenAPI is indeed an attempt to bring some order into the HTTP RPC world, and it's pretty successful. I'm pretty sure all the APIs that I used lately were based on OpenAPI descriptions.

So the trend is clear: move away from loosely-defined HTTP APIs into strict RPC frameworks with code generation because this is a superior approach. But once you start doing it, HTTP becomes a hindrance, so alternatives like gRPC are gaining popularity.

> Also, REST defined as "A vaguely HTTP-ish API that carries JSON" would have to be put later than that.

Ruby-on-Rails came out in 2005, and Apple shipped in 2006. REST-ful APIs were one of its major selling points ( https://web.archive.org/web/20061020014807/http://manuals.ru... ).

AWS S3 API, designed around the same time, also was fully REST-ful. This was explicitly one of its design goals, and it was not really appreciated by most people.

[jerf]

Yes, I agree with all of that stuff about using more structure in larger companies.

My meta point is that it is easy for programmers to come to the conclusion that all that should exist is the stuff that large companies use, as I see so many people believe, but if you try to model the world on that assumption you end up very frustrated and confused by how the real world actually works. You can't push a highly proscriptive, very detailed, high up-front work methology out on everyone. Not because it's a bad idea per se, or because it "wouldn't work", but because you literally can't. You can't force people to be "better" programmers than they are by pushing standards on them.

My gut leans in the direction of better specifications and more formal technologies, but I can't push that on my users. It really needs to be a pull operation.

[cyberax]

> You can't force people to be "better" programmers than they are by pushing standards on them.

Oh, for sure. A company can just mandate something internally, whether it's a good idea or not. But superior approaches tend to slowly win out on merit even in the wider world. Often by standardizing existing practices, like OpenAPI did.

And I believe that strict prescriptive APIs with code generation are superior. This is also mirrored by the dynamic and static typing languages. I remember how dynamic languages were advertised in early 2000-s as more "productive" than highly prescriptive C++/Java.

But it turned out to be a mistake, so now even dynamic languages are gaining types.

[motorest]

> Care to list them?

From the top of my head, OData.

https://www.odata.org/

[cyberax]

This is a recent project. REST happened basically in the environment where your choices were CORBA, DCOM, SOAP and other such monstrosities.

Of course, REST won handily. We're not in this environment anymore, thankfully, and REST now is getting some well-deserved scrutiny.

[motorest]

> This is a recent project.

OData officially started out in 2007. Roy Fielding's thesis was published in 2000.

[cyberax]

So it was a contemporary of Protobufs, Cap’n Proto, and other frameworks. Facebook had Thrift, Amazon had Coral, and so on.

They appeared almost simultaneously, for the very same reason: REST by itself is too vague and unreliable.

[bborud]

I think all of them came a bit later. And I do remember Thrift. With regret.