DependencyTrack / DependencyTrack/dependency-track

General API / API specification improvements

Open
#2,604 1 comment 2 reactions 0 assignees View on GitHub
api docs enhancement
Dominant language
Java
Stars
4.2k
Forks
811
Avg merge
8h 39m
Merged PRs (30d)
237

Description

### Current Behaviour

Note: these are my impressions based on reading the spec, and reading other issues. If they are incorrect, I'm very happy to edit:

- the API spec seems to not be generated from the API implementation (or vice versa) - e.g. https://github.com/DependencyTrack/dependency-track/issues/209 mentions some parameters that do not appear to be in the OpenAPI specification
- the API returns a 500 when unexpected input is sent to it. E.g. POSTing some JSON with no `Content-Type: application/json` header returns a 500
- the OpenAPI specification has some `default` tags for notification-related endpoints
- it is difficult to understand the cause of 403 responses
- it is hard to understand some of the API - e.g. POSTing to `/api/v1/sbom` returns a `uuid`, documented as "Token used to check task progress". This can be used with `/api/v1//v1/bom/token/{uuid}`, but given that returns a boolean it means there is no obvious way to get the UUID of the BOM. Additionally, POSTing to that endpoint with `autoCreate=true` does not return an additional UUID that might indicate what the UUID of the new project is.
- the API entities don't differentiate between POST, PUT and PATCH entities - e.g. some fields are not appropriate for POST, but it's impossible to deduce that

### Proposed Behaviour

- the OpenAPI spec should be generated from the implementation, or vice versa, to make it always fully up to date
- the API should return a non-500 error in every possible instance, and in the instance of incorrect input should instead return a 400 and a list of the problem(s) with the attempt.
- The OpenAPI spec should have a `notification` tag for all notification-related endpoints
- the OpenAPI specification should document the appropriate permission(s) required to access each endpoint, to avoid the difficult processing debugging 403s
- All create and autoCreate options should return standardised responses. Here's an example of what the rules could be, acknowledging this would be a major change:
- all creates should return a `Location` header with a URL to the new resource
- all creates with subsidiary resource creations should return additional UUIDs in the body of the response. E.g. creating a BOM with autoCreate=true should return a Location header to the BOM, and a `{"projectUuid": "..."}` body
- the API definition should split out the different types of entity, e.g. `ProjectRequest`, `ProjectResponse`, `ProjectPatch`. This may come automatically from doing the first bullet point in this list

### Checklist

- [X] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [X] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.