我应该使用curl来消费我自己的api吗?

问题描述:

我正在构建一个Web应用程序,它将为我的几个客户端网站提供支持。它还涉及一个其余的API。让我的客户的PHP网站使用curl消费API而不是直接调用我拥有的PHP代码是明智的做法。我被告知这会让部署变得更容易,特别是对于那些网站不在我的服务器上的客户,但我看不到这样做的好处。另外,我被告知这将有助于保护我们的代码,同样我也没有看到它的好处,因为客户端只能访问基本的活动记录模型。 我没有使用卷曲的问题。我的问题是,目前我所有的客户端网站都托管在我的服务器上,我认为请求到达服务器只是为了让服务器向自己发送一个curl请求来填充请求,这并不是很有效。 任何意见是不胜感激。我应该使用curl来消费我自己的api吗?

+1

创建一个系统,您也可以使用自己的API,这是完全正确的。此类解决方案具有可扩展性,您可确保潜在客户使用您也使用的标准化API。但是,正如您可能已经注意到的那样,这更多的是设计问题而不是直接编程问题,所以它可能因为偏离主题而被关闭。 –

+1

类似Programmers.SE:[我应该使用自己的公共API用于我的Web界面吗?](http://programmers.stackexchange.com/questions/302028/should-i-use-my-own-public-api-for -my-web-interface) – HPierce

+0

Curl是很好的,可能更好的是为你的客户提供围绕API调用的包装库。这样用户就不必知道API的机制,如果您必须做出重大更改,您可以更新包装器,而不是让所有客户端更改依赖于您的API的代码。 –

我认为这是一个很好的模型,即使你得到了两次调用PHP的开销。那开销是真的!然而,一种选择是,如果你的API运行良好,并且你已经正确地使用请求/响应对象构建它(而不是直接依赖全局变量,超全局变量,php://输入,头()等),那么你也可以创建一个'虚假的HTTP客户端',它只是在本地调用相同的PHP代码。

+0

所以基本上,我的客户的网站应该能够使用本地代码,如果不可用,它调用API? –

+0

不,我认为从客户端网站的角度来看,它应该看起来和感觉像是一个HTTP请求,而实际上你模拟请求/响应对象'假装'来发出HTTP请求,但实际上是设置你的API来源并做一个本地电话。 – Evert

+1

如果这对你没有任何意义,只需在一年内发生性能问题时发出真正的HTTP请求并发表评论;) – Evert