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

Reply via email to