在生产环境中IRIS通常以故障转移集群的形态被部署，而集群中各故障转移成员的镜像状态将决定该集群在故障发生时是否能够顺利切换保障业务不中断。因此，成员状态通常也是运维团队需要巡检或监控的目标。

尽管IRIS内部API提供了丰富的集群配置、成员状态监控等一系列接口，但除Portal上的镜像监视器外，并没有特定的接口便于从外部系统访问（如进行企业级监控集成时），也没有整合好的监控接口可用与获取镜像的健康状态。但在IRIS上开发一个REST接口暴露镜像状态数据并不困难，如下所示：

FHIR是快速医疗互操作资源（Fast Healthcare Interoperability Resources）的缩写，所以FHIR的核心是资源模型。它的颗粒度和结构都优于之前的V2 、V3、CDA标准，而且能够灵活扩展。另外一个优势就是它的API，它不仅提供了针对于资源模型本身的原子化的CRUD（创建、读取、更新、删除的这样一些原子化操作），而且提供了查询这种更复杂操作的能力，同样API是可以扩展的。

“池大小”（PoolSize）设置的值决定了一个组件的作业的量和启动方式。在这篇文章中我们将具体讨论对于不同类型的组件来说“池大小”设置的可能值和这些值所代表的含义。

Pool Size = 1

对于所有的组件来说，运行池大小为1的含义都是一样的: 该组件有且只有一个作业，单独运行该组件的代码，顺序处理发送到该组件的消息（FIFO）。

Pool Size > 1

对于业务进程（BP）和业务操作（BO）来说，当运行池大小大于1时，该组件将运行多个作业（作业数=运行池大小设置数）。每个作业都只运行该组件的代码，但消息处理的顺序将被打乱。将运行池的大小设为大于1的值可以在一定程度上提升组件处理消息的性能，但是每个作业的性能还是受限于系统资源的，所以并不是说组件的性能可以随着运行池的大小增加而无限提升。

对于轮询类业务服务（Polling BS）来说，当运行池大小大于1时，该服务也将运行多个作业（作业数=运行池大小设置数）。但这种配置会导致多个进程对轮询结果产生竞争（race condition），所以一般情况下轮询服务不应将运行池大小设为大于1的数值。

添加凭据以登录 FHIR REST 接口 - 在这例子仅考虑基本身份验证

添加服务注册表 - 在这例子仅考虑基本身份验证

- 设置 HTTP 服务

- 输入 FHIR 服务器的路径

- 输入 FHIR 服务的 URL

- 使用配置的凭证

FHIR 通过提供标准化数据模型来构建医疗保健应用程序并促进不同医疗保健系统之间的数据交换，彻底改变了医疗保健行业。由于 FHIR 标准基于现代 API 驱动的方法，因此移动和 Web 开发人员更容易使用它。然而，与 FHIR API 交互仍然具有挑战性，尤其是在使用自然语言查询数据时。

在本文中，我将分享我们在 2023 年全球峰会技术交流室中提出的主题。我和@Rochael.Ribeiro

借此机会，我们就以下话题进行探讨：

• 用于快速 API 的开放交换工具
• 开放API规范
• 传统与快速 Api 开发
• 复合 API（互操作性）
• 规范优先或 API 优先方法
• API 治理和监控
• 演示（视频）

用于快速 API 的开放交换工具

当我们谈论快速现代 API 开发（Rest / json）时，我们将使用两个 Intersystems Open Exchange 工具：

第一个是用于快速开发 API 的框架，我们将在本文中详细介绍。

https://openexchange.intersystems.com/package/IRIS-apiPub

第五章 修改实现（IMPL）类

本章讨论如何修改 REST 服务的实现类。

初始方法定义

实现类最初包含存根方法，如下例所示：

JWT Authentication 原理及验证流程

原理

JWT 是一种结构紧凑、URL 安全的身份验证、授权或信息交换方式。在身份验证的情况下，服务器会向已通过身份验证的客户端提供一个 JWT，这样客户端在 JWT 过期之前就无需再提供密码来访问服务器上受保护的资源。

第六章 修改规范（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 API 参考（七）

Query

此方法对 IRIS 表执行 SQL 查询并返回结果。请求正文是指定查询的 JSON 对象。它返回一个匹配查询条件的对象数组。每个返回的对象都包含与查询返回的一行相关的信息。

URL

POST http://server:port/api/atelier/v1/namespace/action/query

SQL 查询在 URL 请求的正文中指定。查询必须在指定的命名空间中指定一个数据库。

此调用需要标头 Content-Type application/json。

JSON Messages

返回内容是一个对象数组。错误将出现在每个源代码文件对象的状态属性中：

回过头来，业务场景都是千人千面的， FHIR怎么能够用一个标准涵盖尽可能多的用例？HL7吸收了V3的教训，在V3里面不成功的、或者说采纳度比较低的一个原因就V3试图穷举所有用例，由HL7组织自己来规范这些用例。这个是蛮沉重的教训，这也是V3的方法论虽然好，但是这套实施的路线在国际上有很大障碍的原因。