Azure APIM缺失必填查询参数返回404而非400是否为错误实现？

我有一个基于OpenAPI文档的API，通过Azure API Management（APIM）对外暴露，该API通过Terraform DevOps管道部署。以下是部署所用文档的片段：

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

重点关注scope查询字符串参数：API已成功部署且正常运行，但省略该参数时，APIM返回404 - Not found状态码。

根据相关讨论及RFC 7231规范，此类情况应返回400 Bad Request。我可通过将参数设为可选并由后端处理返回400，但认为这是错误实现，APIM行为存在问题。请问该假设是否正确？若不正确，原因是什么？

你的假设不完全正确，APIM返回404并非行为异常，而是由其路由匹配逻辑决定的：

1. APIM的路由匹配规则
   APIM在匹配API操作时，会将必填查询参数纳入路由匹配的判断条件。也就是说，当你在OpenAPI中把scope标记为required: true时，APIM会认为只有包含该参数的请求才属于/my-api/{some_id}的GET操作；没有携带scope的请求，APIM会判定为找不到对应的匹配操作，因此返回404。

这和常规后端框架的逻辑不同：后端通常是先匹配路径，再校验参数是否存在；而APIM是先校验请求是否完全匹配定义的操作签名（包括必填参数的存在性），再决定是否转发请求。

2. 合理的解决方案
   如果你希望APIM返回400而非404，有两种合规的处理方式：

• 添加APIM验证策略：保持scope为必填，在APIM的API策略中添加<validate-parameters>规则，显式校验该参数的存在性，当参数缺失时直接返回400状态码。
• 调整参数定义并由后端校验：将scope设为可选，由后端API负责校验该参数是否存在，若缺失则返回400。这种方式并非错误实现，而是适配APIM路由逻辑的合理方案。

3. 与RFC 7231的兼容性
   RFC 7231规定400用于请求存在语法或语义错误的场景，但APIM在此场景下返回404是因为它认为请求未匹配到任何已定义的API操作，属于路由层面的“未找到”，这是APIM自身设计逻辑的体现，并非违反规范。

内容的提问来源于stack exchange，提问作者Mutation Person