我们今天进行了一场有趣的辩论，讨论在验证存在意外字段的请求正文时，API应该默认执行的操作。我认为我们在一个合适的地方结束了对话，但是它提出了我想进一步探讨的是否或如何应用Postel定律的一个元论点。
我们的应用程序实质上是一个大型而复杂的订单管理，匹配和调度系统（类似于乘车共享服务）。除了实体管理（CRUD）之外，我们的大多数端点都与订单输入，匹配和管理流程中各个阶段的操作有关。没有计划公开开放此API，因此唯一的客户端是我们的移动和Web应用程序（以及我们编写的脚本）。
过去，我写过一些系统，我们在接受领域采用了宽松的方法，当时情况是我们是必须处理的事件流的接收者。在那种情况下，API在接受任意字段时必须是自由的，否则上游生产者将无法有效地添加功能或更改其系统。
但是，在我看来，这是我们想要严格接受的情况。这里的所有用户都是内部开发人员，因此很难想象在许多常见的情况下，宽容可以通过严格的API购买可靠性。我们已经同意，与严格的API相比，在开发方面有很大的改进，并且可以通过在开发过程中进行严格验证来避免许多错误，但是有观点认为，允许的API在生产时会更可靠，因为它不会对其他可接受的请求进行轰炸。但是，由于我们控制着所有合法的客户端，因此似乎不应该在这种情况下结束，除非在某些罕见的客户端发布版本中，这些客户端版本在API准备使用它们之前就使用了某些字段。因此，如果我们开始看到意外的字段，那么至少在大多数情况下我们都想知道并可能出错。是否有一种常见的情况我会错过，那就是限制性API会拖慢我们的速度。
团队的背景有所不同，所以其中一些可能是由于心态不同所致。我想在这里听到并理解其他人的观点，因为我没有完全接受允许宽容性更可靠的论点，而我们希望为具有意外领域的客户提供服务。
答案 0 :(得分：0)
最好限制（或控制）对流入应用程序的数据的控制。它有助于避免意外的错误。同时，由于客户端和服务器端都缺少适当的输入筛选，因此会出现许多漏洞。 这是一些破坏性的安全问题（但容易被利用），
请参阅OWASP top 10安全问题。
如果您希望某些API支持意外数据，请确保采取必要的安全措施以确保应用程序安全。例如，在基于浏览器的客户端中进行正确的输出编码，在使用用户输入等进行数据库查询之前转义通配符。