【问题标题】:Best practice - Calling APIs & Services in Single page applications最佳实践 - 在单页应用程序中调用 API 和服务
【发布时间】:2017-06-19 21:57:06
【问题描述】:

我有一个需要调用各种网络服务和/或 API 的单页应用程序。我想了解从 SPA 进行 api 或服务调用的公认方法是什么。我们目前有两种方法

  1. 对于某些第 3 方 API,我们在没有服务器端代理的情况下从单页应用程序直接调用。为了使它工作,我们启用了 CORS。

  2. 对于其他 API 调用 - 我们调用代理(包装器),该代理负责将它们重定向到适当的端点。

我们决定使用哪种方法的方式是 - 如果在调用第 3 方 api 之前需要进行某种数据操作 - 我们使用代理 - 否则我们从 SPA 直接调用。这是一个有效的方法。如果从安全的角度来看,第一种方法是否稳健,您是否有任何反馈?在第一种方法中,我们有一个仅限 http 的 cookie,它被用作访问令牌来调用 3rd 方 api。这是否会使我们暴露的 API 易受攻击?

提前致谢

【问题讨论】:

    标签: architecture single-page-application microservices


    【解决方案1】:

    我强烈建议您代理所有 API 调用。

    在某些用例中调用 3rd 方 API 是可以的,但如果您开始不得不处理大量此类情况,则不能。

    以下是我的重点:

    • 接口 API 允许集中列出、组织和更新第 3 方 API。它还可以让您更轻松地构建自己的跟踪、统计和监控。
    • 如果任何 API 出现故障,您可以重新路由它,并提供足够的错误处理,以避免由于第 3 方 API 出现故障而让您的客户感到沮丧的超时/丑陋的错误消息
    • 您将客户与外部服务隔离并保护:是的,如果恶意用户利用了第 3 方 API(例如:返回“不良”图片、重定向导航...),您可以对其进行过滤。李>
    • 为您的 API 代理更改一个主机名很容易,但更改更难 20. 如果您想将您的应用程序迁移到封闭环境(私有网络)中,API 代理将成为真正的帮手DNS、代理、网关等问题。
    • 您可以提供自己的标准化 API 来连接所有其他 API:这将成为开发的加速器。看看 GraphQL 是否可以帮助您执行多 API 调用和结果大小优化。

    【讨论】:

    • 感谢您的回复。我应该更清楚——我所说的第 3 方 API 并不完全来自第 3 方——它们是我的团队无法控制的内部组织 API——因此我称它们为“第 3 方”。但我同意你提出的所有要点。
    猜你喜欢
    • 2015-06-06
    • 1970-01-01
    • 1970-01-01
    • 2010-11-03
    • 2013-03-13
    • 1970-01-01
    • 2012-09-13
    • 2014-05-14
    • 2012-06-21
    相关资源
    最近更新 更多