> Of course... If you care to read the HTTP Method definitions
(
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) and taking in
consideration that although Rest style is protocol independent (meaning I
can have a Rest-ish app with my own methods, or as WebDAV a extended set of
HTTP methods), jax-rs is not (meaning it only supports the HTTP methods)...
>
> 9.3 GET
> The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI.
>
> 9.5 POST
> The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line.
>
> then you should use
>
> POST /images: creates a new image
> GET /images?order=random: returns images in random order
>
> BTW if you wanted to create a image under a specific URI, then you should
use a PUT
>
> PUT /images/img0001
>
>
> And if you object to using GET for getting a random image because you're
not referring to the specific image resource (because it's random) you
should note that the specification also says
>
> If the Request-URI refers to a **data-producing process**, it is the
produced data which shall be returned as the entity in the response
>
> so all this is both REST-ish and HTTP-ish...
>
> GET /images: produces a list of images under this resource, ie
{/images/img0001, /images/img0002, /images/holidaysinfrance2008-0001}, in a
hiper-media format
> GET /images/img0001: get the image under this resource, ie the img0001
> GET /images/* get all images
> GET /images?order=random: returns a image returned by a data-producing
process that retrieves a random image
>
> and actually also
>
> GET /images/random
>
> because the URI can point to a **data-producing process** and not
a "entity"
>
> So maybe YOU should not encourage the use of bad design... (hey, you
started the flame... :)
>
> Now there will be situations when you can have multiple combinations of
the same verb and the same uri. But those situations you probably solve by
thinking a little more carefully about what is a resource and not what you
want to do, thinking more "resource-oriented" and not "procedure-oriented".
At least in my case that what's happened.
>
> And if you find out that you can't live without the multiples verb/uri in
your application, probably you shouldn't be using REST at all. REST doesn't
encourage bad design because it's to be applicable in "resource-oriented"
situations and not in RPC-like situations. Now, try to apply REST strictly
to RPC, *that* is a bad design...
>
>
>
> On Dec 31, 2008 8:50am, Markus KARG markus.karg_at_gmx.net> wrote:
> > Why using POST for GETting images? I'd rather would do a simple GET for
> >
> > this.
> >
> >
> >
> > Regards
> >
> > Markus
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: Gili [mailto:cowwoc_at_bbs.darktech.org]
> >
> > > Sent: Mittwoch, 31. Dezember 2008 04:50
> >
> > > To: users_at_jersey.dev.java.net
> >
> > > Subject: [Jersey] JSR311 encourages bad design
> >
> > >
> >
> > >
> >
> > > 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
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> >
> >