2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
如果你曾经在数据库中存储过统一资源定位符（URL）并为此后悔，那么这篇文章就是为你准备的。
这是一个常见的场景：一个服务需要保留对另一个服务中资源的引用。显而易见的解决方案是存储统一资源定位符（URL）。这确实可行——直到主机变更、应用程序接口（API）发布新版本，或者团队决定重构路径为止。突然间，所有存储的引用都失效了，而追踪其影响变成了一个比预期更棘手的问题。
根本问题在于，统一资源定位符（URL）混合了两个不同的概念：资源是什么以及它位于何处。当你存储一个统一资源定位符（URL）时，你是在赌它的位置不会改变。在不断演进的系统中，这通常是一个必输的赌注。
核心理念
如果不存储资源的位置，而是存储一个网关知道如何解析的自有标识符，会怎样？
commerce:orders/order:id=ARG-2024-00091872
finance:accounts/customer:status:id=109234
health:coverage/credential:patient-id=12345678
存储引用的一方无需知道资源位于何处或如何访问它。这是网关的职责。如果应用程序接口（API）发生变更、服务迁移或新系统出现：只有解析器需要更改。存储的引用仍然有效。
我将这种方案称为委托资源标识符（DRI）。
此模式不是什么
- 它不是一种标准
- 它需要一个网关作为中介：当客户端需要直接访问资源而不经过任何中介时，此模式不适用
- 它不强加上下文分类法：每个团队定义自己的分类法
当你需要在受控生态系统中对资源进行持久引用，并希望集中解析逻辑时，这是一种有用的约定。
构建方式
该标识符由两部分组成，以 / 分隔：
<context>/<resource>
- 上下文（左侧）：标识知道如何解析此类资源的域。网关使用它进行路由。
- 资源（右侧）：标识具体的资源。其结构由实现解析器的一方定义。
commerce:orders/order:id=ARG-2024-00091872
└─── 路由 ───┘└─── 具体资源 ──┘
: 分隔层级。= 用于赋值。每一方定义自己的内部约定。
标识符由存储引用的一方构建，依据他们已有的数据和已知的上下文。无需外部调用。例如，接收订单编号的计费服务知道它属于 commerce:orders，并在持久化引用时构建委托资源标识符（DRI）。
如果网关有一个默认解析器，则可以省略上下文：
/order:id=ARG-2024-00091872
一些用例
电子商务：检索订单
客户服务系统存储来自不同渠道的订单引用：自有商店、市场平台、移动应用程序。每个渠道都有自己的应用程序接口（API）。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
