我们曾经报道过，组织明确目标的重要性，所谓的目标就是影响API设计的重要因素之一。本文将阐述第二个重要因素：了解客户。你知道对于战斗机飞行员来说有严格的体重和身高要求吗？考虑到先进技术和重力因素的限制性，要想设计出一种既满足身高5英尺2英尺、体重140磅人的入口又满足身高6英尺5英寸体重300磅人的需求是不符合成本效益的设计原理。

对于应用程序接口(API)的设计也是一样的道理。尽管没有人会拒绝API的潜在客户，但是军方却会告知飞行员他不是很适合飞行工作。要想争取更多的客户、获得更多的能力支持，那么你就要进行更多的投资。

让我们从回答一个基础问题开始：消费者喜欢尝试那种活动呢？

尽管这个问题很简单，但是却常常被人误解或者失之交臂。人们经常会陷入“如何实现服务”和“需要实现哪有服务”的误区之中。而且，客户不应该知道组织内部数据库结果或者API是否由遗留系统、打包应用程序、Node.js程序所支持。

首先，从客户的角度出发，了解他们需要执行的操作，这一点是很重要的。在《A Practical Approach to API Design》一书中，作者D. Keith Casey Jr.和James Higginbotham用一个章节的篇幅介绍了CRUD（创建、读取、更新和删除）设计领域的超越。通过对客户所期望的操作和目标的研究，我们可以将重点放在‘客户想要实现什么功能’的研究上，而不是放在‘API如何完成任务’的研究上。

以上的研究重点很可能形成一种英语术语，构成一种动名词结构，例如‘提供服务器’或者‘订购’。有一点是非常重要的，那就是我们要清楚地意识到，资源（信息）以及各种操作都是要满足客户实现目标的需求。不要立即就想出一种基于操作的方法，因为该方法会导致SOAP服务器与分布式对象根之间产生问题。了解客户是一项分析任务，该任务唯一的目标就是提供API设计所需要的决策信息。

Casey和Higginbotham书中所写的内容完全超越了CRUD的范围，他们将重点放在研究客户实现目标的交互行为上。如订购这样的任务听起来很简单，但是，在完成订购任务之前我们却要先完成一些列的其他活动，并且，在此阶段API需要支持所有相关活动。这就是API设计所面临的真正挑战，因为，大多数企业都还没有像亚马逊一样设计出一种满足所有活动API。接受现实吧，当我们处在内部专用环境中时，API设计方案更多时候是错误的。在此给出一条重要的建议：在设计API时，假设所有客户都处在外部环境中。

为什么这条建议非常重要呢？因为，内部环境下，API设计非常容易走捷径。有些时候，这些捷径是合理的，但是每一种捷径都有隐含成本。捷径通常意味着要放弃抽象处理，从而导致要设计更多的紧耦合系统。对于新成员来说，这是一种阻碍。因此，首先选择外部环境，才能设计出最佳的API方案。

• 验证所有元素：我们要对API的所有属性提出疑问。真的需要将这些信息保留在防火墙中吗？客户真的需要对所有这些参数进行详细的说明才能使之奏效吗？
• 不走捷径：除非通过API公开，否则这些外部系统式无法访问任何其他系统。在内部整合系统中，我们很容易走捷径，因为消费系统已经访问过许多其他数据。这很有可能导致不良的抽象服务，同时，新用户将会无法使用该API。
• 无打包设计：外部客户不会在乎该服务是否有主机作为幕后支持、APP服务器中是否包含Java代码或者node.js脚本。坦白地讲，如果API设计中太过明显的呈现出以上内容，那么客户们就应该放弃该企业。
• 可用性：在内部环境中，通过访谈会很容易的弥补API设计和文档的不足。但是对于企业外部人士来说，想要做到以上内容就不是那么容易了。外部API必须是内容充分的并且容易理解的。

要考虑的另外一点是：是由消费者来支付API访问费用吗？完成支付的客户为整个系统引入了一种全新的活力。他们支付的越多，就会产生更多的影响作用。支付内容包含使用量付费方式、订阅付费方式以及定制API付费方式。隐含付费意味着，由于一些其他协议的约束，使得消费者必须访问该服务，但是这些服务是不收取任何费用的。与流行信念相反，当客户支付了访问费用后，获取到坚实可靠的接口就变得相对容易一些。在隐式服务中，客户其实早已支付过相应的费用，同时该客户也将抵制接受所有使其获取信息变得困难的任何事情。在支付案例中，我们需要确定是否所有客户都是平等的条件。会有人愿意为API定制服务支付更多的费用吗？

最后，客户对于API中所使用的技术将会产生一定的影响作用。支持使用网页、智能手机的消费者和支持传统的内部消费者是完全不同的两种状态。前者会引出一种带有HTTP接口的REST服务，正如利用JSON和XML来改变消息负荷一样。而后者可能会引出一种传统的集成方式。