search

PhilanthropyDataCommons / service

A project for collecting and serving public information associated with grant applications
GNU Affero General Public License v3.0
8 stars 2 forks source link

Add `changemakerId`, `dataProviderShortCode`, and `funderShortCode` filter options to the GET `/sources` endpoint #1295

Open hminsky2002 opened 2 weeks ago

hminsky2002 commented 2 weeks ago

This came up during work on front-end issue 836(https://github.com/PhilanthropyDataCommons/front-end/issues/836), and the case is as follows: if a user were to want to retrieve a Source by shortcode, they would need to fetch all Sources present in the database, and filter client-side. We've standardized on pagination parameters for most of our entity-retrieving endpoints, perhaps it would be worthwhile to consider some sort of search query, where in one could pass any/all relevant fields that they are searching for.

bickelj commented 2 weeks ago

Surprising, I am looking at API now to verify! @hminsky2002 is right, we only allow paginated GET of all sources or GET by internal PDC id. So there is no reliable way to get one by text one knows is in a short code.

slifty commented 2 weeks ago

I don't think we need a full blown search (unless there is a use case I'm not familiar with)

What we do want is the ability to filter by a known foreign key value! I just updated the issue to reflect that.

bickelj commented 2 weeks ago

Simple query filters by those IDs is easier and more precise. I assume multiple query parameters would be interpreted as requesting intersection and not union, given that each is a filter -- or an error to provide two of these filters. Handling that situation is the only weird part.

slifty commented 2 weeks ago

I assume multiple query parameters would be interpreted as requesting intersection and not union, given that each is a filter -- or an error to provide two of these filters. Handling that situation is the only weird part.

Yes to intersection!

My .02 is that the correct behavior isn't an error, but just returning an empty set. That's ok, the client would figure it out. It's predictable and consistent (and technically valid -- just not a particularly meaningful thing to query)