0

The analysis team worked on some specification which sounds a bit strange to me.

I have to delete a resource on a database table. I have the id of the rekord as input parameter.

This is straight forward http delete operation.

DELETE http://my-url/{id}

They want to add as input parameters some other values, present in the rekord, because, they say "the delete operation is very delicate in this case and we want to be sure to exclude errors in frontend, the id passed is should be the id of the values of the rekord passed".

There were a lot of internal discussion about this requirement. Dishes flew between partecipants. Anyway we have to satisfy it.

I know this is not more RESTful operation.

I modified like this:

DELETE http://my-url/{id}
REQEUST BODY
{
    "myProperty1" = 123,
    "myProperty2" = "VALUE",
    ...
}

Swagger generation gets angry about DELETE with REQUEST BODY.

I have to switch to

  • POST operation with REQUEST BODY
  • DELETE operation with some REQUEST PARAMS

The development team likes to stay as long as possible in a RESTful environment. What would be better not to be out of tune?

ANY OTHER ADVICE OR SOLUTION WE DID NOT THINK WOULD BE APPRECIATED.

Falco
  • 1,458
  • 3
  • 19
  • 47

1 Answers1

1

Swagger generation gets angry about DELETE with REQUEST BODY.

Yup, that's right.

A payload within a DELETE request message has no defined semantics -- RFC 7231

DELETE is about decoupling a URI from its representations. It's somewhat analogous to removing a key from a map/dictionary, or a symbolic link in a file system. It tells a web server to stop serving a particular web page.

It's normally easy to figure out what the identifier should be for a DELETE request; it will be the same identifier you use to look up a representation with a GET request.

DELETE is an action with semantics in the transfer of documents over a network domain.

Note this observation included in the standard:

Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect.

If what you are trying to do is pass a message to your server, with a payload, so that the server can do something clever, you should probably be using POST, rather than DELETE.

Remember: it is okay to use POST. The world wide web was catastrophically successful using little more than GET and POST.

They want to add as input parameters some other values, present in the rekord, because, they say "the delete operation is very delicate in this case and we want to be sure to exclude errors in frontend, the id passed is should be the id of the values of the rekord passed".

It's possible that what is being sought here is a conditional delete. We have standardized headers that can be used by validators to determine if the DELETE request and the current state of the resource "match".

Community
  • 1
  • 1
VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91