Request for guidance on OpenAPI disallowing DELETE with request body

1

I’ve been using JSON:API for a few years and am generally familiar with it. Likewise, I have been using OpenAPI/Swagger for a few years and am also familiar with it.

Up to this point I had not needed to implement the write-endpoints for updating relationships, so I only recently stumbled across what I believe is an incompatibility point between the two: OpenAPI, or at least most of the tooling for it, considers a request body on a DELETE request to be an error.

Specific to the JSON:API specs, this means designing a DELETE method on a relationship endpoint, e.g. DELETE /articles/1/relationships/comments from the specs, results in an error from most validation tools. For example, openapi-enforcer has:

Errors: [ EnforcerException: One or more errors exist in the OpenApi definition
    at: paths
      at: /teams/{teamId}/relationships/admins > delete
        Property not allowed: requestBody ]

This topic is not to propose a change to JSON:API, instead, I am looking for guidance on how others have handled this difference between systems.

2

I’ll start :sweat_smile:

My current workaround does not strictly follow the JSON:API specs, but feels like it conforms to the heart of the specs that I’m okay with the nonconformity. (Especially because I have other validation/etc tooling, since using OpenAPI.)

Basically I add a path like DELETE /relationships/{name}/{id} so that (from the spec examples):

DELETE /articles/1/relationships/comments HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": [
    { "type": "comments", "id": "12" },
    { "type": "comments", "id": "13" }
  ]
}

would become two requests:

DELETE /articles/1/relationships/comments/12 HTTP/1.1
DELETE /articles/1/relationships/comments/13 HTTP/1.1

Of course this has some pros and cons:

  • Pro: it is supported by OpenAPI specs, so I can use that tooling.
  • Pro: no more complaints from other tooling for request bodies on DELETEs.
  • Pro: requests are idempotent (compared to using PATCH instead of DELETE).
  • Con: no longer valid JSON:API, may throw errors in other tooling or require additional customization?
  • Con: cannot delete multiple relationships at once.
  • Con: if you have multiple types on a single relationship name, there’s potential ambiguity.

For my current system architecture this design works well, but I would love to hear if anyone else has come up with other ideas!

3

The only OpenAPI tool I’ve used has been Redoc for documentation, and I haven’t had any problems with this. That’s nothing like some of the other tools, apparently; I can describe a compliant JSON:API DELETE method for relationships without any complaints from the tool.

It’s worth noting that I’m not using any tools or frameworks for the implementation of my service or the clients.

-Fred

2 Likes
4

If I understand the following correctly, the newest versions of OpenAPI spec do allow for it. Maybe tooling just needs to catch up with this…

2 Likes
5

Oh yeah, I see that now in the 3.1.0 specs, thanks!

I guess the thing to do now is to contribute to the tooling ecosystem to help get it 3.1.0 compatible. :tada: