-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Endpoints for getting contacts by type #9193
Comments
After a bit of assessment, I've decided to break this task down into smaller tasks in the following way.
|
This was referenced Jul 3, 2024
I will be pushing each sub-task changes to this branch |
sugat009
added a commit
that referenced
this issue
Aug 23, 2024
…erables in cht-datasource (#9311) Co-authored-by: Joshua Kuestersteffen <[email protected]>
sugat009
added a commit
that referenced
this issue
Sep 2, 2024
…erables in cht-datasource (#9368) Co-authored-by: Joshua Kuestersteffen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
As noted in #8889, getting the contacts of a specific type is needed for cht-user-managment.
Describe the solution you'd like
Endpoints should also accept the following query parameters to allow for paging through the data:
limit
- default is100
skip
- default0
When it comes to the cht-datasource api, things will be a bit interesting. On one hand, most consumers of the lib will not want to manually deal with paging, but instead we should return something like an
async Iterable
so the paging it completely abstracted away. However, the api code will need to be able to make a targeted request for a specific limit/skip since that is what it will be receiving as a request and for best performance we will need to be able to pass those though directly to the Couch view query... Perhaps we just provide both functions in cht-datasource:limit/skip
and returns an array of values.Describe alternatives you've considered
Other ways to structure the API include:
api/v1/clinic
api/v1/place/clinic
However, these do not seem any more clear than just using a query parameter and are definitely less flexible.
The text was updated successfully, but these errors were encountered: