我们与 Arnaud Lauret 进行了交谈，他以 API 达人和《Web API 设计》一书的作者而闻名，以了解更多关于即将举行的 ASC 2021（9 月 28-29 日） 的信息。
Lauret 将于 9 月 28 日星期二太平洋夏令时间上午 11:20 开始进行“利用 OpenAPI 进行 API 设计评审”的演讲。
Lauret 是巴黎 Natixis 的高级 API 架构师，目前帮助从高管到开发人员的每个人理解什么是 API、它们为什么重要以及“如何实现它们”。他通过审查和挑战 API 设计、提供培训和构建 API 设计指南来帮助团队设计其 API。
在您于 ASC 2021 上进行的 API 设计评审演示环节中，您将涵盖哪些 3 个关键 API 设计原则？
内外分离、语义化和一致性。
如果一个 API 仅仅是一个技术连接器，用于访问底层混乱的系统，粗暴地将内部暴露给外部，那么对于使用者和提供者来说都是一场噩梦。在使用者方面，人们会遇到一个复杂的 API，需要很高的专业知识，需要付出很多努力才能完成简单的事情。在提供者方面，您可能需要担心意外后果，例如数据损坏或安全漏洞。
语义化非常重要，在设计 API 时，词语的含义至关重要。选择错误的词语，人们可能无法理解您的意图、API 应该做什么、提供什么价值或他们可以使用返回数据做什么。
最后但并非最不重要的是这三者之一：一致性。设计一个一致的 API 很困难，但它值得付出代价。与世界其他地区保持一致将使开发人员在第一次看到您的 API 时感到宾至如归。在您的 API 之间以及 API 内部保持一致将使开发人员能够轻松地在操作、数据模型或参数之间建立连接，因此他们能够掌握您的 API 而无需过多思考。
API 设计评审可以基于事实而非意见吗？这可能吗？
可以。这并不总是那么容易，但这就是我努力做到的事情。基于毫无根据的意见的 API 设计评审毫无意义。人们并不关心您是否更喜欢蓝色而不是橙色。问题是，在特定上下文中，为什么蓝色比橙色更好。提出的所有内容都必须有合理的解释和事实依据。
拥有指南确实非常有帮助：这些预定义的规则提供了每个人都同意的论据。但指南无法解决所有设计问题，它们仅提供高级指导，总会有更具体的函数/业务问题导致多种可能的方案。每一个都符合指南。但是哪一个是“正确的”呢？您需要找到“事实”来做出决定，您可以利用您对业务规则的了解、未来将会发生的事情等。只要一个解决方案有每个人都同意的有效解释，这就是基于事实的评审。
您将在 ASC 2021 上参加哪些其他演讲，以及原因？
实际上，我希望我能参加所有演讲！有很多有趣的会议，但以下是我最喜欢的 4 场：
- API 服务条款：从创意共享到机器可读性 – Célya Gruson-Daniel，COSTECH & Mehdi Medjaoui：我是一个“机器可读性极客”，我喜欢尝试对非结构化数据进行结构化，因为它简化了机器和人类的工作。将机器可读性引入 TOS 对我来说可能会有重大影响。它可以简化服务提供商之间的比较；作为一个参与招标过程以选择软件解决方案的人，我将非常高兴看到这一点。我相信还有其他完全疯狂的结果。我迫不及待地想参加这场演讲！
- 我们将 OpenAPI 文档引入我们的服务目录。接下来呢？ – Shai Sachs & Zoe Song，Wayfair：我在一家大型组织工作，有许多不同的团队、许多不同的 API，这并不容易。Wayfair 的演讲与我的背景相呼应，他们还将讨论我对 Backstage 开源服务目录感兴趣的内容。
- 寻找衡量 API 设计复杂度的方法 – Stephen Mizell，API 顾问：我帮助人们设计 API，我也设计 API。评估一个设计是否复杂并不总是容易的。有时它只是感觉复杂或简单，我不喜欢那样，仅仅依赖于毫无根据的感觉。我更希望用更具体的东西来支持我的评估，如果可能的话，使用真实的事实。这就是为什么我非常期待 Stephen 在这个主题上发表的讲话。
- 在 API 规范评审中应避免的错误 – Rahul Dighe，PayPal：我已经进行了数百次 API 设计评审。我学到了很多东西，找到了各种情况的解决方案，但有时它们不起作用，或者我可能会遇到全新的情况。这就是为什么我总是对学习他人的做法感兴趣，因为他们可能找到了相同问题的其他解决方案，或者处于完全不同的环境中，面临不同的情况。