Remove default limit on /access/ requests
#195
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In order to prevent default enforcement of pagination on the `/access/` endpoint,
this will remove the default limit (currently 10) from `/access/` requests, while
keeping it on all other endpoints.
When we get the paginator for the request, we'll now check to see if the `?limit`
query parameter is sent in the request. If so, we'll continue to respect pagination
on the request, and return a paginated response. If `?limit` does not exist in
the request, we will not set a paginator, which in tern will supply the raw
queryset to the serializer.
In order to keep a consistent API payload with and without pagination, we need to
explicitly return the serialized data nested under a `data` object.
**With Pagination:**
_/api/rbac/v1/access/?application=ansible-automation&limit=20_
```
{
"meta": {
"count": 1,
"limit": 20,
"offset": 0
},
"links": {
"first": "/api/rbac/v1/access/?application=ansible-automation&limit=20&offset=0",
"next": null,
"previous": null,
"last": "/api/rbac/v1/access/?application=ansible-automation&limit=20&offset=0"
},
"data": [
{
"permission": "ansible-automation:*:*",
"resourceDefinitions": []
}
]
}
```
**Without Pagination:**
_/api/rbac/v1/access/?application=ansible-automation_
```
{
"data": [
{
"permission": "ansible-automation:*:*",
"resourceDefinitions": []
}
]
}
```
We now have two different possible 200 responses for `/access/`, one with pagination, and one without. OpenAPI 3 supports the use of `anyOf` and `oneOf` for response body schemas [1]. This updates the spec to reflect those possible responses (with and without pagination), and includes examples of each. [1] https://swagger.io/docs/specification/describing-responses/
coderbydesign
added a commit
to coderbydesign/insights-rbac
that referenced
this pull request
Feb 20, 2020
…upplied In a recent (PR)[RedHatInsights#195] we removed the default limit on the `/access/` endpoint, to ensure all records were returned in a single request instead of using the default of 10. This meant in order to be backwards compatible, we'd also need to continue supporting pagination params. To do this, we updated the spec to include `oneOf` two possible valid responses, one paginated and one unpaginated. The `data` would remain the same, but the meta data for pagination would not be included unless a `limit` param was supplied in the request. The associated updates were made to the `openapi.json` spec, but due to an existing bug/issue in the OpenAPI Generator project [1,2], this breaks some client generation which is used by app teams and QE, even though it's valid per the spec. In order to avoid having a separate endpoint explicitly for a paginated responses, and to also avoid constructing false meta data for pagination, we've decided to set the default limit on the `/access/` endpoint equal to the max limit number when no `limit` is supplied, but continue to respect the `limit` pagination param when it is supplied. This will allow for client generation to continue to work, and will allow those using pagination by default to still be supported. For those not using pagination, the response `data` should again still be the same, and the default limit will not be a barrier to hitting pagination, as it will be the same as our max results. [1] OpenAPITools/openapi-generator#15 [2] OpenAPITools/openapi-generator#1709
lpichler
pushed a commit
that referenced
this pull request
Nov 8, 2023
[GitHub] - Automated ConfigMap Generation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to prevent default enforcement of pagination on the
/access/endpoint,this will remove the default limit (currently 10) from
/access/requests, whilekeeping it on all other endpoints.
When we get the paginator for the request, we'll now check to see if the
?limitquery parameter is sent in the request. If so, we'll continue to respect pagination
on the request, and return a paginated response. If
?limitdoes not exist inthe request, we will not set a paginator, which in tern will supply the raw
queryset to the serializer.
In order to keep a consistent API payload with and without pagination, we need to
explicitly return the serialized data nested under a
dataobject.With Pagination:
/api/rbac/v1/access/?application=ansible-automation&limit=20
Without Pagination:
/api/rbac/v1/access/?application=ansible-automation