I understand that resources are uniquely identified by their @Path,
regardless of any query/matrix parameters and I don't disagree with that.
However, I disagree with JSR311 allowing only one implementation per
resource method regardless of the query/matrix parameters. For example:
POST /images: creates a new image
POST /images?order=random: returns images in random order
In both cases I am interacting with the same resource but I need totally
different implementations for each case. Because JSR311 only allows me to
use one implementation I have two choices:
1) Declare a generic catch-all method signature:
@Path("/images")
@POST
public Response postImages(@Context Request request, @QueryParam("order")
String order)
because the input and return-types of the two use-cases are totally
different. Note that the method arguments are the union of all possible
use-cases. They will be null for the cases that don't use them. This is very
ugly and makes implementations more difficult to maintain.
2) Push the query arguments into @Path as follows:
POST /images: creates a new image
POST /images/random: returns images in random order
This simplifies the implementation but (correct me if I'm wrong) this is
completely the wrong way to go from a RESTful point of view. "random" is not
a resource, "images" is! We are forced to promote it into a resource purely
because of JSR311's limitations.
I look forward to your feedback.
Thanks,
Gili
--
View this message in context: http://n2.nabble.com/JSR311-encourages-bad-design-tp2094913p2094913.html
Sent from the Jersey mailing list archive at Nabble.com.