内部和外部API架构

我工作的公司保持着成功的SaaS产品，这些产品多年来“有机地”增长了。我们计划用一系列新产品扩展产品线，这些新产品将与现有产品共享数据。为此，我们希望将业务逻辑整合到一个地方：Web服务层。WS层将由以下人员使用：

• 网络应用
• 导入数据的工具
• 与其他客户端软件集成的工具（本身不是API）

我们还希望创建一个可供我们的客户使用的API，这些客户可以使用该API创建自己的集成。我们正在努力解决以下问题：

内部API（又称WS层）与外部API是否应在同一方面，并​​具有安全性和权限设置以控制谁可以完成操作，还是应该是两个单独的应用程序，其中外部API仅调用内部API像其他应用程序一样？到目前为止，在我们的辩论中看来，将它们分开可能更安全，但会增加开销。

其他人在类似情况下做了什么？

吃自己的狗粮总是很好。即使考虑了身份验证和授权的一些​​开销，一个API的维护也应该比两个API更简单。

尽管我同意Aneurysm9，但有时您不想公开系统的所有功能。在这种情况下，最好有两个API ... 但是， 如果您选择这种方式...请确保所有通用功能共享相同的API，即IE可以是另一个的扩展版本，而不是两个截然不同的版本代码集。

这样，您就可以自己使用自己的空间，同时又可以进行私人的，敏感的，实验性的工作，同时又可以使您发布和使用新内容而无需过多更改公共API。

我之前（很多次）都遇到过这种情况，而最终我喜欢做的是：

将BL移出网站。使网站成为API的使用者。将网站视为API的其他客户端。您的API是服务。

如果您发现自己仅需要用于网站的特殊API方法，请三思！如果它对鹅有好处，对for鱼也有好处。如果您确实确实需要该网站的特殊功能，那么我建议您真正发现的是“用户个人资料”的不同，因此在这种情况下，API仍应支持“特殊”功能，但是您通过授权控制它们。

不服气吗？

进一步走范式...

电话应用程序在执行字节码的平台上运行，该应用程序驻留在电话中并通过HTTP / JSON使用API​​服务

该网站是运行在执行HTML + Javascript的平台上的应用程序，该应用程序位于浏览器中，并通过HTTP / JSON使用API​​服务

彼此彼此！

将其扩展到平板电脑，电视，其他电话平台，插件，第三方应用程序，混搭，...

许多不同的用户体验都插入了通用API。

您的应用是API。该网站只是其中的一个客户

使用一个API

如果您要将服务API实施为REST层，则只需将身份验证添加到受保护的路由即可。

您可能需要使用不会产生太多“魔力”的开发框架。您无需直接进行反向工程即可直接定义路线的地方。

想一些类似Node.js / Express，python / pylons，python / google app引擎等的东西。

我最近在Google App Engine上针对REST /数据存储区API实现了此功能，但我认为这可能再简单不过了。控制器被实现为类，其后续的HTTP请求（即GET / POST / PUT / DELETE）被实现为这些类的方法。我设法实现basic-auth作为装饰器。这使得向请求添加身份验证要求就像附加@basicAuth装饰器一样简单。

这样，我可以使传入的GET请求公开，为该模型在同一控制器上的POST / PUT / DELETE请求中添加身份验证要求。

如果您知道如何用REST说话，那么生活就会变得更加轻松，因为REST支持已经固有地嵌入到任何Web服务器中（即HTTP只是REST API的一种）。如果要通过网络发送大量数据，甚至可以选择透明的gzip压缩。

我的第一印象是它应该是相同的API，并且您的安全性应该完全在不同的层上。也许由网络前台处理？