-
-
Notifications
You must be signed in to change notification settings - Fork 205
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 Endpoint for getting person by UUID #9065
Comments
Okay, I figured I would throw out a bit of a technical design. This is all entirely speculative (riffing on the content/discussion in this doc), but I figured the most practical way to proceed here was to start with a specific proposal that we could discuss. @garethbowen the main goal here is to hammer out an over-arching design. Once we have an idea of what that should look like, I can iterate on this proposal with more detail. I am happy to jump on a call to discuss this further if that would be more effective! Tech DesignThe actual
|
@jkuester Thanks for taking the initiative and kicking this off - it's been on my todo list too long!
I think so, mostly from the perspective of future proofing. There's a good chance it won't be necessary but if it is found to be useful in future then migrating would be potentially difficult. APIs must also be versioned/versionable and I wonder if namespaces are the way to achieve this too.
Keep this as an MVP IMO.
It's very difficult to introduce validation into an existing system, as we just found out. It may work if we limit it to just the pieces that are absolutely necessary - if we know the CHT will break if you create a contact without a contact_type then we should fail early. But avoid the temptation of validating nice to haves for legacy data. I think this is another thing we could push out of the MVP. Some other thoughts...
I think it would be useful to put this in a Google Doc to get more feedback from the wider team - some of the decisions being made here will affect anyone working on Core for some time to come. |
👍 Incorporating all your suggestions into a new iteration of this documentation that is back in your original proposal document.
Yes, the |
Updated tech design - specifically for this MVP issueThis is based on conversation and iteration in the proposal document.
Data flow with pouch vs fetch adapters@garethbowen, does this diagram match what you were thinking as far as the usage of separate adapters in webapp? flowchart TD
subgraph webapp
subgraph webapp/cht-datasource[cht-datasource]
subgraph webapp/cht-datasource/online[Online User]
webapp/cht-datasource/online/fetch[fetch]
end
subgraph webapp/cht-datasource/offline[Offline User]
webapp/cht-datasource/offline/pouch[PouchDB]
end
end
end
subgraph api
subgraph api/cht-datasource[cht-datasource]
api/cht-datasource/pouch[PouchDB]
end
end
couchdb[(CouchDB)]
api/cht-datasource/pouch ---> couchdb
webapp/cht-datasource/offline/pouch ---> couchdb
webapp/cht-datasource/online/fetch --->|GET api/v1/person| api
|
@jkuester, we don't need an exhaustive set of tests for the controller, but a simple test to validate that everything is working properly should be okay. I may need to see more progress on this to understand it clearly. |
@garethbowen @m5r after doing all this work to stand up
Any thoughts here? Am I missing something? |
Splitting off the get-place functionality into #9194 so that we can close this issue and ship on |
Closed by #9090 |
Thanks a lot @jkuester!! |
Met with @garethbowen and @m5r today to discuss #9065 (comment). The primary conclusions included:
Of these conclusions, I think that the only one that needs to be address in this issue is the first. |
NOTE: the get-place workflow has been split into #9194
Is your feature request related to a problem? Please describe.
Currently the only REST api options for getting contact data are:
GET /api/v2/export/contacts
which returns a little bit of data about all the contactsGET /api/v1/contacts-by-phone
- which returns a list of fully hydrated contacts for a given phone numberA more basic API is needed for being able to retrieve contact data for just a specific contact. (e.g. you just got the data for a user via
GET /api/v2/users/{{username}}
and now you have theircontact_id
value, but you want to get all the data for that contact.)Describe the solution you'd like
We already have
POST /api/v1/places
andPOST /api/v1/places
, so we could haveGET /api/v1/places/{{id}}
andGET /api/v1/people/{{id}}
.Additional context
As noted in #8889, we should implement the core data access aspects of this via a new data source library that can be shared between API and webapp with a well defined interface.
cc @m5r @mrjones-plip
The text was updated successfully, but these errors were encountered: