HATEOAS：绝对或相对 URL？

Question

在使用 HATEOAS 设计 RESTful Web 服务时，将链接显示为完整 URL (“ http://server:port/application/customers/1234") 与仅路径（"/application/customers/1234"）？

Answer 1

当人们说“相对 URI”时，存在微妙的概念歧义。

根据 RFC3986 的定义，通用 URI 包含：

  URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

棘手的是，当省略方案和权限，“路径”部分本身可以是绝对路径（以 / 开头）或“无根”相对路径。示例：

1. 绝对 URI 或完整 URI："http://example.com:8042/over/there?name=ferret"
2. 这是一个 相对 uri，带绝对路径：/over/there
3. 这是一个相对 uri，带相对路径：此处 或 < code>./here 或 ../here 或等等。

因此，如果问题是“服务器是否应该在静态响应中生成相对路径”，答案是“否”，详细原因是可以在这里找到。
我认为大多数人（包括我）反对“相对URI”实际上是反对“相对路径”。

在实践中，大多数服务器端 MVC 框架可以轻松生成带有绝对路径的相对 URI，例如 /absolute/path/to/the/controller，问题就变成了“服务器实现是否应在绝对路径前面添加 scheme://hostname:port 前缀”。就像OP的问题一样。我对此不太确定。

一方面，我仍然认为建议服务器返回完整的 uri。但是，服务器应该永远不要对主机名：端口进行硬编码 源代码中的内容如下（否则我宁愿回退到具有绝对路径的相对 uri）。解决方案是服务器端始终从 HTTP 请求的“Host”标头获取该前缀。但不确定这是否适用于所有情况。

另一方面，客户端将http://example.com:8042和绝对路径连接起来似乎并不是很麻烦。毕竟，客户端在向服务器发送请求时已经知道该方案和域名，对吗？

总而言之，我想说，建议使用绝对 URI，可能会回退到具有绝对路径的相对 URI，切勿使用相对路径。

Answer 2

这取决于谁在编写客户端代码。如果您正在编写客户端和服务器，那么这没有太大区别。您要么会遭受在客户端或服务器上构建 URL 的痛苦。

但是，如果您正在构建服务器并且希望其他人编写客户端代码，那么如果您提供完整的 URI，他们会更喜欢您。解析相对 URI 可能有点棘手。首先，如何解决它们取决于返回的媒体类型。 HTML 具有基本标记，XML 可以在每个嵌套元素中具有 xml:base 标记，Atom 提要可以在提要中具有一个基础，在内容中具有不同的基础。如果您没有向客户端提供有关基本 URI 的显式信息，那么他们必须从请求 URI 或从 Content-Location 标头获取基本 URI！并注意后面的斜杠。基本 URI 通过忽略最后一个斜杠右侧的所有字符来确定。这意味着在解析相对 URI 时，尾部斜杠现在非常重要。

唯一需要提及的另一个问题是文档大小。如果您要返回一个大型项目列表，其中每个项目可能有多个链接，则在不压缩实体的情况下，使用绝对 URL 可能会向您的实体添加大量字节。这是一个性能问题，您需要根据具体情况确定它是否重要。

Answer 3

唯一真正的区别似乎是，如果客户端使用绝对 URI，而不是从相对版本构建它们，那么对客户端来说会更容易。当然，这种差异足以动摇我制作绝对版本。

Answer 4

随着应用程序的扩展，您可能希望进行负载平衡、故障转移等。如果您返回绝对 URI，那么您的客户端应用程序将遵循不断变化的服务器配置。

Answer 5

使用 RayLou 的三分法，我的组织选择支持 (2)。主要原因是避免 XSS（跨站脚本）攻击。问题是，如果攻击者可以将自己的 URL 根注入到从服务器返回的响应中，则后续用户请求（例如使用用户名和密码的身份验证请求）可以转发到攻击者自己的服务器*。

有些人提出了能够将请求重定向到其他服务器以实现负载平衡的问题，但是（虽然这不是我的专业领域）我敢打赌，有更好的方法来启用负载平衡，而不必显式地将客户端重定向到不同的服务器主机。

*如果这个推理过程有任何缺陷，请告诉我。当然，目标不是阻止所有攻击，而是至少阻止一种攻击途径。

Answer 6

您应该始终使用完整的 URL。它充当资源的唯一标识符，因为 URL 都必须是唯一的。

我还认为你应该保持一致。由于 Location HTTP 标头需要基于 HTTP 规范的完整 URL，因此当创建新资源时，完整 URL 将在 Location 标头中发送回客户端。如果您在 Location 标头中提供完整的 URL，然后在响应正文中的链接中提供相对 URI，这会很奇怪。

Answer 7

大型 API 结果中的一个重要考虑因素是重复包含完整 URI 会产生额外的网络开销。不管你相信与否，gzip 并没有完全解决这个问题（不知道为什么）。当结果中包含数百个链接时，完整的 URI 占用了多少空间，我们对此感到震惊。

Answer 8

使用绝对 URI 的一个缺点是 api 无法被代理。

收回...不是真的。您应该使用包含域的完整 URL。

Answer 9

关于优点，我发现传输字节数的减少是以客户端对（绝对）路径所需的额外处理为代价的。如果您迫切希望保存每个字节，即使在尝试将内容编码为 gzip、正确使用缓存标头、使用 etag 和客户端上的条件请求之后，那么这最终可能是必要的，但我期望更高的回报你的努力是其他的。

关于缺点，我认为未来如何引导客户端在资源之间的流动（负载平衡、A/B 测试等）会失去控制，并且我认为这是管理网络的不好做法API。您提供的 URL 对于客户端来说基本上不再是不透明的（请参阅 Tim Berners-Lee Axioms of URI 不透明的 Web 架构）。最后，您有责任让客户对您的 API 的创造性使用感到满意，即使这只是关于您的 URL 空间的结构。如果您需要允许显式定义的 URL 修改，请考虑使用 URI 模板 如超文本应用程序语言中所使用。

Answer 10

GET : http://localhost:9090/api/my-service/manage/route/1

UnaryOperator<OutputResponse> addLinkConsumer = (group) -> {
    try {
        return group.add(
                        Link.of(WebMvcLinkBuilder
                                        .linkTo(WebMvcLinkBuilder.methodOn(GroupController.class)
                                                        .getSubById(group.getId()))
                                        .withSelfRel()
                                        .toUri()
                                        .getPath()));
    } catch (Exception e) {
        throw new APIException(DemoRuntimeException.ERROR_IN_LINK_GENERATION,
                        "Failed to generate link for group " + group.getId());
    }
};

HATEOAS 的输出以及 Java Spring Boot 中的相对路径

   {
        "id": 1,
        "name": "some name",
        "links": [
            {
                "rel": "self",
                "href": "/api/my-service/manage/route/1"
            }
        ]
    },