第 5 章. 设计实践
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
现在,我们已经提供了有关 API 范例、安全性和最佳实践的指导,是时候进行设计 API 的实践练习了。 在本章中,我们将介绍本书第一部分所涉及的所有内容,并使用一个虚构的示例来探讨不同的注意事项。
此外,我们还将深入介绍如何创建有效的设计流程,以便您能够自行设计应用程序接口(API),无论您的用例是什么。
在本节中,我们将重点关注用户体验,以此作为设计决策的基础。今天的消费者习惯于卓越的产品体验,以满足他们的需求和生活方式,而不仅仅是完成工作的产品。这种对体验质量的高要求不仅限于人们购买的产品。它还延伸到他们使用的应用程序,以及他们在使用应用程序接口时所期望的开发人员体验。
我们可能在构建业务和公司,但我们不会为自己设计应用程序接口。我们为接收数据的系统设计应用程序接口,更重要的是,我们为构建这些系统的人设计应用程序接口。如果这些开发人员无法使用我们提供的数据,那么我们最终就没有创造出有用的设计。
在下面的章节中,我们将通过两个不同的场景来探讨如何开始以用户为中心的设计过程,以及如何在设计过程中获得反馈。设计方法有很多,以下流程只是一个起点框架。这种特定方法最重要的一点是,它旨在以一种能让 API 用户最终受益的方式征求反馈意见。
如果您想用自己的例子来说明,不妨使用附录 A。
情景 1
为了让我们从一个实际的例子开始,下面是一个简单的虚构场景,我们将用它来完成本章的第一部分 :
你是一家名为 MyFiles 的快速发展的图像存档初创公司的首席工程师。公司的主要产品允许个人用户和公司私下存档数据。现在,新用户和大量归档元数据源源不断,您和团队认为创建和发布 API 大有可为。作为首席工程师,你的任务是在下个季度推出新的 API。
确定业务目标
在开始编码或编写 API 规范之前,请花点时间问自己两个问题:您想解决 什么问题?这两个问题的答案必须关注用户的需求以及您创建的业务。
对第一个问题的回答应该简明扼要,可以放在任何产品或技术规格书的最前面。其中应包括问题如何影响或涉及客户和企业的信息。
第二个问题的答案应该定义您的 API 成功的样子。它应该说明您希望从使用您的 API 的开发人员那里看到的理想行为。
越早提出这些问题,就越能做出明智的设计决定,从而实现自己的目标。
下面的边栏演示了问题和影响声明对新的 MyFiles API 的影响。
在这些声明中,提到了三个 关键方:
-
MyFiles 业务
-
客户
-
构建第三方集成的开发人员
虽然三方关系适用于 MyFiles 应用程序接口,但对于其他业务,问题和影响声明中涉及的唯一方可能是公司和开发人员,他们也是客户。使用问题和影响声明明确定义 API 用户。
完成上述工作后,请确保公司的其他利益相关者保持一致。对于将构建或使用此 API 的各方来说,理解其试图解决的问题非常重要。不匹配的期望会导致日后的冲突,进而演变成不一致或矛盾的 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access