我发现在本周的几次讨论中,人们谈到了一个正在开发中的Web应用程序是否应该利用正在创建的API。
情况是这样的:我有一个使用MySQL DB的PHP MVC Web应用程序,还有几个移动应用程序正在内部开发。对于移动应用程序,我们正在构建一个REST API。重要的问题是,为什么我的PHP Web应用程序现在要使用那个REST API呢?我一直认为API的使用是为第三方系统与我的数据库进行接口交互或者为使用不同技术构建的系统服务。Web应用程序肯定不是第三方系统,而且服务都是使用PHP编写的。如果API位于不同的服务器上,则可以将其视为第三方系统...但这尚未决定。
对我来说,似乎很奇怪为Web应用程序利用API,特别是由于API的服务将仅限于Web应用程序中50%的功能,而另外50%则是独特于Web应用程序的。我还预见到通过服务层步进而不是直接访问数据库,Web应用程序会受到性能影响。另一方面,我看到维护代码库以使Web应用程序访问数据库和类似函数内置于移动应用程序的API方便得多。
是否有人遇到过类似的情况,并可以提供一些技术上的优缺点,说明为什么我应该使用API,或者可以指向一个可靠的案例研究?
情况是这样的:我有一个使用MySQL DB的PHP MVC Web应用程序,还有几个移动应用程序正在内部开发。对于移动应用程序,我们正在构建一个REST API。重要的问题是,为什么我的PHP Web应用程序现在要使用那个REST API呢?我一直认为API的使用是为第三方系统与我的数据库进行接口交互或者为使用不同技术构建的系统服务。Web应用程序肯定不是第三方系统,而且服务都是使用PHP编写的。如果API位于不同的服务器上,则可以将其视为第三方系统...但这尚未决定。
对我来说,似乎很奇怪为Web应用程序利用API,特别是由于API的服务将仅限于Web应用程序中50%的功能,而另外50%则是独特于Web应用程序的。我还预见到通过服务层步进而不是直接访问数据库,Web应用程序会受到性能影响。另一方面,我看到维护代码库以使Web应用程序访问数据库和类似函数内置于移动应用程序的API方便得多。
是否有人遇到过类似的情况,并可以提供一些技术上的优缺点,说明为什么我应该使用API,或者可以指向一个可靠的案例研究?
app()->service->doSomething()
),只需要在顶部添加一个薄层,以便将功能公开为 HTTP API。 - Marty