<p>I have built a RESTful API, but haven't yet thought about the pagination part, now, I am implementing the pagination and would like some ideas, for example, if the user does this:</p>
<p>/filter?offset=10&limit=10</p>
<p>and later, adds a new filter, do I cache the results of the earlier filter somewhere or do a fresh DB query?</p>
<p>How about usage of websockets instead of pagination?</p>
<hr/>**评论：**<br/><br/>Kraigius: <pre><p>In my service I use the query string "?offset=x&limit=y" too. I've also seen people use "?page=x" without letting the users much control on the page.</p>
<p>My Go service is read only and the data rarely change. It's running behind a Nginx proxy and with a CDN so everything is pretty much cached up with a long expiration timer. I didn't have to do anything special with the Etag + Last-Modified headers. I'd personally prefer avoiding hitting the DB, cache is fast.</p></pre>black_anarchy: <pre><p>It's also a good idea to use local storage, if available and when possible, to save some round trips. </p></pre>synt4x: <pre><p>Offset pagination (with a SQL backend) is one of the worst culprits of API performance, especially once you have collections in the 100k's. Don't paint yourself into a corner; most people do not need arbitrary offsets. <a href="http://use-the-index-luke.com/no-offset" rel="nofollow">http://use-the-index-luke.com/no-offset</a></p></pre>FIuffyRabbit: <pre><p><a href="https://www.google.com/search?q=Pagination+in+a+REST+API&oq=Pagination+in+a+REST+API&aqs=chrome..69i57j69i60&sourceid=chrome&ie=UTF-8" rel="nofollow">https://www.google.com/search?q=Pagination+in+a+REST+API&oq=Pagination+in+a+REST+API&aqs=chrome..69i57j69i60&sourceid=chrome&ie=UTF-8</a></p></pre>thewhitetulip: <pre><p><a href="https://developers.facebook.com/blog/post/478/" rel="nofollow">https://developers.facebook.com/blog/post/478/</a></p>
<p><a href="https://dev.twitter.com/rest/public/timelines" rel="nofollow">https://dev.twitter.com/rest/public/timelines</a></p></pre>
