REST API包装器在发出请求之前是否应验证输入？

Question

假设服务器将JSON字段限制为枚举值集。

e.g。对/user的POST请求需要一个名为gender的字段的对象应该只有＃34;男性＆＃34;，＆＃34;女性＆＃34;或＆＃34; n / a＆＃34;。

包装程序库是否应确保在发出请求之前正确设置了字段？

Answer 1

Pro：使客户端可以快速拒绝原本需要往服务器往返的输入。在某些情况下，这将允许更好的用户体验。

Con：你必须让libary与后端同步，否则你可以拒绝一些有效的输入。

使用体面的类型系统，您应该在库API中对此特定限制进行编码。我认为通常人们至少会验证客户端上的基本内容，让服务器进行进一步的验证，就像客户端根本无法验证的那样。

Answer 2

这是一个设计选择 - 枚举类型约束应记录在服务器的公共API中，并且它是合同的一部分。

客户被迫遵守合同以成功提出请求，但不需要实施验证逻辑。您可以安全地让客户端因“错误请求”或其他4xx错误而失败。

在双方实现验证逻辑将客户端和服务器耦合 - 验证逻辑的任何更改都应在双方实现。 如果验证逻辑更接近常识（例如，该字段不应为空），则可以安全地在两端实现。 如果验证逻辑更具域特性，我认为它应该只保留在后端。

您必须考虑使用包装库（可以将其视为服务器API的客户端）进行相同的权衡。这取决于包装库的作用是什么 - 如果包装库应该公开服务器的完整API协定 - 而不是所有的方式验证逻辑可以在包装库中复制 - 否则我会将它保留在后端

Answer 3

包装器库是REST api的实际客户端，因此必须遵守architectural和协议强加的约束。在his blog post菲尔丁进一步解释了一些限制因素。其中一个是typed resources，它指出客户端不应该假设API返回特定类型，即JSON中的一些用户详细信息。这就是媒体类型和内容协商的真正含义。

媒体类型的定义可以为客户提供有关如何处理收到的数据的提示，例如基于JSON或XML vCard格式的提示。由于媒体类型定义了某些特定文档的实际格式，因此它可能包含处理规则，如预验证要求或语法规则，即通过XML架构或JSON schema验证。

远程计算的基本规则之一是永远不会信任所接收的输入，因此服务器应该验证结果，无论客户端之前是否已经进行了预验证。由于类型化的资源约束，真正的RESTful客户端将检查接收的媒体类型是否支持通过其规范进行预验证，并且仅在规范定义时应用预验证，并且还提到了如何执行它的一些机制（即通过某种架构机制）。

我个人对此的看法是，如果您尝试遵循REST架构方法，除非媒体类型明确支持，否则您不应验证输入。由于客户端将通过错误响应了解某个REST端点所期望的字段和值，并且服务器希望验证输入，无论如何我都没有看到在客户端验证它的必要性。由于性能考虑因素通常比遵循规则和建议更重要，因此由您决定。但请注意，这可能会也可能不会将客户端耦合到服务器，从而增加了更容易破坏服务器更改的风险。由于REST不是协议而是设计建议，因此您需要选择哪条路径。