# Best Practices for Implementing JSON

**URL:** <https://discuss.jsonapi.org/t/best-practices-for-implementing-json/2991>\
**Category:** Uncategorized\
**Created:** [January 31, 2025, 4:39pm UTC](https://discuss.jsonapi.org/t/best-practices-for-implementing-json/2991 "2025-01-31T16:39:35Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Unsteady9968](https://avatars.discourse-cdn.com/v4/letter/u/3e96dc/32.png) [@Unsteady9968](https://discuss.jsonapi.org/u/Unsteady9968)\
**Post date:** [February 5, 2025, 5:38pm UTC](https://discuss.jsonapi.org/t/best-practices-for-implementing-json/2991/2 "2025-02-05T17:38:44Z")

</div>

I’m one of those people who has only used the page[number] page[size] implementation and that is or was a thing our frontend developers hated. What I mean by hated is the links object with first, last, and so on values, so instead we added headers also to include a count of all records, current page, next page and so on.

On thing to take note of is that the json specifications are open to most kinds of pagination

 ![Screenshot_20250205_182442_Firefox](https://us1.discourse-cdn.com/flex016/uploads/jsonapi/original/1X/b7a884b7d68fbce0658ef3c208dad9d22903bac8.png)  
and if the implementation the team did (that i worked in) would have been done only with the json api specifications then we would probably had included a meta object in the links object like the discussion in [Pagination controls](https://discuss.jsonapi.org/t/pagination-controls/422).

---

_[View the full topic](https://discuss.jsonapi.org/t/best-practices-for-implementing-json/2991)._