Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

> No it isn't. Evidence: I'm reading this in a web browser.

And you might not that this site is _not_ REST-ful. It's certainly HTTP, but not REST.

> Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics?

Or whether we want to use If-Modified-Since header or explicitly specify the condition in the JSON body. And 6 months later, with some people asking for the latter because their homegrown REST client doesn't support easy header customization on a per-request basis.

Or people trying (and failing) to use multipart uploads because the generated Ruby client is not actually correct.

There is _way_ too much flexibility in REST (and HTTP in general). And REST in particular adds to this nonsense by abusing the verbs and the path.

REST’s original meaning is pretty ambiguous and poorly specified. The dissertation was written to describe the design and architecture of the HTTP protocol itself, which was largely designed with and alongside this concept of REST. It predates a lot of modern Internet usage and thus doesn’t map perfectly onto current paradigms. I’d argue that even saying a “REST API” means you’re already in the land of impurity.

“True REST” is expounded upon by Fielding in a variety of places, and is essentially HATEOS (hypermedia as the engine of application state). But no one, and I mean no one, actually does that. Thus, in order to communicate effectively and “have an agreement on terms,” as you say, we need a less strict definition. I provided my suggestion.

If your suggestion is to go back to the primary sources, I have. Multiple times. It does not provide a particularly concrete or useful definition (because its point was not to define REST). If it had, trying to define it would be much less of a no true scotsman game. Notice that we’re not sitting here debating the meaning of HTTP.

> Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response.

Sure. Until you need some fields to be optional.

> This makes stable APIs so much easier to integrate with.

Only on your first iteration. After a year or two of iterating you're back to JSON, checking if fields exist, and re-validating your data. Also there's a half dozen bugs that you can't reproduce and you don't know why they happen, so you just work around them with retries.

Why do you say that? I'm involved in the planning for bidi streaming for a product that supports over 200M monthly active users. I am genuinely curious what landmines we're about to step on.

What's funny is none of these are very good, but they're now the most common standards. They are designs to be sure. But they lack the one thing that makes a standard valuable: not having to do a bunch more work every time you want to work with a single new application.

The idea many of you were literally raised with, that you have to look up an application's specific functions, and write your own code to specifically map to the other application's specific functions? That basically didn't exist before, like, 2000.

Look at any network protocol created before HTTP (that wasn't specific to a single application). A huge number of them (most of them?) are still in wide use today. And basically none of them require application-specific integration. FTP, SSH, Telnet, SMTP, DNS, TFTP, HTTP, POP3, SUNRPC, NNTP, NTP, NetBIOS, IMAP, SNMP, BGP, Portmap, LDAP, SMB, LDP, RIP, etc. All layer-7, all still used today, decades after they were created. And every single application that uses those protocols, is not custom-built to be aware of every other application that uses that protocol. They all just work together implicitly.

There's almost no benefit to even using gRPC, OpenAPI, REST, etc. You could come up with a completely new L7 protocol, and just say "if you want to be compatible with my app, you have to add support for my new protocol. here's my specification, good luck.". Sure there are benefits on the backend for transmogrifying, manipulating, re-routing, authenticating, monitoring, etc the underlying protocols. But as far as the apps themselves are concerned, they still have to do a ton of work before they can actually communicate with another app. One other app.

Now it's a feature. People brag about how many integrations they did to get app A to work with apps B, C, D, E, F, G. Like Oprah for protocols. "You get custom code, and you get custom code, and you get custom code, and you get custom code! You all need custom code to work with my app!"

You could say, oh, this is actually wonderful, because they're using a common way to write their own layer-8 protocols! But they're not even protocols. They're quirky, temporary, business logic, in a rough specification. Which is the way the big boys wanted it.

Corporations didn't want to have to abide by a specification, so they decided, we just won't support any applications at all, except the ones we explicitly add code to support. So application A can talk to apps B and C, but nothing else. It's ridiculous. We regressed in technical capability.

But it has to be this way now, because the OS is no longer the platform, the Web Browser is. No protocol can exist if it's not built into the browser. The bullshit people try to sell you about "middleboxes" is bullshit because middleboxes only matter when all the apps are on a Web Browser. Take away the web browser and middleboxes have no power. If the entire internet tomorrow stopped using HTTP, there would literally be no choice but to do away with middleboxes. But we won't go there, because we won't get rid of the web browser, because we like building abstractions on abstractions on abstractions on abstractions on abstractions. People get dumber, choices get smaller, solutions get more convoluted.

C'est la vie. The enshittification of technology marches on.