我想编写一个或多个方法,根据输入返回不同的结果。 从客户端,我向服务器发送请求并反序列化响应主体,我想提供已知类型:
需要不同的返回类型,以便当开发人员调用这些方法时,他们知道服务器的 api 响应中有哪些数据可用。这些方法应该返回发出 http 请求的响应。对于每个请求,发送的内容类型与接收的内容类型相同。有服务器在野外执行此操作。这里的上下文是从 openapi 文档生成代码。请求和响应正文允许路由上有多种内容类型:https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#request-body-object
此方法将从 http post 调用返回反序列化的响应。 我已经想到了一些可能的选择。
返回类型有:
public record ApiResponseWithDeserializationSkipped (
HttpResponse response) {} // body does not exist
public record ApiResponseForTextPlain (
HttpResponse response, String body) {}
public record ApiResponseForApplicationJson (
HttpResponse response, Map<String, String> body) {}
输入:
我对如何实现这一点的一些想法。
单身人士:
public ApiResponseWithDeserializationSkipped post(
SingletonTrue: skipDeserilization,
Object contentType,
Object body) {
// implementation
}
public ApiResponseForTextPlain post(
SingletonFalse: skipDeserilization,
SingletonTextPlain contentType,
String body) {
// implementation
}
public ApiResponseForApplicationJson post(
SingletonFalse: skipDeserilization,
SingletonApplicationJson contentType,
Map<String, String> body) {
// implementation
}
对skipDeserilization + contentType 输入使用枚举。这要求我的输出类始终包含响应+正文,但该正文将是多种内容类型的类型对象。 所以主体返回类型信息是未知的,这不太好。
为每个content_type编写单独的方法,contentType+skipDeserilization不是输入
public ApiResponseWithDeserializationSkipped post(
SingletonTrue: skipDeserilization,
Object contentType,
Object body) {
// implementation
}
public ApiResponseForTextPlain post(
SingletonFalse: skipDeserilization,
SingletonTextPlain contentType,
String textPlainBody) {
// implementation
}
public ApiResponseForApplicationJson post(
SingletonFalse: skipDeserilization,
SingletonApplicationJson contentType,
Map<String, String> applicationJsonBody) {
// implementation
}
这应该怎么做? 您更喜欢其中一种还是其他解决方案,为什么?
我认为这里至少提出了三个单独的问题 - 所以,三个答案:
选项 3(为每组不同的输入参数类型编写单独的方法)对我来说似乎是一个明显的赢家 - 因为它以开发人员已经熟悉的使用 Java 语言的正常方式完成了所需的一切。
相比之下,您的选项 1 和 4 引入了相当复杂的单例类用法,以强制选择特定的方法重载,这在我看来无缘无故地增加了复杂性。
你的选项 2 没有得到充分解释,无法充分说明你的意思,但你自己已经说了为什么它不好。
我认为你不能——任何通用工具都不能。你说过:
对于每个请求,发送的内容类型与接收到的内容类型相同。
但据我所知,没有办法在 OpenAPI 文档中表达这一点。
如果没有这一原则可供依赖,他们的代码就无法假设输入内容类型等于输出内容类型,因此需要在 OpenAPI 中表示的内容之外添加其他信息来创建开发人员友好的客户端库。
为什么人们对此投反对票?它被彻底描述,并且用例在 openapi 规范上下文中是有效的。
我不是投反对票的人之一,但我猜他们反对这个问题的描述方式令人困惑,并且将大部分字数集中在提出解决方案而不是解释问题上(正如评论中已经指出的那样,其中提到了“XY 问题”)。
服务器端 API 看起来过于复杂,这可能也无济于事,在某种程度上值得首先重新设计它(尽管我承认你已经说过你无权这样做)。