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.

Resulting Status lawmaking 400 – max size exceeded

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.

Resulting Condition Code 400 – unspecified content type

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.

Preventions will generate exceptions, hither seen in Application Insights

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.

Resulting Status Lawmaking 400 – Invalid json

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.

Resulting Condition Code 400 – Unspecified header

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.

The required integer parameter in APIM

<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.

Resulting Status Code 400 – with a generic error bulletin

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.

The required header in APIM

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.

Returned Status Code 400 telling the value is invalid for spoken-language

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.

Returned Status Code 400 telling the request could non exist processed

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.

Description of Test-Header

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."

Generic response with Condition Lawmaking 400

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.

Only Status Code 200 is specified

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.

Condition 502 if an unspecified header is returned

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.

tookesackled.blogspot.com

Source: https://skastberg.com/2021/04/15/azure-api-management-validation/

Share this post