接收多列表参数的Java REST API转GraphQL：建模与性能疑问

背景 #

现有一个Java REST API getFooInformationByRecognizer，接收包含识别器对象的列表作为输入，每个识别器包含id和类型（仅A、B、C三种），返回对应每个id的信息。输入可混合三种类型的识别器。

输入示例：

[{"id": "1", "type": "A" }, {"id": "2", "type": "B"},{"id": "3", "type": "C"}, {"id": "4", "type": "A"}, {"id":"5", "type": "B"}]

Java实体定义：

class FooRecognizer{
     String id;
     String FooType;
}

API处理逻辑：先提取所有A类型的id，调用对应服务从A数据源获取信息；同理处理B、C类型，最后将三类数据合并到HashMap返回。流程如下：

ids of type A --> A SERVICE -> <DATA SOURCE FOR A>
ids of type B --> B SERVICE --> <DATA SOURCE FOR B>
ids of type C --> C SERVICE --> <DATA SOURCE FOR C>

请求与响应的Java实体：
请求类：

class FooRequest{
   private Bar bar;
   List<FooRecognizer> list;
}

响应类：

class FooInformationResponse{
   private Map<String, FooRecognizer> fooInformationCollated;
}

响应JSON示例：

"output":{
    "fooInformationCollated":{
    "1":{
       "someProperty": "somePropertyValue",
       "listOfNestedProperties": [{"x": "xValue", "y": "yValue", "z":"zValue"}],
       "nestedProperty":{
          "anotherProperty":{
            "furtherNestedProperty": "value"
          }
        }
      },
   "2":{
        "someProperty": "somePropertyValue",
        "listOfNestedProperties": [{"a": "aValue", "b": "bValue", "c":"cValue"}],
        "nestedProperty":{
           "anotherProperty":{
             "furtherNestedProperty": "value"
          }
        }
      }
    }... and so on for other ids in the input

已设计的GraphQL查询与Schema #

查询语句 #

query{
  getFooInformationByRecognizer(filterBy:{
    fooRecognizer: [{
            id: "1",
            fooType: A
        }],
        bar: {
            barId: "someId",
            ...<other bar info>
        }
  }){
    fooInformationCollated{
      id
      fooInformation{
        someProperty
        listOfNestedProperties
        nestedProperty{
         anotherProperty{
            furtherNestedProperty
          }
        }

      }
    }
  }
}

Schema定义 #

type Query{
    getFooInfoByRecognizer (filterBy: getFooByRecognizerTypeFilter!):getFooByRecognizerTypeFilterResponse
}

input getFooByIdentifierTypeFilter{
    bar: Bar!
    fooIdentifiers: [FooIdentifier!]!
}

input Bar{
    barId: String!
    ....
}


input FooIdentifier{
    id: String!
    fooIdType: fooIdtype!
}

enum fooIdType{
    A
    B
    C
}

技术疑问解答 #

1. 当前查询建模是否为最佳实践？是否要改为三个独立列表参数？ #

当前用统一的fooIdentifiers列表（包含id和类型）的方式是合理的，既符合REST API原有输入模式，也让客户端无需提前拆分列表，调用更直观。

如果改成三个独立列表（listOfAs、listOfBs、listOfCs），优点是参数语义更明确，后端无需再做类型拆分；但缺点是客户端需要提前按类型分组输入，增加了客户端工作量，而且后续新增类型时必须修改查询参数，扩展性较差。

还有一种可选方式：保留统一列表的同时，允许客户端通过参数指定要过滤的类型，但对你的场景意义不大——你的API本来就需要处理所有类型的输入。

总体来说，当前的建模方式更符合通用最佳实践，除非有明确业务需求要求拆分参数，否则没必要改动。

2. 选择复杂输入类型的理由，以及反向场景 #

选择复杂输入类型的核心理由：

• 语义清晰：把相关参数封装成一个输入对象（比如filterBy包含bar和fooIdentifiers），参数间的关联关系一目了然，客户端更容易理解调用逻辑。
• 扩展性强：后续需要新增参数时，只需在输入类型里添加字段，不用修改查询的参数列表，避免API版本变更的麻烦。
• 兼容现有代码：你的Java后端已经有FooRequest这类封装类，用复杂输入类型可以直接对应，减少代码改造量。

适合不用复杂输入类型的场景：

• 参数极少且无关联时，比如只需要一个barId参数，直接用单个参数更简洁。
• 需要严格限制参数数量或类型，避免客户端传递冗余信息的场景。

3. 性能关注点与N+1问题的判断 #

你的判断基本正确，但仍有几个性能细节需要注意：

• 批量查询效率：确保对A、B、C类型的id分别做批量查询，而非逐个id调用服务。比如A类型有10个id，要一次性传给A SERVICE，而不是调用10次。
• 并发调用优化：可以考虑并行调用A、B、C三个服务，而非串行执行，能有效减少总耗时。
• 数据合并开销：如果返回的数据量很大，合并HashMap的过程要注意效率，避免不必要的对象拷贝。

关于N+1问题：因为你的查询是一次性获取所有需要的数据，后续解析字段时不需要再调用后端服务（所有数据已经在HashMap中），所以确实不会出现N+1问题。DataLoader主要解决解析嵌套字段时多次调用后端的问题，你的场景里用不上，因为所有数据已经提前批量获取完成。

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