3 ms·
Pretty much this. I was very anti-REST back circa 2015-2017 when I started doing web dev. I was doing solo work and all my services were JSON-RPC (I can't remem
by daxfohl 4y ago
Pretty much this. I was very anti-REST back circa 2015-2017 when I started doing web dev. I was doing solo work and all my services were JSON-RPC (I can't remember whether that was an actual standard then or if I just rigged it). I was (and still am!) into functional programming, and RPC seemed to fit better: it's just a remote function call. Nakedly PUTting a resource just seemed to violate my idea of good architecture.
In 2017 I left to join Azure, which is REST-heavy (in all this, I mean "modern" REST, not "Fielding" REST). I hated it at first, but eventually saw how nice it is to have the conventions. Less to explain in public API docs, easier to generate scaffolding, common themes of how to destructure incoming requests in middleware handlers and middle-tier services, a standard way to serialize references to resources across the platform. I was a convert.
Moving to google in 2021, they're still very RPC, and it feels so cluttered and arbitrary. I'm not there anymore.
Yes, REST is roughly just some conventions around RPC at the core (though you get things like caching for free), but ultimately it's a really nice set of conventions that are easy to follow and limit surprise, and are standard across the industry. As one user commented, you do sometimes have to work around REST to get it to fit, typically futzing in headers or request metadata, but to me the pros outweigh the cons.
- gspetr 4y agoCan you point to some sources of information about the modern REST you are talking about?
- talideon 4y ago"Modern" REST generally disposes of things like hypertext and representations as being too complex, instead leaning on things Swagger/OpenAPI to declare an IDL equivalent, so you're getting effectively an RPC system with some of the guarantees you'd get from REST. Azure's APIs are more RESTful than most: they actually bother using resource URLs as identifiers. I've never understood what people find so hard about HATEOAS. It's like people have never interacted with a HTML form or followed links to stuff, or have difficulty figuring out how webpages can consist of multiple linked resources.
- naasking 4y ago> I've never understood what people find so hard about HATEOAS. It's like people have never interacted with a HTML form or followed links to stuff, or have difficulty figuring out how webpages can consist of multiple linked resources. Or that an object graph of a system is a web of linked resources, and that every program has an entry point object/interface from which you can navigate to any part of that object graph, just like in REST.
- spdionis 4y agoIt's not hard, it's just wasteful and not very useful.
- daxfohl 4y agoYes this is what I meant. The way Azure does it is kind of nice (to me at least, as an ex member of ARM) because ARM can generically check access just by the URIs. The downside though is that the URI also includes the subscription and tenant id, so ARM has to deal with the URI being stale after stuff gets moved around. And then the advent of management groups and cross-tenant access made it so it's not quite so straightforward anymore. But it was still quite useful.
- still_grokking 4y ago> "Modern" REST generally disposes of things like hypertext and representations as being too complex, instead leaning on things Swagger/OpenAPI to declare an IDL equivalent, so you're getting effectively an RPC system Now the question is: Why do people insist to calling some (no standardized) ad hoc RPC protocol "REST(full)"?