Actually in this case I think you are wrong but there might be cases
that I would agree with. In this case, you should be using PUT to
create a new image and that can be a separate method.
Instead I would say:
> PUT /images: creates a new image
> POST /images?order=random: returns images in random order
In general, REST doesn't support what your use case very well as the
random assortment of images isn't a resource at all. You should
likely be handling this as
POST /images/random
Which then redirects you to a new URL with the resource that is that
collection of images (perhaps with the random seed) like this:
POST /images/random -> redirect -> GET /images/random/18923749937
Or something similar. I like your use of inflammatory subject lines
though, got my attention.
Sam
On Dec 30, 2008, at 7:50 PM, Gili wrote:
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>