4 ms·

In an ideal world, probably, or using {insert technology here} that does that natively, yes. In my experience, it hasn't been the case: designing a REST API (I

by Fradow 6y ago

In an ideal world, probably, or using {insert technology here} that does that natively, yes. In my experience, it hasn't been the case: designing a REST API (I know REST complexifies the API compared to tailored RCP) that behaves properly for the client is magnitude more work than rendering HTML with data server-side. The main difference is switching the question from "what does this page needs to render for this user", to "what are all the things the front-end might want to access through this API for this user, and how do the front-end plan on filtering". The former is obviously easier to answer, and as the result easier to code.

davnicwil 6y ago
I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense. Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging. For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.

by Fradow 6y ago

davnicwil 6y ago

I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense. Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging. For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.