强大的API很奇怪

我的第一次全职API测试经验是针对SOAP服务的。在那里您将了解什么是XSD。你要学会热爱它。

你当然需要！有了基于模式的服务器端启用的验证，您就不必担心愚蠢的测试，比如检查当您发送100个长度的字符串(预期最大长度为50)时会发生什么。只需确保XSD完全正确即可。

在那次魔术之后，测试RESTish API感觉就像回到了过去。回到非常体力劳动的时代。但是，当您了解JSON Schema(RAML、OpenAPI等)时，您又会感到高兴了！耶，我们可以打开服务器端验证，再次推开愚蠢的测试工具。

问题是JSON和XML是不同的野兽。从表面上看，假设模式中定义的任何内容都应该盲目验证，这可能是错误的。

好好看看tugrik元素。如果没有XSD，您就不会知道预期的类型。虽然它看起来像是数字，但您不能确定。也许是像名字一样的字符串？

哦，不，你说，那看起来不对！我们知道图格里克是一个数字，所以就让它成为一个数字：

然而，通过这样做，现在我们甚至不需要任何JSON Schema来猜测类型。没有讨厌的小引号-这是一个令人讨厌的数字！

也许你知道这是怎么回事了。XML文档是纯文本的。每个元素的值都是一个简单的字符串，框架使用XSD将其转换为正确的类型。

但我离题了。主要的一点是，基于XML的文档往往要经过转换机制。只有当无法完成强制转换时，验证才会失败。

JSON不是纯文本的。它们已经有了一些仅通过观察就能看到的基本类型。如果在上面添加JSON Schema并使用任何不太健壮的验证器，则行为将完全不同。

因为验证JSON文档的最简单方法是首先使用一些公用库来使用它，这些库猜测类型几乎和我们一样：“它周围有引号吗？弦！“。只有在此时，使用已经转换的值，才能将其类型与模式中定义的任何内容进行比较。

您能猜到真正健壮的验证器有什么不同吗？正确的!。他们使图格里克：10&34；通过验证。因为他们遵循波斯特尔定律：

虽然这句话比微不足道的小测试者的博客所能处理的要复杂得多，但了解它的存在和应用是很重要的。在任何程度上遵循波斯特尔定律都是一种设计和选择。

如果您的服务旨在将弱输入(如"；tugrik"；："；10"；)作为有效数字处理，则不是错误。如果您在请求中发送了额外的属性，而服务忽略了它们而没有抛出4xx错误，那么这也不是一个错误。这可能是一个非常好的功能。

是的，肯定有一种方法可以错误地或过度地做健壮性。如果您从头开始编写浏览器引擎(为什么？)，您将严格遵循Postel定律。另一个原因是确保API客户端的最长正常运行时间。他们成功的请求越多，连接到您的产品所需的工作就越少，从而获得更高的利润。

因此，当您探索新的API时，在提交错误“Achtung，Achtung，no Validation！1”之前，请确保您了解设计的方式和原因。