插件或主题中提供的API取决于特定代码的逻辑。可能没有适用于所有情况的指南。
我是多个API插件的贡献者，到目前为止我学到的是：
在您真正了解人们如何使用您的代码之前，不要提供API。
在没有任何API的情况下发布前两个或三个版本。如果可能的话，没有自定义操作或过滤器，没有公共方法或函数（也从来没有任何全局变量）。等待用户的请求，但在知道内部代码结构将长期运行之前，不要添加代码。
Maintaining backwards compatibility of an API is hard. 这可能会妨碍其他地方进行必要的改进。想想WordPress现在无法删除的所有全局变量。这是一个糟糕的API，我们多年来一直在使用它，因为use it already.
考虑将API与代码的其余部分分开（请参见上一链接了解想法）
您的API不仅对第三方开发人员有用，而且对您也有用。如果没有必要，不要给自己增加限制。
吃你自己的狗粮
如果您提供自定义挂钩，请在代码中使用它们。这将为其他开发人员提供有用的示例，您可以很快看到可能的缺陷
如果WordPress核心在内部使用所谓的设置API，我们今天就不会有这种混乱。大概
以身作则
在插件中使用WordPress核心API的好部分。避免anonymous objects, 常量、全局变量和任何类型的不可预测代码。
确保使用一致的命名方案（不是such a mess), 并将所有内容放在您自己的命名空间下。
首先编写文档。稍后发布新的（部分）API
为所有内容创建有用的示例。你会惊讶地发现有多少漏洞和冗余。
避免回调地狱
当事情不能正常工作时，提供特定的工具来调试API（包括未缩小的脚本和样式表）。我写了一个例子来说明如何debug AJAX, 只是为了说明你在这里的创造力。同样，在发布这些工具之前，应该在文档中对其进行解释。
WordPress回调范例的另一种替代方法是Observer pattern. 这将为第三方开发人员设置障碍，但可能会在双方产生更好的代码。
