josh-chamberlain
commented
1 month ago The namespace idea is a good one. Most of these make sense to me. My comments here apply, but what about:
GET data-sources/ gets all (I think we should prefer the search endpoint for most use cases)
GET data-sources/{data_source_id} gets one
GET data-sources/id/{data_source_id} could be used if needed
POST data-sources/ adds one
PUT data-sources/{data_source_id} changes one
GET data-sources/search gets multiple too
To reorganize
data-sources, partly in line with the requirements in #362, I propose the following:Associate all endpoints with the
data-sourcesnamespace. In other words, all endpoints affecting the data sources begin with/data-sources/. The changes would be as follows:/data-sourcesGETmethod becomes/data-sources/all/data-sourcesPOSTmethod becomes/data-sources/add/data-sources-by-id/{data_source_id}becomes/data-sources/by-id/{data_source_id}for bothGETandPUTmethods/data-sources-mapbecomes/data-sources/map/data-sources-needs-identificationsbecomes/data-sources/needs-identification/data-sources/link-to-agencyendpoint, which associates a data source with an existing agency (POST), obtains information about an existing link (GET), updates an existing link (PUT) or deletes an existing link (DELETE).The rationale for this is as follows:
GETandPOSTmethods of/data-sourcesenables better clarity in endpoint logic, and additionally enables performing #365 to add aGETmethod to/data-sources/addwhich retrieves all columns which can be added.data-sourceslogic in the future, by associating them with a separate namespace.data-sources/link-to-agencyendpoint enables us to add management of linking logic between data sources and agencies, which previously was only done by https://github.com/Police-Data-Accessibility-Project/data-sources-mirror and by directly interfacing with the database, rather than through an endpoint.