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

Question

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

问题是：我们已经为Application A的模型开发了PHP类，如果我们想创建一个API，我们应该： - 重新使用这些类（API的功能太多，太重了......）
- 创建一个带有一些基本功能的PHP类，它接受输入并仅返回原始值（如字符串，数组......非复杂类）
- 创建另一组PHP类，更简单，并且只能由外部应用程序使用（因此只能轻松获取数据）

通常，API是第二种解决方案（例如，与PHP一样使用，而不是作为Web服务使用），但是我发现它太糟糕了，我们做了一个复杂而有用的类模型化，然后我们把它拆开了有函数，字符串和数组。 第三个似乎是我的妥协，但我的一个同事坚持认为这不是一个API。太糟糕了......

您怎么看？

Answer 1

从架构的角度来看，解决方案编号3可能是最好的解决方案。基本上您使用Facade Design Pattern来简化API。因为我现在正在处理它：在Patterns Of Enterprise Application Architecture中，这种方法被描述为service layer，因为你不想暴露任何用户（意味着谁将处理你的API），这是完全有意义的。比实际需要或期望更复杂。

这包括使用最简单的接口和传输对象（原始值，如果它们有意义）。一旦你的Facade通过远程服务（如web服务）被调用，你最终将不得不打破repsonses并请求原始值（数据容器）。

Answer 2

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

Answer 3

创建一些瘦包装器，在原始类上实现更简单的API。不要重新实现包装器中的任何业务逻辑 - 如果任何逻辑发生变化，这会导致您遇到麻烦，因为您肯定会忘记哪个部分被修改而哪个部分没有被修改。保持外部输入/输出简单，如果你需要比字符串更复杂的东西，使用XML或JSON作为结构化数据，但要尽量避免过多的复杂性 - 如果你有两件事要传递两个查询参数可能比一个结构好得多有2个字段。

这就是'Facade'模式。

Answer 4

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

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