Ok,
Is the following approach better?
Consider node.10.json
Check if the response will contain more than 200 nodes
If so, proceed with the way it is now and send the resources along
with a 200 response code.
If it is not,
Check if node.0.json results in a set bigger then 200 nodes.
If not check node.1.json, then node.2.json, ...
Basically, keep increasing the level until the number of resources is
bigger then 200.
This would give the highest recursion level you can request.
The server would then respond with a 300 and (I think?) a header
'Location' with the highest level.
The thing off course is that you would have to loop over all those
nodes again and again.
Jackrabbit will have caches for those nodes but I'm not really sure
what the impact on performance would be.
Simon
On 12 Jan 2010, at 00:53, Roy T. Fielding wrote:
On Jan 11, 2010, at 10:01 AM, Simon Gaeremynck wrote:
Yes, I guess that could work.
But then you can still do node.1000000.json which results in the
same thing.
I took the liberty to write a patch which checks the amount of
resources will be in the result.
If the result is bigger than a pre-defined OSGi property (ex: 200
resources) it will send a 206
partial content with the dump of 200 resources and will ignore the
rest.
It can be found at http://codereview.appspot.com/186072
Simon
Sorry, that would violate HTTP. Consider what impact it has on
caching by intermediaries.
Generally speaking, treating HTTP as if it were a database is a
bad design. If the server has a limit on responses, then it
should only provide identifiers that remain under that limit
and forbid any identifiers that would imply a larger limit.
An easy way to avoid this is to respond with 300 and an index of
available resources whenever the resource being requested would be
too big.
The client can then retrieve the individual (smaller) resources from
that index.
....Roy
