Question

REST API的正确设计似乎是一个有争议的话题。据我了解，关于ids的纯粹方法是URL是外部世界资源的唯一标识符，因此客户端也不必以任何方式解释URL（例如，知道最新的segment是id）也不必将id显式包含在为简单GET请求返回的表示中。

乍一看，这似乎是一个很好的规则，因为客户端不必关心基于id生成URL，这只是一回事。 id告诉您如何检索资源。但是，我怀疑这在实践中是否真的适用。我想到了一些问题：

如果网址由于新的API版本而更改（假设它是网址的一部分）
或协议从http更改为https。
或者应用程序甚至因任何原因移动到另一个域
短ID可以方便地引用参数中的资源。这是不可能的：/books?author=short.author.id

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

这是否真的在实践中完成？是否有应用此模式的流行公共API的示例？或者我可能不理解它，这不是REST纯粹主义者所倡导的吗？

Answer 1

查看超媒体驱动的RESTFul API。在HATEOAS中，URI是可发现的（并且没有记录），因此可以更改它们。也就是说，除非它们是您系统的入口点（Cool URIs，唯一可以由客户进行硬编码的入口点） - 如果您希望能够进化，那么您不应该有太多的入口点将来系统的其他URI结构。这实际上是REST的useful最多功能之一。

对于剩余的非酷URI，它们可以随着时间的推移而改变，并且您的API文档应该说明应该在运行时通过超媒体遍历发现它们。

查看Richardson's Maturity Model (level 3)，这将是链接发挥作用的地方。例如，从顶级，例如/ api / version（/ 1），您会发现有一个指向组的链接。以下是HAL Browser等工具的外观：

根：

{
  "_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。

在REST API中使用URL而不是id是否真的很实用

1 个答案: