You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description: If PUT, and json is a list, limit the list size to 250.
Justification: This will prevent the client from making unnecessary HTTP requests that are expected to elicit a status 418 response because the limit is exceeded, or even providing the basis for batching requests to handle a very large list.
Risks: other endpoints could potentially implement multi-update without such a limit, or with a different limit. We may need to use a crutch similar to ENTITY_WRAPPER_CONFIG to get around this in the near future if/when this happens, to avoid arbitrarily depriving users of a higher multi-update limit in an endpoint that allows it.a We then have another manually-maintained list where adding support is a one-liner.
Precedent: we already do this for the max offset in pagination to prevent wasted API calls, so it makes sense to do it here, despite the risk of us adding another antipattern config. Where the assumptions made in the abstractions of this client do not hold universally true for all constituent APIs of REST API v2, is where we have to manually maintain some list that distills each divergence between client expectations and API design (or automate it if possible using the documentation source).
Description: If
PUT
, andjson
is a list, limit the list size to 250.Justification: This will prevent the client from making unnecessary HTTP requests that are expected to elicit a status 418 response because the limit is exceeded, or even providing the basis for batching requests to handle a very large list.
Risks: other endpoints could potentially implement multi-update without such a limit, or with a different limit. We may need to use a crutch similar to
ENTITY_WRAPPER_CONFIG
to get around this in the near future if/when this happens, to avoid arbitrarily depriving users of a higher multi-update limit in an endpoint that allows it.a We then have another manually-maintained list where adding support is a one-liner.Precedent: we already do this for the max offset in pagination to prevent wasted API calls, so it makes sense to do it here, despite the risk of us adding another antipattern config. Where the assumptions made in the abstractions of this client do not hold universally true for all constituent APIs of REST API v2, is where we have to manually maintain some list that distills each divergence between client expectations and API design (or automate it if possible using the documentation source).
Sources:
The limit should eventually be documented here: https://developer.pagerduty.com/docs/ZG9jOjExMDI5NTU0-endpoints#put-resources-update-multiple
The text was updated successfully, but these errors were encountered: