REST API does not conform with HTTP spec

[ioggstream]

Current Behavior

REST API method usage does not conform to HTTP specifications https://www.rfc-editor.org/rfc/rfc9110

Some examples:

Method	RFC / best practices	this API	Hint
PUT	replaces a resource with the request payload, e.g /project/{project-id}	create a resource	move PUT operation under POST
PATCH	use a specific media type (e.g. merge-patch+json)	use application/json	enforce merge-patch+json
POST	used to create resources, returns the Location header	used to update a resource but points to the parent	when uuid is not present, should create the resource

If you are interested, I can provide further feedback.

Steps to Reproduce

e.g. POST updates a project

requests.post(
   "http://localhost:8081/api/v1/project",
   data={"name": "foo", "description": "bar", "classifier":"APPLICATION"}
   headers={"X-API-Key": SBOM_TOKEN, "Content-Type": "application/json"},
)
b'The UUID of the project could not be found.'

Expected Behavior

POST creates a project when uuid is not provided

Dependency-Track Version

4.6.x

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

Google Chrome

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this defect was already reported

[ragaskar]

I'm also encountering a lot of surprises around inconsistencies in the API (e.g., sometimes POST is a create, sometimes PUT). I imagine it's quite a bit of work to identify and correct these mismatches, but I believe the time saved by users will be worth it. Consider this a +1 -- I will try to do my part by opening issues when I encounter unexpected behavior.

[hvardhan20]

Even I found it odd using PUT to create a resource. Maybe there was a reason they made it the other way around?

But yeah I'd like this fixed as well. +1

[nscuro]

I am positive that we'll have a better overview of this once https://github.com/DependencyTrack/dependency-track/issues/840 is resolved, likely even during the implementation inconsistencies like those mentioned here will become more apparent. They could then be corrected in a /v2 of the API.