DependencyTrack
v1/vulnerability/{uuid} does not return aliases anymore
Current Behavior
Aliases are not returned in the specified endpoint. There are vastly more details returned from vulnerability/source/{source}/vuln/{id}, which means doubling the API calls in some cases. This seems to be a regression that appeared some time within 4.12.x.
Steps to Reproduce
Query the endpoint.
Expected Behavior
At least aliases should be returned. Even better would be content equivalence between both endpoints.
Dependency-Track Version
4.12.7
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
16.6
Browser
N/A
Checklist
- [x] I have read and understand the contributing guidelines
- [x] I have checked the existing issues for whether this defect was already reported
Maybe the endpoint could have a new parameter or set of parameters about what details to include. For example, I'm not interested in the affected components and/or projects or whatever else details could be returned. Both endpoints I mentioned should return the same data, since they're just different queries. However, this would mean introducing a breaking change.
The code of the /api/v1/vulnerability/{uuid} endpoint hasn't changed in years, technically it should never have returned aliases.
Maybe the endpoint could have a new parameter or set of parameters about what details to include.
While I think this makes sense, I would rather not re-invent GraphQL. Are you aware of widely adopted patterns for such queries for REST APIs we can build upon?
Sorry, I'm actually not sure what's happened here - I have checked in the past what each endpoint returned, and I am somewhat sure both returned the aliases in the past. Yes, I looked at the implementations and history of both endpoints before writing this issue, and I am aware the implementation didn't change in years, so I was a bit confused here - maybe it's a bug I introduced on my side, but again, I'm somewhat sure aliases were there in the past, but since I'm not sure how exactly some changes to DB entities would affect the responses, I thought this could be a side effect of the L2 cache. If that's not the case, this issue can be closed.
Regarding query patterns, no, I'm not aware of such patterns. But I know the Jira API uses so-called expansions to control which parts of the responses are returned/expanded, and I'm pretty sure they're also using that feature to reduce DB queries, this is what I had in mind here. However, this pattern leads to multiple required requests, since you can only expand one level - i.e.,, if you open a Jira issue, I have seen dozens of requests just to show the issue data.
Expansion seems to be the correct keyword here, thanks for that!
I was able to find these related REST API guidelines from Zalando:
Perhaps something we could take inspiration from. Many of our endpoint responses are very bulky at the moment, while others may be missing some information. Having a standardized way for filtering and expansion would really be beneficial across the board.