HTTP Header to be returned in the case where the request is not entirely well formed and a large page size is requested

[WestpacOpenBanking]

Description

The HTTP Response Code section states that the HTTP status 400 Bad Request should be returned in cases where a request is not well formed. The pagination section states that HTTP status 422 should be returned in the case where the page size requested is strictly greater than 1000 records.

These two sections are in conflict in the edge case where a request is malformed (because of say a badly formatted query parameter) and the requested page size is greater than 1000 records.

We believe that the intent in that particular case would be to align with the HTTP Response Code section.

We would appreciate it if this could be confirmed.

Area Affected

The Pagination section.

Change Proposed

Update the Additional Pagination Rules section to say that:

A maximum page size of 1000 records is assumed for all end points (unless otherwise stipulated in the end point definition). If a page size greater than this maximum is requested and the request is otherwise well formed, then a HTTP status of 422 Unprocessable Entity SHOULD be returned. If the request is not well formed, then the HTTP status of 400 Bad Request SHOULD be returned.

[CDR-API-Stream]

Hi @WestpacOpenBanking this should be the expected handling of the error today based on the HTTP Response Codes section. The guidance for page size greater than 1000 provides an explicit response code for this situation. DHs should reasonably fallback to the guidance in the HTTP Response Codes section where a parameter is malformed.

As part of the Enhanced Error Handling consultation, there is benefit in differentiating the error codes and this will be covered there. Would this be a more reasonable focus to provide guidance on the error codes.

[CDR-API-Stream]

Hi @WestpacOpenBanking, this issue will be closed on Fri 19/02/2021 unless you believe the issue has not been sufficiently addressed.

[CDR-API-Stream]

This issue has been closed as part of backlog grooming for Standards Maintenance. Enhanced Error Handling (see Error Codes in the Data Standards) defines error codes for both errors presented in the original CR.