Error Validating Settings: Can Not Use --fields When Input Type Is Json
I had the opportunity to look at the new validation functionality for APIM. I summarize my thoughts to call back and share with others. You find the documentation post hither: https://docs.microsoft.com/en-us/azure/api-management/validation-policies
We have iv ways to validate requests and responses, content, parameters, headers, and status code. Three actions tin can be taken, ignore, detect, or foreclose. Ignore will skip the validation, detect will log the validation error only non interrupt execution and forestall volition cease processing on first error. Validations have a high-level settings that tells what to do with a specified or unspecified settings.
Note: As stated in the documentation I needed to reimport my API using management API version2021-01-01-preview
or later. I did this with a PowerShell script that you can find here APIM-Examples/Validation at chief · skastberg/APIM-Examples (github.com)
Content
Validates the size of a request or response, also ensure that the body coming in or out follow the specification in the API description. For schema validation nosotros're express to json payload. Content-Type validation is checked towards the API specification. Size validation works with all content types up to 100KiB payload size. This validation tin be applied on all scopes for sections inbound, outbound and on-error.
The policy name is validate-content, details on usage see here: https://docs.microsoft.com/en-united states/azure/api-direction/validation-policies#validate-content
Content validation examples
To ensure that the specified content-type is honoured, set unspecified-content-type-activeness to forestall and to limit the size of a asking set max-size and size-exceeded-action to prevent.
<policies> <inbound> <base of operations /> <validate-content unspecified-content-type-activeness="prevent" max-size="102400" size-exceeded-action="prevent" errors-variable-name="requestBodyValidation" /> </entering> <backend> <base /> </backend> <outbound> <base /> </outbound> <on-fault> <base /> </on-mistake> </policies>
APIM will return a status code 400 for any asking with a body that exceeds the max-size.
If the asking doesn't set the right content-type a status lawmaking 400 is returned. In this case the required blazon is application/xml only the provided is text/xml.
Preventions volition generate exceptions that can be seen in Awarding Insights, also you could Trace the errors. The prototype shows a query in Application Insights showing the exceptions joined with the request information.
In this example the policy validates size and content-blazon as the previous 1 and in addition the content chemical element specifies to validate the payload.
<policies> <entering> <base /> <validate-content unspecified-content-type-action="prevent" max-size="102400" size-exceeded-action="forbid" errors-variable-name="requestBodyValidation"> <content type="application/json" validate-as="json" activeness="prevent" /> </validate-content> </inbound> <backend> <base /> </backend> <outbound> <base of operations /> </outbound> <on-fault> <base /> </on-error> </policies>|
If the payload doesn't conform the json schema a status lawmaking 400 is returned with at descriptive message.
Parameters
Apart from the content(torso) nosotros receive information as parameters, header, query, or path. This validation checks the incoming parameters confronting the API specification. Each parameter type has its own chemical element in the policy, depending on needs one or more are used. The API specification volition show how parameters are expected, types and if mandatory or non. This validation tin exist applied on all scopes for the inbound section.
The policy name is validate-parameters, details on usage encounter here: https://docs.microsoft.com/en-us/azure/api-management/validation-policies#validate-parameters
Parameter validation examples
Any parameters
With the following policy with unspecified-parameter-action set to prevent, any parameter of any kind in the asking that is non in the API specification will exist stopped.
<policies> <inbound> <base /> <validate-parameters specified-parameter-activeness="ignore" unspecified-parameter-action="preclude" errors-variable-proper noun="requestParametersValidation" /> </inbound> <backend> <base /> </backend> <outbound> <base /> </outbound> <on-fault> <base /> </on-error> </policies>
The resulting status code 400 response from APIM. In this case a header only it could be something else depending on your specification.
Path
In this example an operation has the required parameter, format, that we want to validate earlier sending to the backend. If the request with wrong blazon for format is received, we get a 400 fault from APIM. As we ready specified-parameter-action and unspecified-parameter-action to ignore other errors will be disregarded.
<policies> <inbound> <base /> <validate-parameters specified-parameter-action="ignore" unspecified-parameter-action="ignore" errors-variable-proper name="requestParametersValidation"> <path specified-parameter-activeness="detect"> <parameter name="format" action="forbid" /> </path> </validate-parameters> </entering> <backend> <base of operations /> </backend> <outbound> <base /> </outbound> <on-error> <base /> </on-error> </policies>
In this instance the response is more than generic not specifying the incorrect parameter, that said the exception seen in Application Insights is more specific.
Headers
In this case an operation has the required header, spoken-language, that nosotros want to validate before sending to the backend. The header is an enumeration, and we desire to validate that the correct values are used earlier sending to the backend.
To prevent that the request is forwarded if an invalid value in the spoken-linguistic communication header we can employ the post-obit policy.
<policies> <inbound> <base /> <validate-parameters specified-parameter-action="prevent" unspecified-parameter-action="ignore" errors-variable-proper name="requestParametersValidation"> <headers specified-parameter-activity="detect" unspecified-parameter-action="ignore"> <parameter name="spoken-language" activeness="forbid" /> </headers> </validate-parameters> </inbound> <backend> <base of operations /> </backend> <outbound> <base /> </outbound> <on-fault> <base /> </on-error> </policies>
A request with an invalid value returns status code 400.
Query
In this example an performance has the query parameter, dayno, that we want to validate earlier sending to the backend. The header is an integer, and we desire to validate that the correct type is used before sending to the backend.
<policies> <inbound> <base /> <validate-parameters specified-parameter-activeness="ignore" unspecified-parameter-action="ignore" errors-variable-name="requestParametersValidation"> <query specified-parameter-action="detect" unspecified-parameter-activity="ignore"> <parameter name="dayno" activeness="foreclose" /> </query> </validate-parameters> </inbound> <backend> <base /> </backend> <outbound> <base of operations /> </outbound> <on-error> <base /> </on-error> </policies>
A request with a non integer value will be prevented and a status code 400 returned past APIM.
Headers
Just as nosotros validate incoming parameters it might be necessary to validate that our outbound data adheres to the API specification. This validation checks that the response headers is of the type nosotros have specified in the API clarification. This validation tin exist applied on all scopes for sections outbound and on-error.
The policy proper name is validate-headers, details on usage meet here: https://docs.microsoft.com/en-united states of america/azure/api-management/validation-policies#validate-headers
Example
In this example an functioning that has the Test-Header specified as integer.
In this policy nosotros detect specified headers but don't act on any errors except Test-Header. Unspecified headers will be ignored.
<policies> <inbound> <base of operations /> </entering> <backend> <base /> </backend> <outbound> <base of operations /> <validate-headers specified-header-action="detect" unspecified-header-action="ignore" errors-variable-name="responseHeadersValidation"> <header name="Examination-Header" activity="preclude" /> </validate-headers> </outbound> <on-fault> <base /> </on-error> </policies>
Returning a response of wrong blazon will result in a status code 400 with a generic text "The request could not be processed due to an internal error. Contact the API possessor." if you look into Application Insights the message is more clear "header Test-Header cannot be validated. Input string 'yourvalue' is not a valid number. Path ", line 1, position 3."
Status code
An important part of our API specifications are the status codes we render. This validation bank check the HTTP status codes in responses against the API schema. This validation can be practical on all scopes for sections outbound and on-error.
The policy proper name is validate-status-lawmaking, details on usage come across here: https://docs.microsoft.com/en-us/azure/api-management/validation-policies#validate-condition-code
Example
In this case an operation that has merely condition code 200 specified. If the requested session doesn't exist the backend will return Status Lawmaking 404. We want to validate all not specified status codes except 404.
To avoid the status code 502 that will be the issue if nosotros validate any unspecified condition codes we add a condition-code element with action ready to ignore.
<policies> <inbound> <base of operations /> </inbound> <backend> <base of operations /> </backend> <outbound> <base /> <validate-condition-lawmaking unspecified-status-code-action="prevent" errors-variable-proper name="variable name"> <status-code code="404" action="ignore" /> </validate-status-code> </outbound> <on-error> <base /> </on-error> </policies>
The prevented response if we don't ignore the 404 status code.
The exception in Awarding Insights
Summary
This is definitely a set up of policies that we tin can utilise to ensure that a API specification is honored. Information technology will require some thinking to remainder the merchandise off between the added value and the performance implication of doing the validation.
Source: https://skastberg.com/2021/04/15/azure-api-management-validation/
0 Response to "Error Validating Settings: Can Not Use --fields When Input Type Is Json"
Post a Comment