> SDKs are an enormous effort to create and maintain for every HTTP API,
Hence the attraction of generating client and server stubs with gRPC
> Browsers (and by extension, websites) are not good examples of REST in practice?
The "client" of a website is a human being - and we are very good at interpreting dynamic content.
As an example: There are probably 100+ websites out there where you can book a ticket for a flight. It might be painful, but as a human, I can figure out how to navigate and book a flight on any of those systems.
I challenge you to write a REST client that can do the same.
Every single one of those websites use HTML, a common media type, with semantics defined in that standard. What's missing are the application-level semantics like what's a "flight search" and "flight booking", which can be solved with linked data. In fact, this already exists! [0]
In theory, using a common media type and linked data vocabulary, one can make this hypothetical scenario of an automated machine-to-machine flight booking system happen. In practice, it requires either changing how people think, or build APIs to begin with. It's a steep uphill battle to change how people think, making this happen is much easier.
SDKs are an enormous effort to create and maintain for every HTTP API, I think it's a malpractice that is all too common.
Browsers (and by extension, websites) are not good examples of REST in practice? I don't know what world you're in.