在这种情况下使用什么适当的HTTP状态代码？

Question

我正在实现一个简单的API流程，其中涉及充当多个上游API的网关。

image demonstrating the flow

基本上，客户端向该端点提供令牌，服务器对API进行多次顺序调用，从最终调用中收集一堆信息，然后将其返回。

我们收到一个令牌，然后转到Upstream API 1，收到一堆与该令牌关联的Objects。理论上，返回的Objects数量不受限制。

然后我们用逗号分隔每个Object的ID，并用逗号分隔的Upstream API 2转到ObjectIDs，以在所有{{1} }。

此MetaInformation可能并非每个Objects都唯一，因此我们可以收到1到MetaInformation Object数目之间的任意地方。

然后，我们打算使用逗号分隔的Objects到第三个API，但是此上游API只能使用10个唯一的MetaInformation，这意味着我们将无法收集客户期望的信息。因此，我们可以在此时发出失败案例而无需发出失败的上游请求，但是适合使用哪种HTTP状态？

客户似乎没有提出错误的要求，因为他们当时无法知道唯一MetaInformationIDs的数量，但是我们将收到MetaInformationIDs的状态是我们发出的请求> 10 MetaInformationIds。

有什么想法吗？

编辑：对于上下文，我忘记提及上游API打算在将来进行升级以支持> 10个唯一ID，因此，目前已经确定，对该API的多请求解决方案不值得。我完全同意这是次优的解决方案。

Answer 1

我的建议是让您的第二个微服务创建足够小的MetaInformationIDs批次，以使对第三个微服务的调用成功。在这种情况下，调用将有望成功，从而消除了您所描述的错误。如果您不能做这样的事情，那么也许您应该重新考虑您的设计。如果可以，那么作为备用，您可以返回500服务器端错误代码，这仅意味着服务器上发生了一些常规错误。

Answer 2

如果10个以上的MetaInformationID是一种不良情况/意外情况，则相应的状态代码应为500 Internal Server Error-如您所说，问题不在于请求，而在于内部约束可以由客户控制。

如果这不是一种特殊情况，那么听起来更像是您的API的一个限制，需要解决，例如创建足以覆盖所有需要处理的唯一ID并返回202 Accepted

的方法，而不是仅支持对第3 API的单个请求

Answer 3

我们使用400个响应状态代码来指示服务器由于某些原因导致客户无法或不会处理该请求，例如，客户端错误（例如，格式错误的请求语法）并不符合您的要求。

500状态代码或内部服务器错误，表示服务器由于未知原因无法处理该请求。有时，当更具体的5xx错误更合适时，此代码就会出现，这在您的情况下似乎是合适的，因为您的API仅可以使用10个唯一的MetaInformationID。