如何为我的插件创建API？

我一直在为WordPress开发插件，我开发的大多数插件使用两到三个类，因此不如Buddypress或WooCommerce大。

我计划开发两个开源插件来交付某种复杂的系统（目前无法共享详细信息，但稍后在开发过程中），其他开发人员可以自定义功能，并且其系统必须与Bud​​dypress和WooCommerce相同。

当我检查这些插件文件并意识到它们已经注册了自己的操作和过滤器时，开发人员可以根据需要进行修改。但是，我的问题是无法完全理解，我该如何编写一个插件，让其他人可以灵活地覆盖功能以及添加自己的功能。

我知道很难给出确切的答案，但是我需要某种入门指南，以便朝正确的方向前进。我需要注册自己的操作和过滤器吗？如果是，怎么办？如果不是的话，我有什么选择？

您的建议将对我有很大帮助。

您在插件或主题中提供的API取决于该特定代码的逻辑。可能没有适用于所有情况的指南。

我是使用API​​的多个插件的贡献者，到目前为止，我了解到的是：

1. 在您真正了解人们如何使用您的代码之前，请不要提供API。

   不使用任何API发行前两个或三个版本。如果可能的话，没有自定义操作或过滤器，没有公共方法或函数（也从没有任何全局变量）。等待用户的请求，但是不要添加代码，直到您知道内部代码结构可以长期运行为止。

   保持API的向后兼容性很困难。这可能会阻止在其他地方进行必要的改进。考虑一下WordPress现在无法删除的所有全局变量。那是一个不好的API，我们已经坚持了很多年，因为人们已经在使用它。

2. 考虑将您的API与其余的代码分开（有关想法，请参见前面的链接）。
   您的API应该不仅对第三方开发人员有用，而且对您也有用。如果没有必要，不要为自己添加限制。

3. 吃自己的狗粮。
   如果提供自定义钩子，请在代码中使用它们。这将为其他开发人员提供有用的示例，并且您会尽快发现可能的缺陷。
   如果WordPress核心在内部使用所谓的Settings API，那么今天我们就不会陷入混乱。也许。

4. 以身作则。
   在插件中使用WordPress核心API的优秀部分。避免使用匿名对象，常量，全局变量和任何类型的不可预测的代码。

5. 确保您使用一致的命名方案（而不是一团糟），并将所有内容放在您自己的名称空间下。

6. 首先编写文档。稍后发布新的（一部分）API。
   为所有内容创建有用的示例。您会惊奇地发现您会发现多少孔和冗余。

7. 避免回调地狱。
   当无法正常工作时提供特定的工具来调试您的API（包括未缩小的脚本和样式表）。我已经写了一个有关如何调试AJAX的示例，只是为了说明您在这里的创造力。同样，在发布它们之前，应在文档中对这些工具进行说明。

8. 观察者模式可以替代WordPress的回调范式。这将为第三方开发人员增加障碍，但可能会导致双方都有更好的代码。