Feature request: support pagination for endpoint "/analytics/raw/incidents"

[NikMohorko]

Hi!

I'm trying to get multiple pages of data from endpoint /analytics/raw/incidents. I get the following response:

import pdpyras

session = pdpyras.APISession(api_key)
incident_list = session.iter_all('/analytics/raw/incidents')

for i in incident_list:
    print(i)

URLError: Pagination is not supported for GET /analytics/raw/incidents.

[Deconstrained]

This seems like more of a request to modify the API itself; I could not find any documented endpoint GET /analytics/raw/incidents. The only GET request analytics endpoints are:

• Get raw data - single incident (GET /analytics/raw/incidents/{id})
• Get raw responses from a single incident (GET /analytics/raw/incidents/{id}/responses)

It would be good to know what the desired use case is here; I could pass that along to our product team.

To iterate over incidents, GET /incidents supports pagination.

[NikMohorko]

The desired use case is to iterate over enriched incident data, which is provided by the endpoint POST /analytics/raw/incidents.

[Deconstrained]

@NikMohorko Thank you; I understand now, seeing the options of that endpoint and what it does.

It's not currently supported because that particular API doesn't provide either of the standard methods of pagination; there is no offset or cursor parameter. It uses a completely different set of parameters to control the display of results that are unique to that API endpoint, in addition to using POST to obtain data (in REST APIs it's customary to use POST for creating data and GET is for retrieving it).

For what it's worth, the endpoint is quite permissive with the limit parameter. In every other resource collection endpoint, its maximum is 100, and in POST /analytics/raw/incidents it's ten times greater. In the mean time, hopefully that helps.

I'm on the fence about adding non-generic design to this API client, beyond the extent to which it already has the machinery for dealing with REST API v2's anti-patterns and special exceptions that was needed to improve its usability. The design philosophy has been "don't make an API for the API"; the focus has been on the patterns that apply the most broadly. That approach has saved the most effort both for end users and in terms of the maintenance of this API client. Providing abstractions for each different resource type within an API, I've noticed in a few other API clients, leads to a more sprawling codebase that requires more effort to maintain, i.e. the necessity to add a new abstraction to support every new resource type.

If we see more new ways of doing things in the REST API that deviate from the standard documented ways of doing things (absent the additional documentation of them as standards that can apply to other new APIs) I might soften my position and implement them, but for now I'm hesitant.