REST 样式 URL 中的 ID 值

Question

如果我的应用程序有不止一种方法来识别资源，例如全局唯一标识符，以及更人性化的值的复合键，这被认为是可取的？

举个例子：

• https://localhost:12345/api/customer/{customerId:int}/product/{productSku}
• https://localhost:12345/api/customer/732/product/46
• https://localhost:12345/api/customer/abc-spares-ltd/product/CF31-APB

相对于：

• https://localhost:12345/api/product/{productGlobalId:Guid}
• https://localhost:12345/api/product/B51B6E8A-B68E-4FD0-9FC2-BAA682FAFB14

这是一种可能，但似乎毫无意义：

• https://localhost:12345/api/customer/{customerId:int}/product/{productGlobalId:Guid}
• https://localhost:12345/api/customer/81C51258-DDDD-4815-A207-37ED735D1AEA/product/B51B6E8A-B68E-4FD0-9FC2-BAA682FAFB14

除了在这种情况下可读性较差（更直接的可能很容易成为系统中的唯一整数），选择背后的原因是什么？应该两者都实现，还是给定资源只有一个 URL？

我认为有一些影响：

• 第二个选项将需要较少的“友好”ID 值和内部全局唯一值之间的转换。
• 在 SQL 数据库中，使用主键意味着不必定义更多索引（这会影响插入/更新）。
• 在 NoSQL 数据库中，“get-by-ID”是典型的，如果不使用数据库系统的“主键”等效项，或者可能需要进行一些转换，查询甚至可能返回最终一致的数据。
• 两者之间是否存在关系（在本例中存在关系，但由于存在 guid ID，因此不一定非要将产品作为集合的子集来查找。
• DDD 风格的聚合设计是否会影响决策？例如，产品不会成为客户聚合的一部分，即使实际上存在关系（例如，一个客户不会“看到”另一个客户的产品）。
• 如果理论上可以修改产品的“SKU”，那么 URL 实际上最终可能指向不同的资源。使用不可变的“内部”标识符这是不可能的（您可能会通过软删除实现 404，并创建一个全新的产品）。

Answer 1

REST 不关心您的 URI 使用什么拼写。

REST API（在 HTTP 中）的要点是让您的域像网站一样工作。因此，当您考虑资源时，您应该考虑您的表示从外部的含义，而不是内部的外观（即，不是您当前的实现）。

也就是说，您应该能够在使用 RDBMS 和无 SQL 文档存储之间切换，而无需更改 API。您的 API 公开了集成资源，因此客户端不受您的实施选择的影响。 Jim Webber 的Domain Driven Design for RESTful Systems 对此进行了扩展。

除了在这种情况下可读性较差（更直接的可能很容易成为系统中的唯一整数），选择背后的原因是什么？

您应该选择与RFC 3986 一致的拼写（路径中的层次结构、查询字符串中的非层次元素、主资源中包含的辅助资源的片段。

Cool URI Don't Change -- 您使用的拼写应以保持 URI 随时间稳定（包括将它们与可能随时间演变的实现分离）为动机。

您应该选择人类可读的拼写——消费者不在乎的机器，因为它们只是跟随链接或填写模板（假设您的 API 包含超媒体功能）。 p>

示例：您为哪个添加了书签？谷歌，还是 216.58.209.164？

应该两者都实现，还是应该只有一个给定资源的 URL？

每个资源总是有一个 URI —— 这在定义中是有一定意义的。也就是说，您可能有许多资源在任何给定时间共享相同的表示。

Fielding 在his thesis 中使用了这个例子。

例如，学术论文的“作者的首选版本”是其值随时间变化的映射，而“在 X 会议论文集中发表的论文”的映射是静态的。这是两个不同的资源，即使它们在某个时间点都映射到相同的值。区分是必要的，以便可以独立识别和引用这两种资源。软件工程中的一个类似示例是在提及“最新修订”、“修订号 1.2.7”或“Orange 版本中包含的修订”时，单独标识受版本控制的源代码文件。

看看你的其他想法......

DDD 风格的聚合设计会影响决策吗？例如，产品不会成为客户聚合的一部分，即使实际上存在关系（例如，一个客户不会“看到”另一个客户的产品）。

不是真的，因为事情比这更复杂。如上所述，集成源不是您的域模型中的实体（请参阅上面链接的 Webber 的演讲）。此外，将持久化数据对齐到“聚合”是一个随时间变化的实现细节。

请注意，您通常只会运行最新的域模型，但您的集成预计将向后兼容以支持旧客户端。

打野

REST 适用于跨多个组织的长期基于网络的应用程序。