Hi Aseem, When you GET a resource, you're asking for its state at a particular instant in time. GET's don't always return the same content, what's important about them is that clients can't be held responsible for any (unintended) side-effects of a GET operation. For example, if you GET the BBC new page now, and then GET it again in 20 minutes, the bytes you receive will almost certainly be different.
I think what's perhaps a bit odd in the paged traverser case is that clients do in fact trigger a state transition on GET which materially changes the response. Adding /next to the paged traverser URI does not change this, it just lengthens the URI. Under the covers, the REST API is just using the traversal API and so gets back an Iterable<T> which is forward-only. We can't (or rather won't) do things like ?page=2 (or similar) because that would involve holding all the traversal state on the server which is one of the things paged traversers were meant to avoid (being kind to both the server and clients). If you want to remember all traversal state on the client, that's OK. You can page through your own local data structures. In fact given the number of clients is likely to be larger than the number of servers, this makes sense since the memory burden is shared amongst the many clients, rather than being placed on the single server. So, I'll buy that we've conflated a little too much into a single GET, but it's motivated by a sincere trade off to not overburden the server. Jim _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
