The GitHub API has two patterns for endpoints that return lists. One is just to return an array, and the other is to return an object that looks like this:
{
"total_count": 42,
"[entities]": [
// ...
]
}Where [entities] can be something different per-endpoint, usually semantically related to the name of the endpoint. For example, the format for GET /orgs/{org}/actions/runners is:
{
"total_count": 2,
"runners": [
// ...
]
}These endpoints require pagination, even though they do not return root arrays, but the heuristic used to determine whether to generate a "get all pages" function misses them:
|
if frt.starts_with("Vec<") && http::Method::GET == m { |
It would be nice if "get all pages" helper functions could be generated for these GitHub API models.
I looked into implementing this in a PR, but it got a bit more complicated than I was ready to devote time to, so I am just filing an issue for now. This is the root cause of #81.
The GitHub API has two patterns for endpoints that return lists. One is just to return an array, and the other is to return an object that looks like this:
{ "total_count": 42, "[entities]": [ // ... ] }Where
[entities]can be something different per-endpoint, usually semantically related to the name of the endpoint. For example, the format for GET /orgs/{org}/actions/runners is:{ "total_count": 2, "runners": [ // ... ] }These endpoints require pagination, even though they do not return root arrays, but the heuristic used to determine whether to generate a "get all pages" function misses them:
third-party-api-clients/generator/src/functions.rs
Line 390 in 31f85e8
It would be nice if "get all pages" helper functions could be generated for these GitHub API models.
I looked into implementing this in a PR, but it got a bit more complicated than I was ready to devote time to, so I am just filing an issue for now. This is the root cause of #81.