The incidents-endpoint needs pagination

[hmpf]

See #131 for filtering

[hmpf]

DRF comes with:

• PageNumberPagination

  Request: GET https://api.example.org/accounts/?page=4

  Respomse:

  HTTP 200 OK
  {
    "count": 1023
    "next": "https://api.example.org/accounts/?page=5",
    "previous": "https://api.example.org/accounts/?page=3",
    "results": [
     …
  ]
  }

• LimitOffsetPagination

  Request: GET https://api.example.org/accounts/?limit=100&offset=400

  Response:

  HTTP 200 OK
  {
    "count": 1023
    "next": "https://api.example.org/accounts/?limit=100&offset=500",
    "previous": "https://api.example.org/accounts/?limit=100&offset=300",
    "results": [
     …
    ]
  }

• CursorPagination For some reason, this doesn't have an example in the DRF docs. This is well suited to large datasets though as it is maximally light for the database. See https://cra.mr/2011/03/08/building-cursors-for-the-disqus-api/ . We already have a non-changing monotonically increasing field, either id or timestamp on the Incident.

• Finally, there the third-party package: link-header-pagination

  As exemplified by github: https://developer.github.com/v3/guides/traversing-with-pagination/. It's basically the same as PageNumberPagination, but the links are sent in the header of the response instead of the body.

[hmpf]

See https://github.com/Uninett/Argus-frontend/issues/131 for frontend

[hmpf]

I think our best option is CursorPagination since we anticipate an abusrd amount of incidents. The questions then are:

1. What should be the default page size in backend?
2. A. Use the library that comes with drf, or B. write our own that uses headers?

Advantages of A: quick to do in the backend, we do not need to support it.

Disadvantages of A: json structure changes

Advantages of B: json structure does not change

Disadvantages of B: We need to support it, and some proxies fuck with headers

[lunkwill42]

I really don't like limit/offset as arguments through the API. I like the page-number approach better, as it leaves the implementation details to the API. I find the cursor-based option intriguing, but I'll have to read up on it.

Also, pagination in the frontend gets tedious fast IMHO - what is our stance on the "infinite scrolling" paradigm? ;-)

[hmpf]

Gah, I actually copypasted wrong. I meant CursorPagination. I'll update the comment.

As for infinte scroll, personally I detest it, but this is not something made with me in mind ;) Whether it is doable for version 1 is another matter.

[hmpf]

(After a meeting we settled on: drf's own CursorPagination, default page size 100.)