Though we're still wondering whether we'll also support timestamps and offset... so that it's possible to query items from a moment in time (last time a client checked) really easily.
I agree with much of the above, but I think URLs shouldn't be a law unto themselves and should be balanced with other parts of the application, protocols, etc.
I end up thinking that as HTTP very clearly defines how to use query strings and page fragments that these things should never be coded into the page/resource part of the URL.
The URL is for the thread, which part of the thread is a query upon the thread.
I really think there is a balance between the requirements and rules of every part, and trying to perfect a URL by breaking other parts is not the right thing.
I also don't think that using a URL correctly exposes anything about the backend system.
Pagination is already using the offset model for the API: http://microcosm-cc.github.io/#basics-pagination
Though we're still wondering whether we'll also support timestamps and offset... so that it's possible to query items from a moment in time (last time a client checked) really easily.
I agree with much of the above, but I think URLs shouldn't be a law unto themselves and should be balanced with other parts of the application, protocols, etc.
I end up thinking that as HTTP very clearly defines how to use query strings and page fragments that these things should never be coded into the page/resource part of the URL.
For example LFGSS does this:
https://www.lfgss.com/thread100073-2.html
And I think that should be:
https://www.lfgss.com/thread100073.html?offset=50
Or:
https://www.lfgss.com/thread100073.html?page=2
The URL is for the thread, which part of the thread is a query upon the thread.
I really think there is a balance between the requirements and rules of every part, and trying to perfect a URL by breaking other parts is not the right thing.
I also don't think that using a URL correctly exposes anything about the backend system.