2

I have a service method which looks like this

public void deleteData(Data data) {
    this.dataDao.deleteData(data);
}

Data class have several fields in it. Somethig like this

private String name;
private String category;
private String discriminator;
private String description;
private String appName;

// getters & setters

I need to write a rest method for this. I was thinking to write something like this

@DELETE
@Path("/deleteData")
public Response deleteData(Data data) {
    // implementation
}

The problem is that using @DELETE with entity body is not recommended or widely used.

My question is if it's ok to use @PUT instead of @DELETE? I can't change the service method implementation so that's not an option. What's the next best alternative here?

UPDATE

In dataDao.deleteData() method, finding an object is not done by object's ID. It looks something like this:

DataEntity entity = this.findDataByNameAndAppName(data.getName(), data.getAppName());

I decided to do something like this:

@DELETE
@Path("/deleteDataset")
public Response deleteDataset(@QueryParam("name") String name,
                              @QueryParam("appName") String appName) {
// implementation...
}

I didn't find any example of @DELETE method with @QueryParam, though. All examples was using @PathParam instead.

gozluklu_marti
  • 79
  • 1
  • 7
  • 26
  • *As you can see in the service implementation, I need it!* - OK you need it, but did you try another options? Like just receiving the id of the resource and pass it to the service wrapping into your `data` object? You do not need to keep your controllers with the same signature of your service, since you can receive any kind of info, wrap, handle, format, validate and then use it in the way you need it. – nortontgueno Mar 26 '19 at 15:47
  • I would say that using `@DELETE` is the best options since it complies with the HTTP specification. You may just think better about your how can you integrate this layer with your legacy service. A good approach would be changing your URI to `/delete/{dataId}` and then handle it properly on your controller layer (instantiating a new `Data` object setting the id for example) – nortontgueno Mar 26 '19 at 15:50
  • 1
    I usually use post method for these purposes. – Roman C Mar 26 '19 at 16:42
  • I have seen many standard REST clients allowing users to have request body for DELETE operation. So i think it is perfectly ok to use request body for DELETE operation check this post: https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request – Amit Mar 26 '19 at 16:42
  • @Amit Jersey mentioned in tags does not allow body for DELETE requests. – devmind Mar 27 '19 at 13:07

1 Answers1

2

Well, DELETE is meant for... deleting stuff. So stick to that (without body).

You could either delete a resource using its unique identifier sent as a path parameter:

DELETE /resources/{id} HTTP/1.1
Host: example.org

If you need to delete multiple resources, you could consider query parameters to filter a collection of resources and then delete the resources that match such criteria:

DELETE /resources?name=foo&category=bar HTTP/1.1
Host: example.org
Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • I wonder if using `@QueryParam` is an off pattern as much as providing an entity body? – gozluklu_marti Mar 27 '19 at 13:28
  • @Yonetmen [URI](https://tools.ietf.org/html/rfc3986) is a resource identifier and nothing stops you from performing a `DELETE` request to a URI with a query string. – cassiomolin Mar 27 '19 at 13:46