在REST API中使用URL代替ID确实很实际

Question

REST API的正确设计似乎是一个有争议的话题。据我了解，关于ID的纯粹主义方法是，URL是外界资源的唯一标识符，因此客户也不必以任何方式来解释URL(例如，知道最新的URL细分是ID(，也不必须将ID明确包含在用于简单的Get请求的表示形式中。

乍一看，这似乎是一个好的规则，因为客户不必关心基于ID的URL，这是同一件事。ID告诉您如何检索资源。但是，我怀疑这在实践中确实适用。我想到的一些担忧：

• 如果URL因新的API版本而更改(鉴于它是URL的一部分(
• 或协议从http更改为https。
• 或该应用程序甚至出于某种原因移动到另一个域
• 简短的ID非常方便参考参数中的资源。这是不可能的：/books?author=short.author.id

它只是将过多的信息放入并非真正属于那里的ID中，因为任何消费者都不应以这种方式解释IDE。

这在实践中真的做到了吗？是否有采用这种模式的流行公共API的例子？或者，也许我不正确理解它，这不是纯粹的纯粹主义者拥护者？

Answer 1

可以查看HyperMedia驱动的Restful API。在Hateoas中，uris是可以发现的(没有记录在案(，以便可以更改它们。也就是说，除非它们是您系统中的非常入口点(酷乌里斯，唯一可以由客户刻录的乌里斯( - 如果您希望能够发展其余部分，则不应该有太多的您系统将来的URI结构。实际上，这是休息的最有用的功能之一。

对于剩余的非冷urr，它们可以随着时间的推移而更改，并且您的API文档应阐明应在运行时通过HyperMedia Traversal发现它们。

查看Richardson的成熟模型(级别3 (，这将是链接发挥作用的地方。例如，从最高级别(例如/api/version(/1((，您会发现这些组有一个链接。这是在HAL浏览器之类的工具中看起来的外观：

root：

{
  "_links": {
    "self": {
      "href": "/api/root"
    },
    "api:group-add": {
      "href": "http://apiname:port/api/group"
    },
    "api:group-search": {
      "href": "http://apiname:port/api/group?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}"
    },
    "api:group-by-id": {
      "href": "http://apiname:port/api/group/{id}" (OR "href": "http://apiname:port/api/group?id={id}")
    }
  }
}

这里的优势是客户只需要知道关系(链接(名称(显然是资源结构/属性以外(，而服务器大多可以自由更改关系(和资源(URL。