2 ms·

I agree with the underlying point being made here: a separate API (REST/JSON) that serves data should be kept separate from the endpoints that serve an applicat

I agree with the underlying point being made here: a separate API (REST/JSON) that serves data should be kept separate from the endpoints that serve an application, in this case, HTML-based. It seems like building your application around a single API that is also used to provide data externally saves you time, but you end up polluting that API with presentation concerns needed to drive the application's reports/grids/views. It's not worth the mental energy to consider how changes you need to make for presentation might affect the 'purity' of your public API. Returning hypermedia from the 'internal' API just forces that separation: there's no expectation that this 'data' is being returned for consumption by anything except the app that uses it.

twelfthnight 3y ago
It's a really good point. It's natural, but if an API is primarily used to serve a front end, all other internal consumers (analyst, data science, etc) take a back seat. I think it also leads to situations where most of the engineers on the team don't really understand the "natural" data domains, but always think about it in a front end lens (e.g. pagination, merging of different concepts because they are on the same UI element, very quick endpoints only, JSON instead of less web friendly serializations, etc)
BiteCode_dev 3y ago
Also the filtering, grouping, caching, pre-fetching and ordering contraints are unlikely to be the same. Even worse if the json api is public, as it may need to restrict capabilities.