嵌入式插件的兴衰：嵌入式框架的API

虽然了解 iframe 的替代方案很重要，但 iframe 仍然是成功嵌入框架的一种有价值且常用的方法。即使考虑替代方案，iframe 也有助于了解可能性，以及成功平台需要考虑的设计和技术细节。

嵌入框架的意义远不止让合作伙伴出现在您的界面中。更好的框架不仅通过将合作伙伴定位在界面中经过深思熟虑的位置来实现深度集成，而且还通过提供专门用于这些嵌入式集成的 API 来实现深度集成。

除了支持嵌入式集成和提供 API 访问之外，更好的框架还具有 API、事件触发器和其他功能，让合作伙伴集成真正在环境中进行交互。

入门：让应用程序知道它们适合放在哪里

回顾 iGoogle、Facebook Canvas 和 OpenSocial 的“旧时代”，嵌入框架提供商至少知道要确保合作伙伴能够轻松识别其界面中可访问的位置，以便他们能够在正确的时间显示正确的体验。

对于 Facebook 和 LinkedIn（OpenSocial），应用程序可以在用户个人资料的一小部分区域内显示，而且还可以拥有从侧边栏访问的自己的“应用程序页面”，并拥有更多空间来显示不同的体验。

此类应用的开发人员习惯于在清单文件中指定（尽管不一定）其应用可显示的不同界面，并指定要加载的 URL 或要运行的代码。这种情况仍然很常见，只是清单符合较新的 API 标准（基本上是 JSON 文件，而不是旧的 XML）。

"location": {

  "support": {

    "ticket_sidebar": "assets/iframe.html"

  },

  "chat": {

    "chat_sidebar": "assets/chat_iframe.html"

  }

}

本质上，平台提供商必须让开发人员知道他们在 UI 中的位置，并指定相应地加载什么内容。

更具创造性：API 与界面交互

iframe 提供了一定的安全性，因为它们无法与父页面进行太多交互。也就是说，没有父页面的许可。当我们希望合作伙伴在框内执行更多操作，而不仅仅是在我们的页面中显示某些内容时，我们会提供额外的 API 来获取有关嵌入合作伙伴应用的页面的信息，甚至通过使用触发 UI 中某些内容的函数与页面进行交互。

例如，Gmail 附加组件允许应用程序查看发件人的信息和邮件文本：

// Setting the access token with a gmail.addons.current.message. readonly

// scope also allows read access to the other messages in the thread.

var thread = message.get Thread () ;

var threadMessages = thread.getMessages () ;

// Using this link can avoid the need to copy message or thread content

var threadLink = thread.getPermalink();

使用 SDK 让开发更简单

平台可以通过在这些 API 之上提供额外的工具来简化嵌入式集成。首先，Javascript 库可以让合作伙伴用更少的代码调用以嵌入为中心的 API。这是嵌入框架最常见的功能之一，通常被认为是在允许基本 iframe 之后要构建的下一个功能。

Zendesk、Trello、Shopify和Twitch只是这些客户端库的几个例子。在提供 iframe 功能平台时，它们非常常见，几乎是意料之中的事情。

这些库还有助于讲述一个故事，即构建完全在客户端运行的简单应用程序。与界面或核心平台后端交互的 API 仍然可以从前端制作，由 JavaScript API 库支持。然后，合作伙伴可以使用 HTML、CSS 和前端 JavaScript 创建简单的应用程序。

事实上，此类应用程序可以轻松安全地托管在平台本身上，而不是由第三方开发人员托管。虽然当今许多平台都托管合作伙伴的服务器代码，但托管客户端代码是一个简单的开始。

服务器端要求

有些平台不仅允许通过完全在客户端操作轻松构建小型应用程序，但有时这根本不可能。在企业软件中，合作伙伴当然会托管和运行后端操作。即使在 K-12 教育技术中，我也管理了一个需要许多 API 调用在服务器到服务器之间进行的平台。合作伙伴在线提供数学和语言游戏，供学生尝试，并将成绩提交到课堂成绩册。提交成绩的调用必须在服务器端进行，否则精通技术的学生可能会找出 API 调用并在英语课上作弊。

Twitch 专注于这种场景，在客户端和服务器端库之上提供了附加工具。

安全相关事项：API 范围

为了实现这些更深层次的集成，需要专门为这些嵌入式集成设计的新 API 功能。新 API 带来了更多责任。这些 API 端点的作用域与其他 API 的工作方式往往大不相同。

对于与 Google Drive 连接的移动应用程序，可能需要完全访问用户的 Google Drive 帐户，以便创建文件夹、上传文件、共享文件夹等。但是，如果嵌入 Google Drive 中仅与一个文件交互，这有必要吗？对于 Google Drive，最好将集成限制为仅与用户选择的文件一起使用。

Google Drive 一直在更新其 API，以便仅用于文件的集成不会请求超出其需求的范围。现在，每次用户将文件启动到第三方服务时都可以创建新的令牌，从而使第三方只能访问用户刚刚启动的文件。

如何跳过 API 身份验证

iframe、API 和库看起来足够简单，但请记住，可用性很重要。平台经常会忽略一个点。这是一个常见的点，公司经常需要后续更新：身份验证体验。

如何让合作伙伴能够访问用户的帐户？最新的 Oauth 标准是最有可能的解决方案，但它往往没有得到应有的实施。平台经常将用户引导出其界面，迫使他们转到合作伙伴，登录，再次通过 Oauth，才能访问集成。

您的用户体验不必如此！从流程来看，用户更有可能在集成目录中找到这些应用。找到后，他们将（或可以）登录到帐户 – 准备批准应用。在这里，让他们简单地“添加”应用，然后在您的界面上通过正确的 Oauth 提示，怎么样？

当然，许多合作伙伴也需要访问他们的 API。这可以由应用程序在首次启动时处理，或者理想情况下，通过同一体验上的重定向来处理。在清晰的“安装”流程中，一次性体验即可让用户开始使用。

合规性注意事项

一些企业公司不愿启动 iframe 集成，并指出他们正在尝试实现 HIPAA 和 FINRA 合规性，这需要集成合作伙伴服务。一些平台主机告诉我，出于这个原因，iframe 是不可能的。

Salesforce 遇到了这种情况，但采取了一种简单的方法，即为需要 HIPAA 的客户禁用所有集成。显然，有办法解决合规性问题，同时仍然允许第三方嵌入式集成。

除了完全阻止某些客户的合作伙伴之外，还有更自由的选择。或者，平台提供商可以标记哪些集成服务具有某些认证。当客户需要 HIPAA 认证时，所有未经认证的 Hipaa 集成都无法访问该帐户。

如果行业重视合规性，那么在平台的早期规划阶段就需要了解这一点。好消息是，这个问题很容易解决。

超越 iFrame

在考虑用例并应用良好的设计原则后，iframe 可以实现非常引人注目的平台。一旦与正确的 API 和实施规则相结合，这样的平台就可以很好地适应客户，并扩展到数百个集成。

尽管过去曾有过无数的挣扎和伤痕，但只要正确使用，iframe 仍然很有价值。尽管如此，它们并不总是最好的解决方案。在了解了 iframe 和良好嵌入框架的设计原则之后，了解平台在尝试其他体验和技术时还有哪些其他选择是值得的。

原文链接：https://www.moesif.com/blog/technical/api-development/Fall-and-Rise-of-Embedded-Plugins-Part-3/