Welcome to the Consumer Data Right Support Portal

Check out our guides, browse through our FAQs, and post your own questions for Support.

New to the Consumer Data Right? Learn more

[ARCHIVE] CDR Error Code for invalid product category query parameter Follow

Avatar
Neale Morison
  • Created:
  • Last edited:
  • Updated

Archived 2022.11.20. Content moved to error scenarios and responses.

Question

What are the expected CDR error codes for the following scenarios:

  • The value sent as product_category query parameter is not a valid product category according to the CDS specification.
  • The value sent as product_category query parameter is a valid product category according to CDS specification, but it is not offered by the Data Holder (DH).

Answer

If the value provided is not a valid value for a well-defined enumeration, then the appropriate HTTP status code is 400 Bad Request because "request has malformed, missing or non-compliant JSON body or URL parameters".

If the value is a valid enumeration value, however the Data Holder does not support that value, the appropriate HTTP status code is 422 Unprocessable Entity because "the request was well-formed but unable to be processed due to business logic specific to the request".

A 422 Unprocessable Entity response is permitted where the Data Holder receives a product-category filter that is correct according to the standards (a valid enumerated type) but the Data Holder knowingly doesn't offer that category of product to the market.

A 200 OK status response is also permitted in that situation and it is likely to be easier for Data Holders to implement in any event.

 

See:

Comments

4 comments

Sort by Date Votes
  • Avatar
    Nils

    Hi Neale Morison

    Would a 200 status response with an empty array be acceptable where no accounts or products match the query?

    There are quite a few arguments in favour of a 200 in a REST API, e.g. -
    https://stackoverflow.com/questions/13366730/proper-rest-response-for-empty-table
    https://stackoverflow.com/questions/11746894/what-is-the-proper-rest-response-code-for-a-valid-request-but-an-empty-data

    1
    Comment actions Permalink
  • Avatar
    Rod Dalrymple
    • Edited

    Hi Neale Morison

    I second Nils comment. HTTP 4xx status response codes are errors and more specifically 'client errors'. A request with query parameters that do not result in any resources/objects/records are not a client error as the client can't know the contents of the datastore being filtered. The HTTP 422 definition 'Unprocessable Content' (and example with 'semantically erroneous') does not apply as the server is able to process the request and return an empty array (with a HTTP 200). This is more in line with industry practice in REST APIs but also in all styles of data querying where an empty result set is not accompanied by an error condition or code.

    I'm sure this has been discussed or documented before in other contexts (Get Transactions comes to mind), but I've been unable to find a documented reference in Github or Zendesk.

    I also contend that the first case (invalid product-category) should return a 422 as:

    the syntax of the request entity is correct (thus a 400 (Bad Request)
    status code is inappropriate) but [the server] was unable to process the contained
instructions.  For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.

     

    [Ref: https://www.rfc-editor.org/rfc/rfc4918#section-11.2] 

    1
    Comment actions Permalink
  • Avatar
    Jarryd

    Hi Nils,

    To your question: 

    A 200 OK would be acceptable where the Data Holder doesn't have any products or accounts matching a valid product category. If however the product category is not valid (it is not defined in the enumeration) then it is an error and a 400 Bad Request is correct.

    Hope helps with your question; we'll work through the article as well. Rod Dalrymple we'll take your comments as well.

    Thanks,

    -Jarryd

    0
    Comment actions Permalink
  • Avatar
    Jarryd

    Hi Rod Dalrymple,

    Had a chat internally and this is what is advised:  the consultation on error codes at the time concluded that errors arising from invalid field values should be a 400 Bad Request. 

    Applies when the value of the URL parameter or request body parameter is an invalid type or the value violates the field's constraints as defined by the interface contract.

    The 422 Unprocessable Entity would be permitted where the Data Holder receives a product-category filter that is correct according to the Standards (a valid enumerated type) but the Data Holder knowingly doesn't offer that category of product to the market. As previously highlighted by Nils remarks and question, a 200 OK is also permitted in that situation and it is likely to be easier for Data Holders to implement in any event.

    Hope this answers your question.

    Thanks,

    -Jarryd

    0
    Comment actions Permalink

Please sign in to leave a comment.