2 ms·
A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place. SDKs are an enormous effort to create and maintain for
by daliwali 9y ago
A good rule of thumb is that if a REST API has an SDK, then it's not really RESTful in the first place.
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.
- wstrange 9y ago> 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.
- daliwali 9y agoEvery 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. [0]: https://schema.org/FlightReservation https://schema.org/FlightReservation