公共API中的最佳实践是什么?内部API在同一服务上的最佳实践是什么？

Question

我想了解什么是最佳的行业实践和利弊在以下两个选择：

• 只提供内部API和公共API的单个服务，vs。
• 2个单独的服务--一个用于内部API，另一个用于公共API。

我想补充更多的上下文，因为我知道答案将取决于不同的情况：

• 该产品有许多(>20)服务，其中大部分仅限于内部服务。只有少数(<5)有面向公共端点的。
• 我有一个超关键的服务X，目前只供其余的服务使用，并且没有面向外部的公共端点。
• 我们希望添加与X的目的相关的面向公众的API。(修改相同的数据库和表)。经过一些授权、安全检查和验证之后，面向API的公众将在内部调用X的内部唯一API。

Pros-Cons到目前为止

有了单独的服务，边界b/w、面向公共的服务和内部的唯一服务就清楚地分开了。这带来了安全效益和运行效益，例如单独的费率划分、DDoS保护、服务负载、单独的资源(cpu、内存等)、停机时间不影响X等。然而，它也伴随着额外的运营成本--需要管理的额外服务和增加的公司成本。但是，让同一服务为两个端点服务的成本节约是否比拥有新服务的运营成本还要高呢？对于每种选择，还有哪些其他的优点和缺点？想听听你的想法。

Answer 1

你想要一个API网关。这为您提供了一个工具，它可以使用您想要的任何url向公众公开API，并且在它已经存在的地方具有它的功能。网关负责外部用户的访问，并通过有效的请求。大多数商业网关产品还允许编写一些脚本来进行基本验证，并且可以作为诸如限制公共用户的节流或速率限制等事情的一个单一点。

API网关的存在是为了为内部进程创建一个公共面，它可以使单独的服务看起来是对最终用户的相同服务，或者允许向多个服务发送单个调用。关键是网关基本上是他们的路由请求，而不是做业务逻辑。添加许多特定的验证可能很有诱惑力，但这些验证实际上应该与实际服务保持在一起，只有最基本的检查才能在这里完成，比如数字是编号，或者请求是有效的json。

部署不同版本的后端服务仍然是有意义的，但理想情况下，这可能是允许网关通信量的简单配置差异。这使您能够有一个更完整的分离，如果有关注(您仍然在同一个db，所以它不是完全隔离)，但您确实防止任何复杂性在代码中增长。