HTTP URL 路径中分隔符的最佳实践答案

【问题标题】：Best practice for delimiters within HTTP URL pathHTTP URL 路径中分隔符的最佳实践
【发布时间】：2011-10-30 23:53:45
【问题描述】：

在 HTTP URL 路径中使用各种标点符号是不明智的吗？我正在为 API 定义资源 URL。这些资源 URL 必须由各种客户端和中间件访问、存储和传输，因此它们不包含可能导致问题的字符非常重要。

RFC 3986, section 2.2. "Reserved Characters" 将以下字符指定为子分隔符：!$&'()*+,;=

在 HTTP 方案中的 URL 路径中任意使用这些是否非法？

即使根据标准它们是合法的，其中任何一个都很有可能由于不合规的软件而导致现实世界的互操作性问题？

您之前在广泛部署的 API 中是否有任何特定的子分隔符没有问题（这将证明您使用的子分隔符是安全的）？

动机是我们需要分隔没有层次语义的键值对。我们正在考虑这样做：http://doriantaylor.com/policy/http-url-path-parameter-syntax。但是，如果这可能是一个问题，我们将只做http://example.com/key1/value1/key2/value2

谢谢

【问题讨论】：

【解决方案1】：

无论你走哪条路，都要确定；即使指定了版本，更改 API 也可能会出现问题。同一资源有多个位置是坏主意 - 应该有一个规范位置。虽然理论上您可以使用 HTTP 301 重定向，但如果您担心兼容性，最好避免使用它。

Dorian Taylor 集合方案看起来很合理（并且完全合法），并且不应该与任何系统（或任何没有太大问题的系统）产生任何兼容性问题。

如果您的 URL 需要用作新 URL 中的参数，则正斜杠和等号必须为 percent encoded，但对于标准查询字符串 (?&=) 和您建议的替代方案都是如此，如以及://（如果包含协议）。显然，如果你想在你的值中使用;,=，你需要对它们进行编码。

我能看到的唯一可能的问题是您的网址是否存储在 CSV 中，但 CSV 库很常见，并且引用特殊字符的定义很明确。

【讨论】：