Incorrect APIM Response for Malformed Request

Question

I have an Open API document that I have as the basis of an API that I am exposing through Azure API Management (APIM).

The following shows a snippet of the document that is used when the API is deployed through a terraform devops pipeline:

openapi: 3.0.0
info:
  title: my-api
  description: 
  version: "1.0"
...
...
paths:
  /my-api/{some_id}:
    get:
      ......
      operationId: get-stuff
      parameters:
      - name: scope
        in: query
        description: The scope that the request for details is being made in
        required: true
        style: form
        explode: true
        schema:
          type: string
          example: owner
          enum:
          - owner
      ...
      responses:
      ...
        "400":
          description: Bad Request
          

The important bit I am wanting to highlight is that scope querystring parameter.

The API is deployed successfully, and is working, but I have noted that if I omit this querystring parameter, that APIM returns a 404 - Not found.

There has been debate on other questions on SO (e.g. What HTTP status response code should I use if the request is missing a required parameter?), but most are really clear that 400 Bad request is the correct response here (https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1)

I can easily return a 400 instead (I make the param optional, and let the policy or back-end handle it), but it my view is that this is an incorrect implementation, and that APIM is actually incorrect in doing.

Is this a correct assumption, and if not, why not?

Answer 1

@Wiseman, James,Welcome to the Microsoft Q&A Platform!

Thank you for reaching out. You are correct; this has been the intended behavior of API Management from the beginning and has been discussed in various forums.

You can submit a feature request here so the product team can implement a feature to control this behavior. The default behavior is 404, but customers can override it to 400 as per their requirements like the way you suggested to handle. I will also discuss with the internal team on this and will suggest you post the same as feature request in our feedback forum.