RESTful Web API 模式与实践指南

第 6 章 分布式数据 分布式数据

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

打破以数据为中心的习惯的第一步，是不再把系统设计成数据服务的集合，而是为业务能力而设计。

伊拉克利-纳达雷什维利，摩根大通

本章主要介绍以数据为中心的服务接口的秘诀。以数据为中心的接口需要遵循第 5 章中涉及的所有相同原则，以及存储和管理数据的责任所带来的一些额外细节。这些细节涉及确保数据完整性、隐藏内部数据模型和实现技术，以及在不使任何现有数据失效的情况下处理各种可能的网络故障。现在，数据可以很容易地在世界各地传输，并接触到《通用数据保护条例》（GDPR）等法规，这一点尤为重要。

并非所有服务都需要管理自己的数据，但大多数服务都有一定程度的数据支持责任。以数据为中心的服务面临的挑战是，它们通常支持持久性数据。即使服务离线，数据也必须继续存在和/或可被其他服务访问。在某些情况下，服务接口的任务是将本地管理的数据与来自其他外部服务的数据混合在一起。这就加剧了完整性和可靠性问题，因为目标接口现在必须依赖其他数据服务来完成请求工作。而且，特别是在写入数据的情况下，操作中涉及的服务越多，出错的可能性就越大，纠正任何问题也就越复杂。

在超媒体环境中支持分布式数据（见图 6-1）意味着将数据响应表示为消息，并返回超媒体控件，以传达对返回数据的可能操作。这还意味着提供一种通用的信息检索查询语言（IRQL），它独立于任何内部自定义数据查询技术，如 SQL、GraphQL 等。在 Network+ 上编辑数据还意味着支持所有更改的惰性，以提高成功写入的可能性。最后，在网络上启用分布式数据意味着您需要支持修改和扩展后端数据模型的能力，而不会破坏服务接口。

图 6-1. 超媒体数据配方

最小力量法则

本章所选的秘诀旨在强调共同的挑战、确定共同的原则，并就如何遵循蒂姆-伯纳斯-李的 "最小功率法则 "实施应用程序接口提供一般性建议："语言的功能越弱，用该语言存储的数据所能做的事情就越多"。

毫无疑问，数据服务很难。这里的解决方案尽量使用功能最弱的 "数据语言"，以支持您对所存储的数据做最多的事情。

提示

有关设计和实施以数据为中心的服务的更多背景信息，请参阅"支持分布式数据"。

6.1 隐藏数据存储内部结构

几十年来，数据存储技术发生了翻天覆地的变化。与此同时，界面设计师往往需要创建应用程序接口（API），以便能够与使用明显是为本地访问而非分布式网络支持而设计的技术和功能编写的数据服务进行交互。创建以数据为中心的服务的指导原则是将技术隐藏在界面背后，并始终提供 "使用 API 消费者语言 "而非数据存储技术语言的 API。

问题

确保以数据为中心的服务的 API 不会 "泄露 "该服务所使用的底层存储和查询技术的最佳方法是什么？怎样才能使 API 消费者免受基础数据技术随时间推移而发生变化的影响？什么时候暴露当前存储技术的语法才有意义，什么时候为服务接口采用更通用的查询、数据管理和存储语言才有意义？

解决方案

原则上，最好向 API 用户隐藏数据存储技术。他们不应该知道您使用的是基于 SQL 的技术、GraphQL 还是简单的基于文件的存储。理想情况下，您在设计接口时应允许更改底层数据存储，而不会对现有的 ...