... | ... | @@ -588,6 +588,17 @@ class OriginV4RecordSerializer(IpListSerializer): |
|
|
```
|
|
|
|
|
|
|
|
|
# The pagination
|
|
|
|
|
|
[Official DRF documentation on pagination](https://www.django-rest-framework.org/api-guide/pagination/)
|
|
|
|
|
|
Using paginated results is a good practice that simply consists in returning a certain number of results maximum and provide links to get the other pages of results. This is useful for not overloading the server, not requesting extremely long response that can timeout and also not being a return a heavy response. In some context it can even be used to exploit the data page by page and thus avoid working with structures which takes a lot of RAM on the client side. The downside is a slight performance decrease when retrieving all the results, mostly because a database request is made for each page instead of a single database request for all at once. Nevertheless if timing is not a strong constraint, it is better to use the paginated responses.
|
|
|
|
|
|
For the above reasons, the default behavior of the DRF generics views in Re2o is to paginate the results with pages of 100 elements. However the pagination class used is not the DRF default one but a custom one, defined in `api.pagination.PageSizedPagination`, that extends a bit the functionnalities for performance optimization.
|
|
|
|
|
|
As the standard DRF pagination, the page is requested through the `page` argument in the query. The difference is that a custom page_size can be requested by the client. It can be any integer from 0 to 10000 (still limited for safety but should not be a problem in practice) or it can be the string `all` to specify the page should contains all the results. This option is too use carefully and only for optimizing specific request that are time-constrained.
|
|
|
|
|
|
|
|
|
# The format
|
|
|
|
|
|
[Official DRF documentation on formats](https://www.django-rest-framework.org/api-guide/format-suffixes/)
|
... | ... | |