表述性状态传递 (REST) 是一种软件架构风格，它定义了一组用于创建 Web 服务的约束。符合 REST 架构风格的 Web 服务（称为 RESTful Web 服务 (RWS)）提供了互联网上计算机系统之间的互操作性。RESTful Web 服务允许请求系统通过使用统一预定义的无状态操作集来访问和操作 Web 资源的文本表示。其他类型的 Web 服务（如 SOAP Web 服务）需要公开它们自己的专有操作集。
大家可能已经听说过，我们近期推出了InterSystems API管理器 (以下简称IAM)。InterSystems IRIS数据平台™新增了一项功能，支持用户监视、控制和管理IT基础架构中基于Web的API间通信。
在本文中，我将向大家展示如何设置IAM，并重点介绍IAM中可用的一些功能。InterSystems API管理器可提供你所需的一切功能。
在这个由三个部分组成的系列文章中，介绍了如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。
第一部分介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的一些初始定义和配置，以帮助读者理解确保服务安全的整个过程。
第二部分详细讨论和演示了配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。
本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。
如果您想试用IAM，请联系InterSystems销售代表。
与上个场景不同的是，该场景中将使用一个名为“OAuth 2.0 Authentication”的插件。
如果要在资源所有者密码凭证流中将IAM作为授权服务器使用，客户端应用程序必须对用户名和密码进行身份验证。只有在身份验证成功时，才能发出获取IAM访问令牌的请求。
首先，将其添加到“SampleIRISService”中。正如下面截屏所示，需要填充一些不同的字段来配置此插件。
首先，将“SampleIRISService”的ID粘贴到“service_id”字段中，这样就可以在服务中启用该插件。
在“config.auth_header_name”
在这个由三部分组成的系列文章中，我们将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。
在第一部分中，我们介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。
现在，本文将详细讨论和演示配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。
本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。
如果您想试用IAM，请联系InterSystems销售代表。
在该场景中，需要使用一个外部授权服务器生成JWT（JSON Web Token）格式的访问令牌。该JWT使用了RS256算法和私钥签名。为了验证JWT签名，另一方（本例中是IAM）需要拥有授权服务器提供的公钥。
由外部授权服务器生成的JWT主体中还包括一个名为“exp”的声明（包含该令牌过期的时间戳），以及另一个名为“iss”的声明（包含授权服务器的地址）。
因此，IAM需要先使用授权服务器的公钥和JWT内部“exp”声明中包含的过期时间戳对JWT签名进行验证，然后再将请求转发给IRIS。
对IAM进行相应配置时，首先要向IAM中的“SampleIRISSer
介绍
目前，诸多应用程序通过开放授权框架（OAuth）来安全、可靠、高效地访问各种服务中的资源。InterSystems IRIS目前已兼容OAuth 2.0框架。事实上社区有一篇关于OAuth 2.0和InterSystems IRIS的精彩文章，链接如下。
然而，随着API管理工具的出现，一些组织开始将其用作单点身份验证，从而防止未经授权的请求到达下游服务，并将授权/身份验证复杂性从服务本身分离出来。
您可能知道，InterSystems已经推出了自己的API管理工具，即InterSystems API Management （IAM），以IRIS Enterprise license（IRIS Community版本不含此功能）的形式提供。这里是社区另一篇介绍InterSystems AIM的精华帖。
这是三篇系列文章中的第一篇，该系列文章将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。
第一部分将介绍OAuth 2.0相关背景，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。
本系列文章的后续部分还将介绍两种使用IAM保护服务的可能的场景。在第一种场景中，IAM只验证传入请求中的访问令牌，如果验证成功，则将请求转发到后端。在第二种场景中，IAM将生成一个访问令牌（充当授权服务器）
.png)
什么是npm-iris？
NPM是“No Project Mess（项目不乱）”的缩写。
NPM是使用Intersystems IRIS和Bootstrp 4建成的项目和任务管理应用程序。
NPM的创建初衷是通过一个简单直观的项目和任务管理软件，帮助开发者和小型商业公司降低日常问题的复杂度。
它能提供不同的任务视图，包括电子表格、看板、日历，甚至甘特图！
为什么？
在不同的团队中工作，您会发现不同的人喜欢不同的工具。
所以，有时您会在一个项目中使用甘特图，在另一个项目中使用看板，在其他项目中使用纸上的列表……
NPM专注于任务。无论您和您的团队喜欢以哪种方式查看。只需单击并更改您的视图。
功能
新特性/改进的路线图
试一下这款应用程序！
http://npm-iris.eastus.cloudap
假设您想编写一些真正的web应用程序，例如medium.com网站的简单克隆。这类应用程序可以在后端使用任何不同的语言编写，也可以使用前端的任何框架编写。编写这样一个应用程序有很多方法，你也可以看看这个项目。它为完全相同的应用程序提供了一堆前端和后端实现。您可以轻松组合它们，任何所选前端应该与任何后端搭配。
我来介绍一下这个使用后端InterSystems IRIS来实现后端的相同的应用程序。
在本文中，我想谈一谈规范优先的 REST API 开发方式。
传统的代码优先 REST API 开发是这样的：
规范优先遵循同样的步骤，不过是反过来的。 我们先制定规范（同时兼做文档），然后根据它生成一个样板 REST 应用，最后编写一些业务逻辑。
这是有好处的，因为：
RESTful 应用程序编程接口 (API) 设计和文档编制初学者指南。 通过示例，您将学习一些常见的 RESTful API 模式。
您需要知道
什么是应用程序编程接口？ 是具体化的东西吗？ 是单一编程单元吗？ API 的作用是什么？ 在我看来，API 是由程序代码以间接方式决定的。 但完全定义的 API 是由运行可执行程序的容器（由部署设置控制）提供的。 因此，我宁愿将 API 定义为服务的公共描述。 该描述可以是人类可读的，也可以仅机器可读， 或者两者均可。 API 用于与将要使用服务的人员共享有关服务的基本信息。 API 说明了服务的作用、使用环境、功能以及管理的数据结构等。
在过去的好时光，“编制程序文档”或多或少是一种“必要之恶”。 现代编程语言通过在程序源码中引入声明来强制编制文档。 虽然声明是“机器人”可读的文档，但通过使用工具（runoff、Java doc...），可以提取信息并将其格式化成人类可读的格式。 即使没有在源码中添加任何一行真正的文档，这些工具仍然能够生成少量文本。
现在有什么不同吗？ 并没有。 服务 API 仍然是一个抽象的概念，表示正常使用一个功能
关注开发者社区全栈竞赛的朋友会知道，我提交了一个名为qewd-conduit的参赛作品。我想总结一下，为什么我认为您应该花点时间来看看这个作品。
qewd-conduit 使用基于 Node.js 的 QEWD 框架和 IRIS，可以为 RealWorld Conduit 应用程序实现后端 REST API：
https://github.com/gothinkster/realworld
这个方案很酷，它提供了一个平台，让很多人可以为特定应用程序的后端和前端，实现不同的技术解决方案。而qewd-conduit只是符合相同REST API后端规范的众多解决方案之一。同样，要实现完全相同的UI/UX，您可以尝试使用众多不同前端客户端中的任何一个，并通过REST与包括QEWD-Conduit在内的任何Conduit后端集成。
这样就可以用各种不同的框架和技术，去执行完全相同的任务，从而对不同的框架和技术进行比较和对比。
RealWorld应用程序很好地平衡了相关性和非琐碎性（不仅仅是ToDo应用程序！），并且也不是太复杂，无论是在UI/UX还是在后端API方面。因此便于展示和说明如何使用特定技术来实现RealWorld的指定功能。
那么对于qewd-conduit，我将展示如何用QEWD作为Node.js框架来完全用JavaScript实现一组REST API（在IRIS中