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

Refactor generic /attributes router into attribute-specific routers #354

Closed
alyssadai opened this issue Oct 15, 2024 · 1 comment · Fixed by #358
Closed

Refactor generic /attributes router into attribute-specific routers #354

alyssadai opened this issue Oct 15, 2024 · 1 comment · Fixed by #358
Assignees
Labels
maint:refactor Simplifying or restructuring existing code or documentation. released This issue/pull request has been released. type:maintenance Upkeeping efforts & catch-up corrective improvements that are not Features nor Bugs

Comments

@alyssadai
Copy link
Contributor

alyssadai commented Oct 15, 2024

Given that our API is gradually expanding to accommodate requests for more specific metadata about specific attributes (e.g., versions of a specific pipeline), it makes sense to restructure the logic of existing /attributes routes to be more REST-compliant and intuitive for API consumers.

At the moment, we have two "top-level" subpaths in the /attributes router, which are:

  • /attributes/{data_element_uri}/
  • /attributes/{data_element_uri}/vocab

While the current level of abstraction makes it easy to accommodate new attributes in the graph, this structure is less intuitive in terms of what each endpoint returns, and gets tricky to expand in terms of the types of info returned. e.g., specific versions of the nb:Pipeline attribute:

  • /attributes/{data_element_uri}/versions or even /attributes/nb:Pipeline/versions is not very elegant

Instead, it would be more helpful and maintainable to adopt a more conventional REST structure where top-level routers represent distinct entities (with potentially distinct operations and behaviours), and subpaths point to increasingly specific resources of those entities. This avoids path ambiguity for the end user cause by nesting everything under a single /attributes router, and makes the API more explicit and intuitive.

This can be seen in practice in the Stardog and GraphDB API docs.

Suggested path structure

  • /attributes/ -> to return all Neurobagel attributes in the data model (i.e., keeping the current behaviour)
  • and then one top-level router for each attribute we support introspection of (most likely, all the ones with controlled terms as objects):
    • /pipelines
    • /assessments
    • /diagnoses
    • /sex (?)
  • per attribute router, there should be:
    • a root path / that returns available instances in the graph
    • a vocab path /vocab that returns the possible labels and term URLs from the corresponding vocab

NOTE The f-API would also need to be updated to reflect this change

@alyssadai alyssadai added maint:refactor Simplifying or restructuring existing code or documentation. type:maintenance Upkeeping efforts & catch-up corrective improvements that are not Features nor Bugs flag:schedule Flag issue that should go on the roadmap or backlog. labels Oct 15, 2024
@rmanaem rmanaem removed the flag:schedule Flag issue that should go on the roadmap or backlog. label Oct 15, 2024
@alyssadai alyssadai self-assigned this Oct 16, 2024
Copy link

🚀 Issue was released in v0.4.0 🚀

@neurobagel-bot neurobagel-bot bot added the released This issue/pull request has been released. label Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maint:refactor Simplifying or restructuring existing code or documentation. released This issue/pull request has been released. type:maintenance Upkeeping efforts & catch-up corrective improvements that are not Features nor Bugs
Projects
Status: Review - Done
Development

Successfully merging a pull request may close this issue.

2 participants