Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for metadata-wrapped paginated endpoints #261

Open
lrstanley opened this issue Jun 29, 2024 · 0 comments
Open

feat: add support for metadata-wrapped paginated endpoints #261

lrstanley opened this issue Jun 29, 2024 · 0 comments

Comments

@lrstanley
Copy link

Currently, if a paginated endpoint does not return an array schema, rather something like the following:

{
  "content": [...],
  "page": 1,
  "last_page": 11,
  "is_last_page": false,
  "total_count": 101
}

Restish doesn't seem to handle this, and it doesn't look like there is a viable openapi extension or configuration option which allows re-configuring it to look at sub-fields. Example output:

$ restish http://localhost:8080/users
WARN: Skipping auto-pagination: response body not a list, not sure how to merge
HTTP/1.1 200 OK
Content-Type: application/json
Date: Sat, 29 Jun 2024 01:53:52 GMT
Link: </openapi.json>; rel="describedby", </users?page=2>; rel="next", </openapi.json>; rel="service-desc"

{
  content: [
[...]

A few ideas:

  1. Optional openapi extension field on list endpoints which allows specifying something like content as the paginated key.
  2. If no annotation is provided, use the OpenAPI spec, and find the first child (in AllOf or AnyOf if within spec), which returns an array. If more than one, maybe still fail? If only one, assume it is the field that is desired?
@lrstanley lrstanley changed the title feat: add support metadata-wrapped paginated endpoints feat: add support for metadata-wrapped paginated endpoints Jun 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant