InterSystems API Manager (IAM) 版本1.5已正式发布。

在医疗行业要实现互操作，应该要达到语义级别。只有达到语义级别才能保障医疗信息的准确和医疗行为的安全。而要达到语义级别，我们需要基于标准。

第二十三章 源代码文件 REST API 参考（五）

DeleteDoc

此方法删除指定命名空间中的命名源代码文件。它返回相应的源代码文件对象。

与源代码文件有关的错误将在源代码文件对象的状态属性中。

有关示例和其他详细信息，请参阅本手册教程章节中的删除文件。

URL

DELETE http://server:port/api/atelier/v1/namespace/doc/doc-name

注意：如果要删除 CSP 文件 ，则 doc-name 的值包括 /（斜杠）字符。这就是定义 DeleteDoc 的 URLMap 包含此参数名称的 (.*) 而不是 :docname 的原因。有关详细信息，请参阅创建 REST 服务中的“为 REST 创建 URL 映射”。

第六章 修改规范（SPEC）类

概述

下表列出了修改规范类的原因并简要总结了所需的更改：

最近，我需要从持久类和序列类生成一个 Swagger 规范，所以我发布了我的代码（它并不完整 - 你仍然需要处理应用程序的细节，但这是一个开始）。 代码在这里。

假设你有下面的类：

第七章 在 REST 服务中支持 CORS

概述

本节提供 CORS 的概述以及如何在 IRIS REST 服务中启用 CORS 的概述。

CORS 简介

跨域资源共享 (CORS) 允许在另一个域中运行的脚本访问服务。

通常，当浏览器从一个域运行脚本时，它允许对同一个域进行 XMLHttpRequest 调用，但在对另一个域进行调用时不允许它们。此浏览器行为限制某人创建可滥用机密数据的恶意脚本。恶意脚本可能允许用户使用授予用户的权限访问另一个域中的信息，但随后在用户不知道的情况下，将机密信息用于其他用途。为了避免这种安全问题，浏览器一般不允许这种跨域调用。

在不使用跨域资源共享 (CORS) 的情况下，具有访问 REST 服务的脚本的网页通常必须与提供 REST 服务的服务器位于同一域中。在某些环境中，将带有脚本的网页与提供 REST 服务的服务器放在不同的域中是很有用的。 CORS 支持这种安排。

在本文中，我想谈一谈规范优先的 REST API 开发方式。

传统的代码优先 REST API 开发是这样的：

• 编写代码
• 使其支持 REST
• 形成文档（成为 REST API）

规范优先遵循同样的步骤，不过是反过来的。 我们先制定规范（同时兼做文档），然后根据它生成一个样板 REST 应用，最后编写一些业务逻辑。

这是有好处的，因为：

• 对于想要使用你的 REST API 的外部或前端开发者，你总是有相关且有用的文档
• 使用 OAS (Swagger) 创建的规范可以导入各种工具，从而进行编辑、客户端生成、API 管理、单元测试和自动化，或者许多其他任务的简化
• 改进了 API 架构。 在代码优先的方式中，API 是逐个方法开发的，因此开发者很容易失去对整体 API 架构的跟踪，但在规范优先的方式中，开发者被强制从 API 使用者的角度与 API 进行交互，这通常有助于设计出更简洁的 API 架构
• 更快的开发速度 - 由于所有样板代码都是自动生成的，你无需编写代码，只需开发业务逻辑。
• 更快的反馈循环 - 使用者可以立即查看 API，并且只需修改规范即可轻松提供建议
  让我们以规范优先的方式开发 API 吧！

第九章 REST 服务安全

如果 REST 服务正在访问机密数据，应该对服务使用身份验证。如果需要为不同的用户提供不同级别的访问权限，还要指定端点所需的权限。

为 REST 服务设置身份验证

可以对 IRIS REST 服务使用以下任何形式的身份验证：

• HTTP 身份验证标头 — 这是 REST 服务的推荐身份验证形式。
• Web 会话身份验证 — 其中用户名和密码在 URL 中的问号后面指定。
• OAuth 2.0 身份验证 - 请参阅以下小节。

REST 应用程序和 OAuth 2.0

要通过 OAuth 2.0 对 REST 应用程序进行身份验证，请执行以下所有操作：

RESTful 应用程序编程接口 (API) 设计和文档编制初学者指南。 通过示例，您将学习一些常见的 RESTful API 模式。

在阅读之前

您需要知道

• 如何在 Ensemble 中创建 RESTful Web 服务
• 如何在 Ensemble 中使用 RESTful Web 服务
• 如何传递服务参数
• 如何返回服务结果

什么是服务 API？

什么是应用程序编程接口？ 是具体化的东西吗？ 是单一编程单元吗？ API 的作用是什么？ 在我看来，API 是由程序代码以间接方式决定的。 但完全定义的 API 是由运行可执行程序的容器（由部署设置控制）提供的。 因此，我宁愿将 API 定义为服务的公共描述。 该描述可以是人类可读的，也可以仅机器可读， 或者两者均可。 API 用于与将要使用服务的人员共享有关服务的基本信息。 API 说明了服务的作用、使用环境、功能以及管理的数据结构等。

第十章 发现和记录 REST API

本章讨论如何发现实例上可用的 REST 服务以及如何为 REST 服务生成文档。

使用 /api/mgmnt 服务发现 REST 服务

/api/mgmnt 服务包括可用于发现 REST 服务类和启用 REST 的 Web 应用程序的调用。

发现 REST 服务

要使用 /api/mgmnt 服务来发现实例上可用的 REST 服务，请使用以下 REST 调用：

关注开发者社区全栈竞赛的朋友会知道，我提交了一个名为qewd-conduit的参赛作品。我想总结一下，为什么我认为您应该花点时间来看看这个作品。

第十一章 /api/mgmnt/ API 参考

此参考列出了 /api/mgmnt/ 服务中的端点，所有这些端点都适用于较新的 REST 服务。下表总结了端点并指出它们是否也适用于手动编码的 REST 服务。

假设您想编写一些真正的web应用程序，例如medium.com网站的简单克隆。这类应用程序可以在后端使用任何不同的语言编写，也可以使用前端的任何框架编写。编写这样一个应用程序有很多方法，你也可以看看这个项目。它为完全相同的应用程序提供了一堆前端和后端实现。您可以轻松组合它们，任何所选前端应该与任何后端搭配。

我来介绍一下这个使用后端InterSystems IRIS来实现后端的相同的应用程序。  

第十二章 使用中的 OpenAPI 属性

本附录列出了 API 管理工具在生成 REST 服务类时使用的 OpenAPI 2.0 规范的属性。此处未列出的属性将被忽略。有几个扩展属性；它们的名称以 x-ISC 开头。

Swagger

• basePath

• consumes

• host

• produces

• definitions (请注意，API 管理工具在生成代码时不使用 Schema 对象的任何属性)

• parameters (for details, see “Parameter Object”)