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