[解決済み] HATEOAS: 絶対URLか相対URLか？

質問

HATEOASを使ったRESTful Webサービスの設計において、リンクを完全なURLで表示することの長所と短所は何ですか(" http://server:port/application/customers/1234 とパス（"/application/customers/1234"）とでは、どちらがよいのでしょうか？）

どのように解決するのですか？

相対 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

厄介なのは、schemeとauthorityを省略した場合、"path"の部分自体は、絶対パス(先頭が / で始まる) か、または "ルートレス" 相対パスのいずれかであることです。例として

1. 或いは 絶対URI または完全なURI。 "http://example.com:8042/over/there?name=ferret"
2. そして、これは 相対 URI であり、絶対パス : /over/there
3. そして、これは 相対パスで、相対 URI : here または ./here または ../here またはその他

つまり、もし質問が "サーバーが 相対パス を生成すべきかどうかという質問であれば、答えは "No"、そして の詳細な理由はこちらでご覧になれます。 . 私を含め、相対URIに反対している人の多くは、実は相対パスに反対しているのだと思います。

そして、実際には、ほとんどのサーバーサイドのMVCフレームワークでは、簡単に 相対 URI を絶対パスで というように /absolute/path/to/the/controller のような絶対パスを持つ相対的なRIを使用する場合、サーバーの実装はそのような相対的なRIの前に scheme://hostname:port を絶対パスの前に付けるべきかどうかということです。OPの質問と同じですね。私はこれについてはよくわかりません。

一方では、私はまだ、サーバーが完全なURIを返すことが推奨されると考えています。しかし、サーバーは をハードコードしてはいけません。 hostname:port のようなソースコード内の のように、ソースコード内で をハードコードすることはありません (そうでなければ、むしろ絶対パスで相対 URI にフォールバックすることになります)。解決策は、サーバーサイドが常にHTTPリクエストの"Host"ヘッダーからそのプレフィックスを取得することです。しかし、これがすべての状況でうまくいくかどうかはわかりません。

一方、クライアント側で http://example.com:8042 と絶対パスを連結するのは、それほど面倒ではなさそうです。結局のところ、クライアントはサーバにリクエストを送信するときに、そのスキームとドメイン名をすでに知っているのですね？

全体として、私はこう言うでしょう。 絶対URIを使うことを推奨し、場合によっては絶対パスで相対URIにフォールバックし、相対パスは決して使わない。 .