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

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

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

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

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

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

这是有好处的，因为：

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

虽然 Caché 和 InterSystems IRIS 数据库的完整性完全不会受到系统故障的影响，但物理存储设备故障确实会损坏其存储的数据。 因此，许多站点选择运行定期数据库完整性检查，尤其要与备份配合，以验证在发生灾难时是否可以依赖给定的备份。 系统管理员在应对涉及存储损坏的灾难时，也可能强烈需要完整性检查。 完整性检查必须读取所检查的 global 的每个块（如果尚未在缓冲区中），并且按照 global 结构指示的顺序读取。 这会花费大量时间，但完整性检查能够以存储子系统可以承受的最快速度进行读取。 在某些情况下，需要以这种方式运行以尽快获得结果。 在其他情况下，完整性检查需要更加保守，以避免消耗过多的存储子系统带宽。

行动计划

以下概述适合大多数情况。 本文其余部分中的详细讨论提供了采取其中任一行动或得出其他行动方案所需的信息。