您是否应该防止来自外部API的意外值？

可以说，您正在编码一个从外部API接收输入的函数MyAPI。

该外部API MyAPI的合同规定其将返回string或number。

它是推荐的防范之类的东西null，undefined，boolean等即使它不属于API的一部分MyAPI？特别是，由于您无法控制该API，因此无法通过诸如静态类型分析之类的方法来做出保证，因此，安全起来总比对不起好。

我在考虑稳健性原则。

无论来源是什么，您都永远不要相信软件的输入。不仅验证类型很重要，输入范围和业务逻辑也很重要。根据评论，OWASP对此进行了很好的描述

如果不这样做，充其量只能留下您以后需要清理的垃圾数据，但最坏的情况是，如果上游服务以某种方式受到破坏，您将留下被恶意利用的机会（qv目标黑客）。介于两者之间的问题范围包括使应用程序处于不可恢复的状态。

从评论中我可以看到，也许我的答案可能会有所扩展。

所谓“从不信任输入”，只是意味着您不能假设您将始终从上游或下游系统接收有效且可信赖的信息，因此，您应始终尽力清除输入或拒绝输入它。

我将举例说明，评论中出现了一个论点。是的，您必须在某种程度上信任您的操作系统，例如，拒绝随机数生成器的结果（如果您要求输入1到10之间的数字并且它以“ bob”作为响应），这并不是没有道理的。

同样，对于OP，您绝对应该确保您的应用程序仅接受来自上游服务的有效输入。如果情况不佳，您该怎么办，取决于您要完成的实际业务功能，但是您至少要记录下来以供以后调试，否则请确保您的应用程序不会运行进入无法恢复或不安全的状态。

尽管您永远无法知道某人/某事可能给您的所有可能输入，但您当然可以根据业务需求限制允许的输入，并以此为基础进行某种形式的输入白名单。

是的，当然。但是，什么使您认为答案可能有所不同？

您肯定不想让程序以某种不可预测的方式运行，以防API无法返回合同规定的内容，不是吗？因此，至少您必须以某种方式应对这种行为。最小限度的错误处理总是值得（非常少！）的努力，并且绝对没有任何理由不执行这样的事情。

但是，应对这种情况您应该投入多少精力在很大程度上取决于大小写，并且只能在您的系统环境中回答。通常，只需简短的日志条目并让应用程序正常结束就足够了。有时，您最好实施一些详细的异常处理，处理不同形式的“错误”返回值，并且可能必须实施一些后备策略。

但是，如果您只编写一些内部电子表格格式的应用程序（供少于10人使用，并且应用程序崩溃的财务影响很小），或者正在创建新的自动驾驶汽车，那将大为不同系统，应用程序崩溃可能会丧命。

因此，没有捷径可以反省自己在做什么，使用常识始终是必不可少的。

健壮性原则-具体来说，“一半接受您所接受的东西是自由的”-在软件中是一个非常糟糕的主意。它最初是在硬件的环境中开发的，在物理环境中，物理限制使工程公差非常重要，但是在软件中，当有人向您发送格式错误或不正确的输入时，您有两种选择。您可以拒绝它（最好是对哪里出了问题进行解释），也可以尝试弄清楚它的含义。

编辑：原来我在上面的声明中弄错了。健壮性原则不是来自硬件领域，而是来自Internet体系结构，尤其是RFC 1958。它指出：

3.9发送时要严格，接收时要宽容。在发送到网络时，实现必须严格遵循规范，并容忍来自网络的错误输入。如有疑问，除非规范要求，否则请静默丢弃错误的输入，而不会返回错误消息。

简而言之，这从头到尾都是错误的。出于这篇文章中给出的原因，很难想象出一个比“无提示地丢弃错误的输入而不返回错误消息”更错误的错误处理概念。

另请参阅IETF论文“稳健性原则的有害后果”以进一步详细说明这一点。

永远不要，永远不要选择第二种选择，除非您拥有与Google搜索团队相当的资源来投入您的项目，因为这就是想出一种计算机程序所需的资源，该程序可以在特定的问题域中完成任何体面的工作。（即使那样，Google的建议似乎也有一半时间是直接从左字段出来的。）如果您尝试这样做，最终将是头疼的地方，您的程序将经常尝试解释当发件人的实际意思是Y时，输入为X的错误信息。

这是不好的，有两个原因。显而易见的原因是因为这样您的系统中的数据很差。不太明显的是，在很多情况下，您和发送者都不会意识到出了什么问题，直到很晚以后当您的脸炸毁时，然后突然您要解决一个巨大，昂贵的混乱，并且一无所知出了什么问题，因为至今仍未从根本上消除明显的影响。

这就是为什么存在“快速失败”原理的原因。通过将其应用到您的API，可以节省所有人的头痛。

通常，应在可行的情况下构造代码以至少遵守以下约束：

1. 当给出正确的输入时，产生正确的输出。

2. 当给出有效输入（可能正确或不正确）时，产生有效输出（同样）。

3. 当给定无效输入时，对其进行处理时，除了正常输入或定义为发信号错误的副作用以外，没有任何副作用。

在许多情况下，程序实际上将通过各种数据块，而不必特别关心它们是否有效。如果这些块恰好包含无效数据，结果程序的输出可能包含无效数据。除非专门设计用于验证所有数据的程序，并保证即使给定了无效的输入也不会产生无效的输出，否则处理其输出的程序应考虑其中包含无效数据的可能性。

尽管尽早验证数据通常是可取的，但它并不总是特别实用。除其他事项外，如果一个数据块的有效性取决于其他块的内容，并且输入到某些步骤序列中的大部分数据在此过程中是否会被滤除，则将验证范围限制在通过与尝试验证所有内容相比，所有阶段都可能产生更好的性能。

此外，即使程序只是预期给予预先验证的数据，它往往是件好事，它秉承了上述约束反正只要实用。在每个处理步骤中重复进行完整的验证通常会消耗大量的性能，但是为了满足上述约束而需要进行的有限数量的验证可能会便宜得多。

让我们比较这两种情况并尝试得出一个结论。

方案1 我们的应用程序假定外部API将按照协议运行。

方案2 我们的应用程序假定外部API可能行为不当，因此增加了预防措施。

通常，任何API或软件都有可能违反协议；可能是由于错误或意外情况引起的。甚至API可能在内部系统中也存在问题，从而导致意外结果。

如果我们编写的程序假设外部API将遵守协议，并避免添加任何预防措施；谁将面对这些问题？将会是我们，编写集成代码的人。

例如，您选择的空值。说，根据API协议，响应应为非空值；但是如果突然违反了我们的程序，则会导致NPE。

因此，我相信最好确保您的应用程序具有一些其他代码来解决意外情况。

您应该始终验证传入的数据（用户输入或以其他方式输入），因此当从此外部API检索的数据无效时，应该有适当的流程来处理。

一般而言，组织外系统相遇的任何接缝都应要求进行身份验证，授权（如果不是仅通过身份验证简单定义）和验证。

通常，是的，您必须始终防止输入错误，但是根据API的类型，“保护”的含义有所不同。

对于服务器的外部API，您不希望意外创建崩溃或破坏服务器状态的命令，因此您必须避免这种情况。

对于诸如容器类（列表，向量等）之类的API，抛出异常是一个很好的结果，损害类实例的状态在某种程度上是可以接受的（例如，提供有错误的比较运算符的分类容器将不可接受）排序），即使使应用程序崩溃也可以接受，但是损害应用程序的状态（例如，写入与类实例无关的随机存储器位置）极有可能不会。

提出一个稍微不同的意见：我认为仅使用给定的数据就可以接受，即使它违反了合同。这取决于用法：对于您来说，这一定是字符串，或者只是显示/不使用等。在后一种情况下，只需接受即可。我有一个API，只需要另一个api传递的数据的1％。我不太关心这99％中的数据是什么，所以我将永远不会检查它。

必须在“因为我检查输入不够而出错”和“因为我过于严格拒绝了有效数据”之间取得平衡。

我对此的看法是始终始终检查系统的每个输入。这意味着应该检查从API返回的每个参数，即使我的程序未使用它也是如此。我倾向于检查发送给API的每个参数的正确性。该规则只有两个例外，请参见下文。

测试的原因是，如果由于某种原因API /输入不正确，则我的程序将不依赖任何内容。也许我的程序链接到API的旧版本，该版本与我所相信的有所不同吗？也许我的程序偶然发现了外部程序中从未发生过的错误。甚至更糟的是，无时无刻不在发生，但没人在乎！也许外部程序被黑客欺骗，以返回可能损害我的程序或系统的东西？

测试我的世界中所有事物的两个例外是：

1. 仔细评估效果后的效果：

   • 在进行测量之前，永远不要优化。与实际调用相比，测试所有输入/返回的数据通常花费很少的时间，因此删除它通常几乎没有节省。我仍然保留错误检测代码，但可以将其注释掉，也许是通过宏将其注释掉。

2. 当您不知道如何处理错误时

   • 有时候，有时候您的设计根本不允许处理您会发现的那种错误。也许您应该做的是记录错误，但是系统中没有错误记录。几乎总是可以找到某种方式来“记住”该错误，至少允许您作为开发人员在以后进行检查。错误计数器是系统中的一件好事，即使您选择不使用日志也是如此。

究竟如何仔细检查输入/返回值是一个重要的问题。例如，如果说API返回一个字符串，我将检查以下内容：

• 数据类型是字符串

• 该长度在最小值和最大值之间。始终检查字符串以获取程序可以预期的最大大小（返回太大的字符串是网络系统中的经典安全问题）。

• 相关时，应检查某些字符串中的“非法”字符或内容。如果您的程序以后可能发送该字符串以表示数据库，则最好检查数据库攻击（搜索SQL注入）。这些测试最好在系统边界上完成，在此我可以查明攻击的来源，并且可以尽早失败。当以后合并字符串时，执行完整的SQL注入测试可能很困难，因此应该在调用数据库之前进行测试，但是如果您可以尽早发现一些问题，则将很有用。

测试发送到API的参数的原因是为了确保我能获得正确的结果。同样，在调用API之前进行这些测试似乎没有必要，但是性能却很少，并且可能会在我的程序中捕获错误。因此，在开发系统时测试是最有价值的（但如今每个系统似乎都在不断开发中）。根据参数的不同，测试可能会更彻底或更彻底，但是我倾向于发现您通常可以在程序可以创建的大多数参数上设置允许的最小值和最大值。也许字符串应该始终至少包含2个字符，并且最长不能超过2000个字符？最小值和最大值应在API允许的范围之内，因为我知道我的程序将永远不会使用某些参数的全部范围。