[arethuza]

The only small issue I can see with that is identifying where the path to the resource ends and where the query to applied to the JSON representation of the resource starts.

Perhaps something like:

    www.example.com/data.json?query=/user

[alexchamberlain]

A webserver could easily figure that out, as long as it is configured correctly and with knowledge of the domain. I don't like using query strings like this, as it makes the URL point to multiple objects.

[arethuza]

I'm not sure it could, if I have a resource with a URL:

    www.example.com/foo

and it can arbitary sub-resources e.g.

    www.example.com/foo/bar/raz

then how do I know whether bar is a different resource or part of the JSON returned describing www.example.com/foo

This would mean you'd have to restrict your resource names to ensure they don't clash with JSON names - which seems a pain (e.g. say the resource names are uploaded files and directories, so you won't have much control over what they are called)

[ZenPsycho]

Replying to the reply to this- I am pretty sure the webserver can easily find out that foo is a JSON file when resolving the path. Most operating systems don't let you name a file and a directory the same thing, so the file system API knows straight away there is no such directory named "foo", and can have special handling for whatever kind of file "foo" happens to be. (in this case, JSON)