2011-08-19 119 views
6

在HTTP URL路徑中使用各種標點符號會不明智嗎?我正在爲API定義資源URL。這些資源URL必須被各種客戶端和中間件訪問,存儲和傳輸,因此重要的是它們不包含可能導致問題的字符。HTTP URL路徑中分隔符的最佳實踐

RFC 3986, section 2.2. "Reserved Characters"指定下列字符作爲子delims:$ &「()* +,; =

是否有任何這些在HTTP協議的URL路徑內任意使用非法的!?

即使他們根據標準是合法的,這些中的任何一個都很可能會由於不符合標準的軟件而導致真實世界的互操作性問題?

在廣泛部署的API中,您有沒有使用過以前沒有問題的特定子分隔符(這可以證明您使用的是安全的)?

其動機是我們需要爲沒有分層語義的鍵值對進行分隔。我們正在考慮這樣做:http://doriantaylor.com/policy/http-url-path-parameter-syntax。但是,如果這可能是一個問題,我們會只是做http://example.com/key1/value1/key2/value2

感謝

+0

我會和Dorian Taylor的模式一起工作,直到某些事情中斷,然後將'/ key/value/key/value'作爲_alternative_添加,但保留舊的兼容性。 – zwol

回答

0

你去無論怎樣,可以肯定的是,即使使用指定的版本,更改API也可能會產生問題。這是一個壞主意有相同資源的多個位置 - 應該有一個規範的位置。理論上講,如果您擔心兼容性,最好避免使用HTTP 301重定向。多利安泰勒設置方案看起來很明智(而且完全合法),不應該給任何系統(或任何不是很大的錯誤)的任何兼容性問題。

如果您的URL需要用作新URL中的參數,則正斜槓和等於必須是percent encoded,但對於標準查詢字符串(?&=)和您提出的替代方案,以及如果協議包含在內,則爲://。顯然,如果你想在你的值中使用;,=,你需要對它們進行編碼。

我可以看到的唯一可能的問題是,如果您的URL存儲在CSV中,但CSV庫很常見,並且引用特殊字符的定義很明確。