Originally I thought a 300 response is issued if the client did not issue the
right kinds of headers and say multiple content-types are available. I no
longer think this is the case because the specification talks about the
server returning multiple URLs so this isn't a simple matter of headers
against the original URL.
Can you please give a concrete example of when a 300 response would be
appropriate?
Gili
Paul Sandoz wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/300-MULTIPLE-CHOICES-tp2209176p2217683.html
Sent from the Jersey mailing list archive at Nabble.com.