A better approach would be to make the URL represent the resource you want
to DELETE, rather than passing a query parameter to identify it. Possibly
having two separate subresource locators:
@Path("{id: id-\d+}")
public SubResource getById(@PathParam("id") final long id) { ... }
@Path("{length: length-\d+}")
public SubResource getByLength(@PathParam("length") final long length) {...}
class SubResource {
...
@DELETE
public Response delete() {...}
}
I'd avoid having multiple URIs for the same resource though... could send a
SEE OTHER response when accessing the .../length-NNN URI to maintain
canonical URIs.
2011/4/11 NBW <emailnbw_at_gmail.com>
> Say I have two methods in a root resource like so:
>
> @DELETE
> @Produces(MediaType.APPLICATION_JSON)
> public Response deleteById(@QueryParam("id") final long id) {
> ....
> }
>
> @DELETE
> @Produces(MediaType.APPLICATION_JSON)
> public Response deleteByLength(@QueryParam("length") final long length {
> ....
> }
>
> I would have thought that Jersey would see these as different resources but
> it doesn't. It seems to see them as conflicting due to the fact they produce
> the same media type. At least that is the error message that is logged. I
> am guessing this goes beyond simply the same media type being produced but
> also the fact that the type of the parameter is the same in both? I would
> have expected Jersey to distinguish between them using the QueryParam name
> as well, not just its type and see these as different resources.
>
> Would then it mean that in this case I would need to use one method and
> test to see how the parameters are set? eg. pseudo code:
>
> @Produces(MediaType.APPLICATION_JSON)
> public Response deleteByIdOrLength(@QueryParam("id") @DefaultValue("-1")
> final long id,
>
> @QueryParam("length") @DefaultValue("-1") final long length {
> if ((id == length == -1) || (id != -1 && length != -1))
> set appropriate error response
> else (if id != -1)
> deleteById
> set appropriate success response
> else
> deleteByLength
> set appropriate success reponse
> return response
> }
>
> That seems rather ugly. Is there a better approach? Thnx,
>
> -Noah
>
>