From our sprint two planning for OCL for OpenMRS with @darius and @rubailly, we discovered that we need to add REST endpoints to the OCLAPI to enable us implement dictionaries which will be a combination of collections and sources. We would appreciate your assistance during development. cc @darius @paynejd @rubailly @dkayiwa @emasys @waweru @shakira210791 @christopherkala @kodero
@hadijah315 it would be nice if your team can put together an initial proposal for this, based on reviewing how the current REST API generally behaves, and what data and workflows we want to support.
Some quick thoughts of my own:
- I would call the resource
openmrsdictionary(unless Jonathan wants us to just call thisdictionary) - of course we want to support the major GET, DELETE, and PUT/POST operations. (I don’t know if OCL typically uses POST or PUT for edits.)
- the object should have the top-level fields that correspond to what’s in the mockups for creating a dictionary. (you should fill this in)
- My first thought is:
- subresource for
/customconceptswhere a user adds/removes their custom concepts - subresource for
/conceptreferenceswhere a user add/removes concepts from CIEL and other dictionaries - subresource for
/conceptswhich is GET-only and is what we’d use to drive the UI that lists all concepts in a dictionary. (because this would need to include both custom concepts and references)
- subresource for
Thanks we shall do that
hello @darius @paynejd The document below highlights the Phase One endpoints for the dictionary creation. The structure involves first creating a django app in the existing oclapi called openmrsdictionary with the GET, POST, PUT AND DELETE endpoints dictionary as the document below illustrates.
@waweru thanks for doing this good start! I have made some pretty detailed comments, largely around the fact that we should make this REST endpoint more consistent with existing endpoints in OCL’s REST API, especially the collections one.
In addition, we’ll need to propose how subresources that contain the actual concepts will work. I made some suggestions on the doc.
Some of the suggestions might need some explanation. I could talk at our usual 2pm UTC time slot tomorrow (i.e. Friday) if you want.
sure @darius the comments are well noted and most of them will reflect on an actual task that is currently on the board. However tomorrow as Andela we are having an offsite and we will be unavailable for the entire day as we had communicated to @dkayiwa. Is it okay for us to schedule the call on Monday 2 pm UTC?
As always we appreciate your timely feedback and assistance as we build this platform.
cc @rubailly
@christopherkala
@hadijah315
@shakira210791
@emasys
hello @darius, concerning the development sync, i have setup the hangouts link here:
cc: @dkayiwa @rubailly @christopherkala @hadijah315 @shakira210791 @emasys @hadijah315
its ok tell us the time so that we join
1 Like
Ok we shall be there
1 Like
Will attend the call
He is working on it
hello @darius it is an organizational permissions issue, lets move to this hangout link. https://hangouts.google.com/call/MkGRWBLQQVgzl-VZrQQ1AAEI
Hi all, Thanks for drafting this! I just added additional comments in the gdoc. I thought this was on the right track after my initial review, but having given it more though, I would suggest that we modify the approach. Specifically, I think we should just add functionality on to the collection resource rather than create a new endpoint. As I noted in the gdoc, we are actually talking about a small set of modifications: adding a “linked source for custom resources”, adding a “preferred source”, and enhancing the “cascading” functionality. Otherwise, the new openmrsdictionary resource is the same as a collection. I think it would be redundant to duplicate this object and also take a lot more work than simply enhancing the existing one.
Can we discuss this sometime this week before we move much further? I’m happy to be wrong on this approach, but I think we may be making this harder than it needs to be!
1 Like
Hey @paynejd, Thank you so much for your feedback on the platform, I have been working on the openmrsdictionary resource endpoint in the past one week and i did raise a PR Here, And I do agree creating a dictionary endpoint to just reuse several functionalities of the collection was not the easiest thing given the fact that i had to understand how everything is related. However, voicing my personal opinion @darius had suggested the implementation of the concepts was to be done on the collections endpoints but have the routes reflect on the openmrsdictionary endpoint (This is subject to confirmation). As a team we were also a bit skeptical with the interference of the production version of the OCL, as with the changing needs, the endpoints specifically the openmrsdictionary might be changed further to cope with both the final MVP and and the MVP+, that i cannot tell at this point.
Meanwhile, we will be having our second demo tomorrow at 2pm UTC, it would be an awesome experience having you onboard to provide your feedback on this issue. Also @darius’s input could go a long way in shedding light on what approach may lead us home safely.
I had suggested some possible approaches in this google doc though I had actually intended for the team to make the decision about which approach to take. (In fact while I was typing those up I realized it’s not as straightforward as I had previously thought.)
I’m certainly open to just adding this to the existing collections endpoint, if we can keep the API clean and usable for the OCL-for-OpenMRS application we’re building.
Here are a couple things I’m not sure are straightforward if we just use the collections REST API:
- Creating a concept in the “linked source for custom resources” should atomically also add this concept and all its mappings to the collection
- Release a version of an implementation dictionary (presumably this means doing simultaneous linked releases of the collection and the source.
Let’s reserve some part of tomorrow’s demo call to discuss this further. (@paynejd and I will both be there.)
2 Likes
Sure looking forward…