-
Notifications
You must be signed in to change notification settings - Fork 51
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
Draft architecture for LORIS API calls within LORIS-MRI Python #1148
Draft architecture for LORIS API calls within LORIS-MRI Python #1148
Conversation
@maximemulder I just realized that for HBCD, I do call the API and I added the following in database_config.py:
I am only using the API to create issues in the issue tracker and this is how the token is generated:
and then
That system works well for HBCD. Wondering if that could work for your case as well. |
Hhhhm, interesting, there are definitely some parts that I don't have in my code (why |
Summary of today's design meetingThis PR design is fine. The answers to the unanswered questions are the following:
I looked into Swagger codegen in more details. It certainly generates a lot of the boilerplate to us, which is more practical to create the API client, but the generated code seems to be of lesser quality, and notably does not seem to have type hints (big no-no for me). A final not really related to this PR, but another one that should arrive next week, is how to pass user credentials to a script that calls the API. One solution is simply to store a single user's credentials in the config file, as @cmadjar does it. However, I need a script which can be ran by multiple users, and the options we considered for the password are these ones:
I will ask Sylvain about this as he might have some insights or an opinion. |
After some discussion with Rida, we concluded the script should live at the BIC and not LORIS-MRI, so not planned for now. |
This is a draft architecture to call the LORIS API from within the LORIS-MRI Python code (issue #1147), using the API calls from the DICOM upload API PR (Loris#9154). The code is not fully working yet (TODO: error handling, type conversions), but it presents the broad lines of the architecture:
There is an
Api
class used as the canonical way to make API calls. It stores the LORIS URL and an API token, and can be passed around to any code that needs to make API calls. It has a methodapi.call(...)
that allows to call any API route with unstructured values (route as a string, returns the response without parsing it).There is a
python.lib.api
namespace that contains specialized wrappers for each API route. These wrappers allow to use the API in a structured way, by passing the route arguments directly as function arguments, and by returning structured objects.Unresolved question, in which namespace to put this
Api
class ?lib.api
(which this PR does, EDIT: this is a bad choice because there is a name clash with thelib.api
namespace) ?lib.dataclass.api
(EDIT: I prefer this option) ?lib.api.api
?Unresolved question, how to structure the objects returned by the API calls ?
from_object
,from_json
,from_dict
) ?dataclasses-json
andpydantic
)Unresolved question, how to structure the API wrapper files ?
lib.api.routes
,lib.api.types
) ?The (which this PR does) mentions are just here as an indication, I am not particularly advocating for these options over others.