API设计的七宗罪( 三 )


大多数JSON方法都需要API密钥才能访问帐户 。可以在菜单>>帐户>>帐户访问中设置API代码 。
除了上面关于身份验证的沟通不畅之外,API密钥实际上是用户需要自己创建的东西(实际上是手动键入密钥,绝不自动生成),并且其长度应在16到64个字符之间 。允许用户自己创建密钥可能会导致非常不安全的密钥(很容易猜到)或某些格式问题,因为可以在帐户设置的该字段中输入任何字符串 。在最坏的情况下,它也可能成为SQL注入或其他类型攻击的门户 。请不要让用户创建API密钥 。始终为他们提供不可变的自动生成的密钥,并能够在需要时使其无效 。
对于那些实际经过身份验证的请求,我们有一个不同的问题:身份验证令牌必须作为请求主体的一部分发送,如下所示(从文档中可以看出):

API设计的七宗罪

文章插图
Beds24 API authentication example
在请求正文中包含身份验证令牌意味着服务器将需要首先解析请求正文,提取密钥,执行身份验证,然后决定如何处理请求:是否执行请求 。如果成功通过身份验证,则不会涉及任何开销,因为无论如何都将解析该正文 。万一验证失败,服务器将完成上述所有工作,只是提取令牌,从而浪费宝贵的处理时间 。相反,更好的方法是使用Bearer身份验证方案或类似方法将身份验证令牌作为请求标头发送 。这样,服务器仅在成功认证的情况下才需要解析请求主体 。使用诸如Bearer令牌之类的标准身份验证方案的另一个原因仅仅是因为大多数开发人员都熟悉它 。
罪过7:性能最后但并非最不重要的一点是,请求完成平均需要1秒钟多一点的时间 。在现代应用中,这种延迟可能是不可接受的 。因此,在设计API时要考虑性能 。
 
尽管上面解释了API的所有问题,但它确实可以完成 。但是,对于开发人员来说,理解和实现它需要花费数倍的时间,并且需要花费大量时间来编写更复杂的解决方案以解决琐碎的问题 。因此,在发布API之前,请考虑让开发人员实现您的API 。确保文档完整,清晰且格式正确 。检查您的资源名称是否遵循约定,数据结构是否正确,易于理解和使用 。另外,请注意安全性和性能,不要忘记正确执行错误处理 。如果在设计API时将上述所有因素都考虑在内,那么就不需要像前面的示例中那样奇怪的"准则" 。
如前所述,这篇文章的目的不是让您永远不要使用Beds24或任何类似的系统,因为它们的API没有正确实现 。目标是通过分享一个不好的例子并解释如何更好地完成软件来提高软件产品的质量 。希望这篇文章可以使某人更多地关注软件开发最佳实践,并使软件系统更好 。直到下一次!
 
(本文翻译自Robert Konarskis的文章《How NOT to design APIs》,参考:https://blog.usejournal.com/how-not-to-design-restful-apis-fb4892d9057a)




推荐阅读