假设我有一个POST /orders将订单项目集合作为输入的操作。一个订单不能包含超过 50 件商品，但我在哪里执行此验证？
在客户端和服务器中验证订单大小将是多余的，如果我决定更改订单大小限制，则会增加维护成本。
仅在服务器中对其进行验证将防止客户端“快速失败”（即，您将一千件商品添加到订单中，并且仅在完成时才被告知限制）。
我假设客户端验证不是一个选项，因为 API 可能有其他客户端。
如果我有动态验证规则，问题会变得更加复杂。假设零售客户可以订购 50 件商品，但批发客户的订单中可以订购 500 件商品。API 是否应该公开一个操作，以便客户端可以获取当前的验证规则？
我同意前面所说的。
虽然，我认为如果您可以预测用户可能遇到的几乎所有情况，您也可以创建客户端验证。
根据您关于批发/零售的示例，您可以首先创建一个下拉列表，要求客户选择他们是批发还是零售，然后根据第一个选项将 500/50 规则应用于输入框。
明显的问题在于，如果您的 API 发布给其他开发人员，他们可能不知道 50/500 规则，这就是我同意之前关于服务器上发生的关键验证的答案的地方。如果您正在构建供自己使用的 API，那么您可以采用任何一种方式，因为您知道输入限制。如果应用程序非常大，它还将节省相当多的服务器成本（服务器上的验证会很费力）。
你必须两者都做，但不同。
为了保证有效操作，所有关键验证都必须在服务器/Web 服务端进行。客户端 UI 就是这样 - 一个用户界面，使人们可以方便地与 Web 服务进行交互。一旦 Web 服务稳定且安全，创建一个默认方法通过客户端将 Web 服务错误传递给用户。在那之后，UI 层中的功能是可用性问题，应该基于测试（即使那是通过监视用户的肩膀或听取反馈的非正式测试。）