Stripe 原生 PHP 库与使用普通 cURL 的比较

Question

因此，我即将对我们的一个项目实施条纹支付，我已经阅读了他们的 API 文档，其内容如下：

Stripe API 是围绕 REST 组织的。我们的 API 设计为具有可预测的、面向资源的 URL，并使用 HTTP 响应代码来指示 API 错误。我们使用内置的 HTTP 功能，例如 HTTP 身份验证和 HTTP 动词，这些功能可以被现成的 HTTP 客户端理解，并且我们支持跨域资源共享，以允许您从客户端安全地与我们的 API 交互Web 应用程序（尽管您应该记住，您永远不应该在任何公共网站的客户端代码中暴露您的秘密 API 密钥）。JSON 将在来自 API 的所有响应中返回，包括错误（尽管如果您使用 API 绑定，我们会将响应转换为适当的特定于语言的对象）。

他们为流行语言提供了一套很好的即用型 API 库，因此您可以将它们导入您最喜欢的语言，然后开始使用他们的 API，包括 PHP，这就是我们在这个项目中使用的 API。

现在，他们的 API 很大并且有很多对象。我们实际上并不打算使用整套功能，因此我最初的想法是仅将其 HTTP RESTFul 接口包装在简单的 cURL 代码周围，这样我就不必为了性能而加载其整套类。

现在，在我实际围绕他们的 HTTP API 实现我自己的 cURL 客户端之前，我花了几分钟查看他们的 PHP 库的源代码，他们似乎正是这样做的：包装 cURL 函数、抛出错误、公开对象化响应等。

那么问题是：即使我知道我将加载很多我不会使用的类，是否值得只使用他们的库，或者我应该用 cURL 围绕他们的 REST API 编写自己的包装器？

考虑到这个问题出现在我的脑海中，因为我们正在使用其他服务（例如 TangoCard），并且它们中的大多数都已弃用“本机”库，转而使用您最喜欢的 HTTP 客户端库，而只使用 REST API。

谢谢！

Answer 1

就性能而言，加载类几乎不是问题，尤其是在使用 APC 时。我认为使用他们为您提供的内容所节省的时间完全证明了由于加载他们的类而导致的轻微性能损失。

但是，如果他们的代码编写得很好，您就不应该加载任何您实际上不使用的类。

此外，如果他们维护自己的库，随着时间的推移，接收更新将会更容易。例如，我们曾经推出自己的 Facebook API，该 API 使用了curl，但由于随着时间的推移，它们的更新数量和重大更改而不得不停止。