Hi Gili,
My understanding is a 300 response is returned when the client may not
send enough information to indicate what it wants from the server.
From section 10.3 [1]
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The
action required MAY be carried out by the user agent without
interaction with the user if and only if the method used in the
second request is GET or HEAD. A client SHOULD detect infinite
redirection loops, since such loops generate network t
traffic for each redirection.
In that respect i think it does fit in with the current model. For
example, the developer is using the client API and has written code to
expects a 200 response, so a 300 would be the exception in this
respect. We want to avoid the client having to switch on a status code
for the common cases.
But it is a bit of a grey area. A 202 Accepted could return a
different representation to that of a 200 OK.
However from your use-case it seems to me that "similar tags" are
actually different but *related* resources rather than the requested
resource "corresponding to any one of a set of representations" for
the purposes of agent driven content negotiation. Thus, IIUC your use-
case, i think you may be using a 300 for something different than it
is intended.
In that respect a 200 response with hypermedia defining the
relationship seems fine. Namely, given a tag you want to get tag-based
resources that are related by "similarity", for example:
http://.../<tag>/similarTo
or
http://.../tagSimilarTo?tag=<tag>
or
http://.../tags/<tag>
where the representation returns also contains some related tags as
well as additional information on the tag.
and "it is business as usual" from the perspective of the client
GETing a representation and following links in that representation
that are related in some manner.
Paul.
[1]
http://greenbytes.de/tech/webdav/rfc2616.html#status.3xx
On Jan 24, 2009, at 5:31 PM, Gili wrote:
>
> Upon further reflection, perhaps 200 OK is meant to be used for
> resources
> that are expected to return multiple representations, whereas 300
> MULTIPLE
> CHOICES is meant to be used for resources that aren't expected to do
> so.
>
> For example:
> http://example.com/myDirectory/ should return 200 OK with a list of
> nested
> files
>
> http://example.com/tags/NewYorc should return 300 MULTIPLE CHOICES and
> suggest "similar" tags the client may wish to investigate.
>
> This would fall in line with Jersey's treatment of 300 as an
> exception. What
> do you think?
>
> Gili
>
>
> Gili wrote:
>>
>> Hi,
>>
>> I wanted to discuss the fact that Jersey throws
>> UniformInterfaceException
>> if the return-code is equal to or greater than 300.
>>
>> I started a discussion at
>> http://stackoverflow.com/questions/401191/how-to-return-random-items-restfully
>> and someone suggested that return-code 300 is appropriate for a
>> resource
>> whose state consists of links to sub-resources. In such a case,
>> HTTP 300
>> would not constitute an error at all. What are your thoughts on the
>> matter?
>>
>> Thanks,
>> Gili
>>
>
> --
> View this message in context: http://n2.nabble.com/300-MULTIPLE-CHOICES-tp2209176p2209401.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
>