Change Details

## Overview All endpoints that return a list of posts should support optional pagination. With page number and optional number of posts per page. ## Background Many people are using the API in custom applications, like showing some posts on another website of theirs. They currently must take the entire list of posts, which for some users may be from a few hundred to over a thousand. Ideally they could select a number of their latest posts and walk through 'pages' of the results with subsequent API calls. Aside from this some pages, like the drafts page, can be slow when the user has a lot of posts in that collection. ### Users This would affect more advanced users but also speed things up on the write.as front for regular users as well. ## Implementation On routes: - `GET /api/collections/{COLLECTION_ALIAS}/posts` - `GET /api/me/posts` Add two new query parameters, `p` or `page` for page number and `l` or `limit` for the number of posts per 'page'. Both parameters should be optional to retain backwards compatibility. If the _page_ parameter is provided **without** the _limit_ parameter, then the limit should default to something sane, like 50.

## Overview All endpoints that return a list of posts should support optional pagination. With page number and optional number of posts per page. ## Background Many people are using the API in custom applications, like showing some posts on another website of theirs. They currently must take the entire list of posts, which for some users may be from a few hundred to over a thousand. Ideally they could select a number of their latest posts and walk through 'pages' of the results with subsequent API calls. Aside from this some pages, like the drafts page, can be slow when the user has a lot of posts in that collection. ### Users This would affect more advanced users but also speed things up on the write.as front for regular users as well. ## Implementation On routes: - `GET /api/collections/{COLLECTION_ALIAS}/posts` - `GET /api/me/posts` Add two new query parameters, `p` or `page` for page number and `l` or `limit` for the number of posts per 'page'. Both parameters should be optional to retain backwards compatibility. If the //page// parameter is provided **without** the //limit// parameter, then the limit should default to something sane, like 50.

## Overview All endpoints that return a list of posts should support optional pagination. With page number and optional number of posts per page. ## Background Many people are using the API in custom applications, like showing some posts on another website of theirs. They currently must take the entire list of posts, which for some users may be from a few hundred to over a thousand. Ideally they could select a number of their latest posts and walk through 'pages' of the results with subsequent API calls. Aside from this some pages, like the drafts page, can be slow when the user has a lot of posts in that collection. ### Users This would affect more advanced users but also speed things up on the write.as front for regular users as well. ## Implementation On routes: - `GET /api/collections/{COLLECTION_ALIAS}/posts` - `GET /api/me/posts` Add two new query parameters, `p` or `page` for page number and `l` or `limit` for the number of posts per 'page'. Both parameters should be optional to retain backwards compatibility. If the _//page_// parameter is provided **without** the _//limit_// parameter, then the limit should default to something sane, like 50.