3 ms·

> The problem when using REST "correctly" is that the way your objects interrelate is not necessarily the same way on the backend as it is on the UI. So you end

by qyv 11y ago

> The problem when using REST "correctly" is that the way your objects interrelate is not necessarily the same way on the backend as it is on the UI. So you end up creating custom REST endpoints for complicated UI that does not map directly to how your objects are related in the database. Not defending the article here, but I don't see this as a problem at all. Yes, you API objects should not necessarily map directly to your persistence layer; that is a good thing. The problem domains of the UI and the persistence layer are completely different and should therefore be modelled differently. Your API mediates between the two, acting like a repository for your UI models and abstracting away the persistence layer completely.

vlunkr 11y ago
Right, you shouldn't feel like you are "sending a SQL query to the backend" as OP suggests. An API is an abstraction layer, you shouldn't have to know anything about the database to use it.
Mickydtron 11y ago
You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different versions of those views. You can end up with a proliferation of API endpoints, each serving a custom view object for each different type of view, or you make your endpoints generic enough to serve all views, thus serving more data than any one view will ever use. You'll naturally have a tension between endpoint reusability and specific usefulness. The article actually seemed to have some of that tension itself, saying both "If you only want a subset of that graph, make an endpoint around that subset." and also "[Ad hoc endpoints] aren't REST", without giving any guidance as to how to make endpoints around arbitrary subsets of graph data without descending into being ad hoc. I'm not saying that you can't balance these with a good REST API, just that there is a real tension.

by qyv 11y ago

vlunkr 11y ago

Right, you shouldn't feel like you are "sending a SQL query to the backend" as OP suggests. An API is an abstraction layer, you shouldn't have to know anything about the database to use it.

Mickydtron 11y ago

You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different versions of those views. You can end up with a proliferation of API endpoints, each serving a custom view object for each different type of view, or you make your endpoints generic enough to serve all views, thus serving more data than any one view will ever use. You'll naturally have a tension between endpoint reusability and specific usefulness. The article actually seemed to have some of that tension itself, saying both "If you only want a subset of that graph, make an endpoint around that subset." and also "[Ad hoc endpoints] aren't REST", without giving any guidance as to how to make endpoints around arbitrary subsets of graph data without descending into being ad hoc. I'm not saying that you can't balance these with a good REST API, just that there is a real tension.