search

Police-Data-Accessibility-Project / data-sources-app

An API and UI for using and maintaining the Data Sources database
MIT License
2 stars 5 forks source link

Do we need as many columns in some endpoint responses? #359

Open maxachis opened 2 months ago

maxachis commented 2 months ago

Certain queries, such as the GET method in the DataSourceById resource, return a large number of values. In the case of DataSourceById's GET method, it returns 66 distinct values, which strikes me as a tad excessive. This adds burden onto testing, refactoring, and maintenance. We may want to consider whether all of these values are truly essential to our responses.

josh-chamberlain commented 2 months ago

Could you post an example of the 66 values you're getting, just so we're on the same page? We can probably cut some—but I would want to do it by cutting them entirely, not storing them in the database at all.

If we don't return all the public database properties, we have a different problem—every time there's an edge case requiring a property we keep in the database but don't use too often, we have to go add it to the API response, docs, tests, etc. If we're not going to return them in the API, what's the point of having them?

GraphQL solves this by having users ask only for the properties they need. One day.