CODEWITHSUNDEEP
javahttpjax-rshttp-method
JiboOne
JiboOne

Reputation: 1548

what is the correct way to pass additional parameter to HTTP @DELETE method

I have to build JAX-RS web service, which will delete client from client resource, plus it should have external uuid in request.

the implementation of @DELETE method without externalId is very simple

/myService/client/1


@DELETE
    @Path("/client/{client}")
    public Response removeClient(@PathParam("client") long client) {

        // implementation code 

        return Response.status(200).build();
    }

but where should I add externalId as @QueryParam?

in case @QueryParam the URI will be this, is it correct design? 

/myService/client/1?externalId=d852e3fc-b7ac-42d7-b22b-74cb4da709ec

  @DELETE
        @Path("/client/{client}")
        public Response removeClient(@PathParam("client") long client, @QueryParam("externalId") String externalId ) {

            // implementation code 

            return Response.status(200).build();
        }

or maybe I should send externalId in to request body or as @PatchParam?

which will be correct design?

should I use another HTTP Method instead of HTTP DELETE for this case?

Upvotes: 1

Views: 711

Answers (2)

davidxxx
davidxxx

Reputation: 131436

Sending two information to identify a resource to delete is not conventional.
It doesn't mean that it is forbidden but you should be aware of it.

Adding this information in the body ?
Servers may ignore body for delete requests.

Suffixed this information in the path ?
It breaks the semantic of the path that should be a way to identify naturally a resource in the hierarchy/resource structure.

I think that you actual way with @QueryParam is an acceptable workaround if you have the constraint to convey these two information and that really you cannot change it.
As alternative you can also use URL matrix parameters to convey a composite id
such as DELETE /myService/client/1,123456 where 1 is the client id and 123456 the uuid

Upvotes: 1

ZhenyaM
ZhenyaM

Reputation: 686

from specification:

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

Thus, no any restrictions or recomendations about parameter passing. You could use any variant as you like and convenient for you

Upvotes: 1

Related Questions