关于许多供应商未能理解的事情是，这个“我需要我所需要的而你提供的或者你不需要”的方法同样适用于企业开发者。虽然大多数企业对企业（B2B）供应商（包括硬件和软件）都明白需要提供一个有用的，通常易于学习的用户界面或命令行，但这种理解往往不能扩展到API。
                                              

        有一种“我们都是开发者在这里”的心态，这是真的，但是开发者有不同的优先级。正如大多数最终用户不会使用记录不完整，非直观和复杂的应用程序一样，大部分企业开发人员也是如此。他们有一个目标，正在努力完成他们的工作，如果你的API正在放缓他们的工作或加大他们的工作，他们将寻找替代方法来实现他们的目标。

         肯定会有一小部分人深入挖掘和学习API，不管它有多混乱和无证，因为各种各样的原因，从获得极客的信誉到项目需求的要求。但是，如果给出一个选择，绝大多数开发人员将寻求一种更简单的方式来做需要做的事情。他们有时间表和截止日期，不会让文件不佳等干扰这些要求。API的稳定性和可预测性是必不可少的，没有这些工具将不会被使用。但是，没有文档和直观的设计，可预测的类型，请求，响应等，许多开发人员甚至不会到达稳定部分。当工具无法在可用时间内找到时，稳定性就完全不相干了。

 那么你需要什么？

1. 凝聚力的设计。大多数API随着时间的推移而增长，但是他们需要遵守API文档所设定的标准，这样开发人员就不会浪费时间去做“这里完全不同的东西......”变体需要被清楚地记录下来。
2. API参考。帮助开发人员了解如何进行API调用的快速参考，参数是什么，响应是什么，支持的标准以及使用API​​的要求。
3. 一个完整的“如何设置”。包括使用API​​所需的东西的清晰文档。开发人员不关心你是不是写了部分工具集 - 他们期望的 - 但是你最好给他们提供他们需要的所有信息来配置他们的开发环境，包括你没有写的部分。这是你的 API，记录所有的步骤，使其工作。
4. 样品。不是“Hello World”级别，虽然属于API，但真正的用例样本深入研究，最好是逐步进行，以便开发人员无需打开防火墙即可学习。
5. 输入/输出样本。在SOAP / REST API的世界中，有时您只需要看看最终请求的外观需要什么样，以及响应文档中的内容。
6. 高级API。你的开发人员越是单一，他们越愿意将每一个微小的操作公开给你的产品，就可以把它作为一个单独的API来使用。但老实说，企业开发人员不想打50个电话来做一件行业共同的事情。浪费时间编码，浪费网络带宽，使应用程序更加迟钝。要使用我的实用程序根目录，如果“读取计量器”是命令，那么开发人员想要告诉API。他们没有（也不应该）关心需要采取多少步骤，他们希望工具集“做到这一点”。这并不是说用户不想访问一个流程的各个步骤，只需要一个调用来实现一个业务功能。如果你没有业务层，就去写一个。现在。
7. Rockstar支持。说真的，如果你想让人们使用这个工具，那么你必须给他们一个获得可靠答案的方法。诸如StackOverflow之类的地方对于大量用户来说都是非常棒的，但对于高度专业化的API来说却并非如此。所以你必须在社区提供技术支持，无论哪种方式最好，但是当卡住的时候，人们需要回答他们的问题，而不是通过文档来查找，希望找到一些模糊的参考。
8. 沟通和不断的反馈。通过社交媒体，博客，聚会，任何东西，并谈论API的变化，一些客户已经发现的API的新用途，内联固定的错误和解决方法是非常重要的。用户希望得到通知，对API的沉默意味着缺少对未来的支持 - 无论这种含义是否准确，都是被感知的。而反馈是最好的改进想法来自哪里。刚刚通过API实施而苦苦挣扎的人，对于什么可能会更好有独到的见解，需要一个沟通机制来提出这些建议。与此同时，那些花了几年时间就可以使用API​​的人可能会比原来分析人员更了解设计的实际意义。同样，需要一个反馈机制。

最后，API的要点是让人们使用它。投资API，把它看作是一个产品，即使在你的商业案例中，它是一个功能，而不是产品。它是为了一个原因而开发的，给它提供了使这个原因真实的工具。