Skip to content
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

REST API faults #261

Open
3 of 17 tasks
appukuttan-shailesh opened this issue Mar 19, 2020 · 6 comments
Open
3 of 17 tasks

REST API faults #261

appukuttan-shailesh opened this issue Mar 19, 2020 · 6 comments
Assignees

Comments

@appukuttan-shailesh
Copy link
Collaborator

appukuttan-shailesh commented Mar 19, 2020

I found the following problems with the REST APIs:

  • [ ] GET for models does not return 'license' and 'project' parameters
  • GET for tests does not return 'publication' and 'age' parameters
  • GET /authorizedcollabparameterrest/ should also return values for other parameters like 'license' (model instances) and 'status' (tests)
  • GET /authorizedcollabparameterrest/ should change key 'data_modalities' to 'data_modality' to align with regular usage
  • EDIT for models returrns uri (e.g. {'uuid': 'https://nexus.humanbrainproject.org/v0/data/modelvalidation/simulation/modelproject/v0.1.0/bc38a55a-4134-438f-b98a-4fcd373912bc'}) whereas intended output is only UUID, as is with other APIs
  • API error messages lack info for debugging. E.g. for duplicate test alias while creating test, we simply get: "Exception: Error in adding test. Response = <Response [400]>"
  • POST for tests sets 'cell_type' to 'Not applicable' when no value is specified (None); other params seem fine.
  • when registering a model with all same parameters (no alias, same name), the API executes successfully, but returns the same UUID each time. Changing a parameter such as 'brain_region' doesn't change anything. But on changing the name, we get a new UUID.
  • listing of all results via GET https://validation-v1.brainsimulation.eu/results/?order=score_type fails (<h1>Server Error (500)</h1>); retrieving indiviual results still works e.g. GET https://validation-v1.brainsimulation.eu/results/?order=score_type&id=073151b6-dfbb-4015-a8ea-24a304c927ec
  • GET on indivudal results doesn't return parameters such as 'platform', 'hash', ' '.
  • GET on tests seems to retrieve only 100 entries
  • GET on models returns output with keys: ["models", "page", "total_models", "total_nb_pages"], while GET on tests returns output only with key: "tests"
  • GET on invalid ID/alias works inconsistently for models, tests, results. Invalid model_id and test_id return errors, while model_alias, test_alias and result_id return empty lists.
  • As part of new REST API changes, we should have POST on model creation (and tests) to return the entire JSON object (and not just the newly created UUIDs). The model instances UUIDs are unavailable in the current scenario and thus would demand an extra request for populating the model detail page immediately after creation. This would also help in other situations.
  • POST on models takes an array of instances, whereas POST on tests can accept only a single instance. The instances for tests are named "codes" and should probably be named "instances" as in the case of models. The keys for JSON for POSTing to models and tests are also not consistent [(model, model_instance) vs (test_data, code_data)].
  • POST on models accepts empty string ("") for fields such as species, whereas the same isn't accepted by POST on tests.
  • decision needs to be taken (and subsequent implementation) on handling "images" under models. Do we retain them; move them to model instances; or have them for both?
  • PUT on models has a different JSON requirement than PUT on tests. Former requires a key "models" and accept a list of dicts, whereas the latter only accepts a dict (no "tests" key or list).

Other API related tickets:
https://github.com/HumanBrainProject/hbp-validation-framework/labels/REST%20API

@apdavison
Copy link
Member

  • 'license' should now be a property of the model instance
  • the 'project' field was not migrated from the Postgres DB. What is its intended use?

@appukuttan-shailesh
Copy link
Collaborator Author

project field was used here

project : int
Numeric input specifying the Collab ID, e.g. 8123.
This is used to indicate the Collab where results should be saved.

@appukuttan-shailesh
Copy link
Collaborator Author

Let me know when any of the APIs have been updated, and I will make changes accordingly to the client (or atleast open tickets for the client). I realized today that the Python client hadn't accommodated quite a bit of the recent API changes.

@apdavison
Copy link
Member

collab id is available as data["app"]["collab_id"]

@appukuttan-shailesh
Copy link
Collaborator Author

appukuttan-shailesh commented Mar 20, 2020

I think this was important previously as the API only returned the App ID (models were tied to specific app instances, and not Collabs initially).

Currently, as far as I can think of, project parameter of model can be used mainly for filtering models based on several projects of a single user. This isn't all that important, and can therefore be removed.

@appukuttan-shailesh
Copy link
Collaborator Author

Update:

  • I have now removed project parameter for models from the Python client .
  • I have moved license parameter from model to model instance in the Python client

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants