PHP中API的最佳实践：函数还是类？

在我的公司，我们开发了一些应用程序。我们必须为一个应用程序（比如应用程序A）创建一个API，以便其他应用程序可以使用它（应用程序its数据）

问题是：我们已经为应用程序A的模型开发了PHP类，如果我们想创建API，我们应该：
-重复使用这些类（API的函数性太多，太重…）
-创建一个包含一些基本函数的PHP类，该类接受输入并仅返回原始值（如字符串、数组……而不是复杂类）
-创建另一组更简单的PHP类，这些类仅设计为供外部应用程序使用（以便轻松获取数据）

通常，API是第二种解决方案（与PHP一起使用，而不是作为web服务使用），但我发现太糟糕了，我们制作了一个复杂且有用的类建模，然后我们将其拆分为函数、字符串和数组。 第三个在我看来是折衷方案，但我的一位同事坚持认为这不是API。太糟糕了

---

您认为如何？

构建一组简化公共API的Facade类。

从体系结构的角度来看，解决方案3可能是最好的解决方案。基本上，您使用的是一种简化API的方法。因为我现在正在处理这个问题：在本文中，这种方法被描述为完全有意义的，因为您不想让任何用户（意味着任何将处理您的API的人）暴露于比实际需要或期望的更复杂的环境中

---

这包括使用最简单的接口和传输对象（原始值，如果它们有意义的话）。只要通过远程处理服务（如Web服务）调用Facade，您最终就必须将代理和请求分解为原始值（数据容器）。

创建一些精简包装，在原始类上实现更简单的API。不要在包装器中重新实现任何业务逻辑——如果任何逻辑发生更改，都会给您带来麻烦，因为您肯定会忘记哪一块被修改了，哪一块没有被修改。保持外部输入/输出简单，如果您需要比字符串更复杂的内容，请使用XML或JSON处理结构化数据，但尽量避免太复杂-如果您有两件事要传递，则两个查询参数可能比一个结构和两个字段要好得多

---

这就是“门面”模式。

我还想说看看门面模式。 构建一组Facade类，这些类只提供真正需要公开的功能。这些类肯定会使用当前的核心类

---

这还为您提供了一个优势，即如果您更改了核心类，则不必更改API。

您的意思是选项3？（我想确认一下，英语不是我的母语）谢谢你，谢谢所有其他人。我来看看这个正面图案，就是这个。