Implemented your suggestion + made the patch work for resources in
general not just Nodes.
patch @ http://codereview.appspot.com/189121/show
Downside of setting the Location header is that most client's will
automatically retrieve their data.
For example doing a GET request with jquery in firefox
to /.infinity.json will automatically
result in a second request to /.2.json
Thanks for keeping up with me for so long. :)
Simon
On 18 Jan 2010, at 13:25, Alexander Klimetschek wrote:
On Fri, Jan 15, 2010 at 20:58, Simon Gaeremynck
<[email protected]> wrote:
If there are too many children it responds with the following:
Status: 300
Header Content-Type: application/json
Body ["/path/to/node.4.json"]
In this case, /path/to/node.4.json is the url which will result in
a safe
dump of the tree
I would prefer the alternate "working" URL to be in the Location
header.
The spec says that for a 300 Multiple Choices response the list of
choices could be given in the entity (because the Location header is
for one resource only, so multiple links must go into the body of the
response). But if the server can chose a single one that is preferred,
that resource can go into the Location header (see citation below).
And I think that is the case here, since the server knows that only
...node.4.json is the "maximum" one that works.
Also, I think the body could contain all *.json up to the maximum, eg.
in this case:
["/path/to/node.0.json", "/path/to/node.1.json",
"/path/to/node.2.json", "/path/to/node.3.json",
"/path/to/node.4.json"]
<rfc-snip>
If the server has a preferred choice of representation, it SHOULD
include the specific URI for that representation in the Location
field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.
</rfc-snip>
Regards,
Alex
--
Alexander Klimetschek
[email protected]
