HATEOAS:绝对或相对 URL? [英] HATEOAS: absolute or relative URLs?

查看:52
本文介绍了HATEOAS:绝对或相对 URL?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

In designing a RESTful Web Service using HATEOAS, what are the pros and cons of showing a link as a complete URL ("http://server:port/application/customers/1234") vs. just the path ("/application/customers/1234")?

推荐答案

当人们说相对 URI"时,会有一种微妙的概念歧义.

There is a subtle conceptual ambiguity when people say "relative URI".

根据RFC3986 的定义,通用 URI 包含:

By RFC3986's definition, a generic URI contains:

  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

棘手的是,当省略了方案和权限时,路径"部分本身可以是绝对路径(以 / 开头)或无根"相对路径.示例:

The tricky thing is, when scheme and authority are omitted, the "path" part itself can be either an absolute path (starts with /) or a "rootless" relative path. Examples:

  1. 绝对 URI 或完整 URI:"http://example.com:8042/over/there?name=ferret"
  2. 这是一个相对uri,具有绝对路径:/over/there
  3. 这是一个相对uri,带有相对路径:here or ./here or ../here或等
  1. An absolute URI or a full URI: "http://example.com:8042/over/there?name=ferret"
  2. And this is a relative uri, with absolute path: /over/there
  3. And this is a relative uri, with relative path: here or ./here or ../here or etc.

因此,如果问题是服务器是否应该在静态响应中生成相对路径",那么答案是否",并且 此处提供详细原因.我认为大多数人(包括我)反对相对 URI"实际上是反对相对路径".

So, if the question was "whether a server should produce relative path in restful response", the answer is "No" and the detail reason is available here. I think most people (include me) against "relative URI" are actually against "relative path".

并且在实践中,大多数服务器端 MVC 框架可以轻松生成具有绝对路径的相对 URI,例如 /absolute/path/to/the/controller,以及问题变成了服务器实现是否应该在绝对路径前添加 scheme://hostname:port 前缀".就像OP的问题一样.我不太确定这个.

And in practice, most server-side MVC framework can easily generate relative URI with absolute path such as /absolute/path/to/the/controller, and the question becomes "whether the server implementation should prefix a scheme://hostname:port in front of the absolute path". Like the OP's question. I am not quite sure about this one.

一方面,我仍然认为建议服务器返回完整的 uri.但是,服务器应该永远不要硬编码hostname:port 像这样的源代码中的东西(否则我宁愿回退到具有绝对路径的相对 uri).解决方案是服务器端始终从 HTTP 请求的主机"标头中获取该前缀.不过不确定这是否适用于所有情况.

On the one hand, I still think server returning a full uri is recommended. However, the server should never hardcode the hostname:port thing inside source code like this (otherwise I would rather fallback to relative uri with absolute path). Solution is server-side always obtaining that prefix from HTTP request's "Host" header. Not sure whether this works for every situations though.

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

On the other hand, it seems not very troublesome for the client to concatenate the http://example.com:8042 and the absolute path. After all, the client already know that scheme and domain name when it send the request to the server right?

总而言之,我会说,建议使用绝对 URI,可能回退到具有绝对路径的相对 URI,永远不要使用相对路径.

这篇关于HATEOAS:绝对或相对 URL?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆