mraineri
commented
3 years ago The first test verifies the HTTP status code; as long as it's a 501, the test passes.
The second test verifies the response message contains an indicator that the referenced query parameter in the extended error. In the payload you provided for the second attempt, it's using the more general "QueryNotSupported" which is used to indicate query parameters are not supported at all. Your first attempt contained text that called out the specific query parameter that is not valid, which is why it passed before. Unfortunately looking between the spec and standard messages, I don't see how we can reasonably expect folks to implement to this. The spec contains the following text today:
Services shall return:
- The HTTP 501 Not Implemented status code for any unsupported query parameters that start with $.
- An extended error that indicates the unsupported query parameters for this resource.
The second bullet is in conflict with what we have standardized for messages; no standard messages today allow a service to indicate which query parameter is not allowed. I'll need to raise this with the forum for discussion.
The tests case below return status code not consistent:
Attach the following picture for your reference: Old version
Repaired version
Attach the following 501 status code message for your reference: { "error": { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_0_8.Message", "Message": "Querying is not supported by the implementation.", "MessageId": "Base.1.5.QueryNotSupported", "Resolution": "Remove the query parameters and resubmit the request if the operation failed.", "Severity": "Warning" } ], "code": "Base.1.5.QueryNotSupported", "message": "Querying is not supported by the implementation." } }
Why the second test case return status code change to 501 will fail? Is this issue caused by error message mentioned in Message?