Hi, On Wed, Jan 13, 2010 at 12:51 AM, Simon Gaeremynck <[email protected]> wrote: > ...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...
As you mention, I think that would be too expensive performance-wise. How about setting both a maximum allowed number of levels and a maximum number of resources returned? The JSON producer would then fail (see below) if any of those limits are met. And maybe use different limits for the admin user. For failing, we might return a 403 status code (forbidden) for the "too many levels" case. For the "too many resources" case we might return a 300 (multiple choices) pointing to URLs like foo.0to50.json, foo.51to99.json which return the foo resource and the corresponding ranges of child resources, based on other selectors - assuming that solves the performance problem. BTW, JSON rendering should be done in a streaming mode, where large data sets shouldn't be a problem (except on the client side maybe, if that's a browser). If that's not the case, we might need to start by fixing that. -Bertrand
