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

【问题标题】：Best practices for an API in PHP : functions, or classes?PHP 中 API 的最佳实践：函数还是类？
【发布时间】：2010-02-18 16:26:33
【问题描述】：

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

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

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

你怎么看？

【问题讨论】：

标签： php api function model class

【解决方案1】：

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

这包括使用最简单的接口和传输对象（如果有意义，则为原始值）。一旦通过远程服务（如 Web 服务）调用您的 Facade，您最终将不得不将响应和请求分解为原始值（数据容器）。

【讨论】：

谢谢你，也谢谢所有其他人。我来看看这个 Facade 模式，就是这样。

【解决方案2】：

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

【讨论】：

你的意思是选项3？（我想一定要明白，英语不是我的母语）

【解决方案3】：

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

这就是“门面”模式。

【讨论】：

【解决方案4】：

我还想说看看 Facade 模式。构建一组仅提供真正需要公开的功能的外观类。那么这些类肯定会使用你当前的核心类。

这还给您带来了好处，即如果您更改核心类，则不一定要更改 API。

【讨论】：