Pagination in a REST web application
This is a more generic reformulation of this question (with the elimination of the Rails specific parts)
I am not sure how to implement pagination on a resource in a RESTful web application. Assuming that I have a resource called products , which of the following do you think is the best approach, and why:
1. Using only query strings
eg. http://application/products?page=2&sort_by=date&sort_how=asc
The problem here is that I can't use full page caching and also the URL is not very clean and easy to remember.
2. Using pages as resources and query strings for sorting
eg. http://application/products/page/2?sort_by=date&sort_how=asc
In this case, the problem that is see is that http://application/products/pages/1 is not a unique resource since using sort_by=price can yield a totally different result and I still can't use page caching.
3. Using pages as resources and an URL segment for sorting
eg. http://application/products/by-date/page/2
I personally see no problem in using this method, but someone warned me that this is not a good way to go (he didn't give a reason, so if you know why it's not recommended, please let me know)
Any suggestions, opinions, critiques are more than welcome. Thanks.
I think the problem with version 3 is more a "point of view" problem - do you see the page as the resource or the products on the page.
If you see the page as the resource it is a perfectly fine solution, since the query for page 2 will always yield page 2.
But if you see the products on the page as the resource you have the problem that the products on page 2 might change (old products deleted, or whatever), in this case the URI is not always returning the same resource(s).
Eg A customer stores a link to the product list page X, next time the link is opened the product in question might no longer be on page X.
I agree with Fionn, but I'll go one step further and say that to me the Page is not a resource, it's a property of the request. That makes me chose option 1 query string only. It just feels right. I really like how the Twitter API is structured restfully. Not too simple, not too complicated, well documented. For better or worse it's my "go to" design when I am on the fence on doing something one way versus another.
HTTP has great Range header which is suitable for pagination too. You may send
Range: pages=1
to have only first page. That may force you to rethink what is a page. Maybe client wants a different range of items. Range header also works to declare an order:
Range: products-by-date=2009_03_27-
to get all products newer than that date or
Range: products-by-date=0-2009_11_30
to get all products older than that date. '0' is probably not best solution, but RFC seems to want something for range start. There may be HTTP parsers deployed which wouldn't parse units=-range_end.
If headers is not an (acceptable) option, i reckon first solution (all in query string) is a way to deal with pages. But please, normalize query strings (sort (key=value) pairs in alphabet order). This solves "?a=1&b=x" and "?b=x&a=1" differentiation problem.
链接地址: http://www.djcxy.com/p/41134.html上一篇: 我可以使用一些具体的信息
下一篇: 在REST Web应用程序中进行分页