關於REST URL的詳細問題

這是那些小細節（也可能是宗教）問題之一。假設我們正在構建REST架構，並且爲了確定服務需要三個參數：x,y和z。閱讀關於REST的各項工作，似乎這應該表示爲一個URI像關於REST URL的詳細問題

X/Ÿ/ž

已經寫了很多的CGI的過去，似乎很自然的表達這

http://myservice.example.com/service?x=val,y=val,z=val

是否有什麼特別的理由更喜歡使用全斜槓？

來源

2008-12-24 Charlie Martin

您表示URI的方式對REST來說並不重要，只是您知道。這只是關於HTTP的一個問題。 – aehlke 2009-08-11 19:30:41

原因很小，但在這裏。

酷URI的不改變。

http://myservice.example.com/resource/x/y/z/形式在上帝和大家面前宣稱，這是通向特定資源的路徑。

請注意，我更改了名稱。可能涉及到服務，但REST原則是您正在描述一個名爲/x/y/z/的特定Web資源。

該http://myservice.example.com/service?x=val,y=val,z=val形式不會造成強烈的索賠。它說有一個代碼service將嘗試做某種查詢。沒有保證。

來源

2008-12-24 01:56:38

這個答案是非常荒謬的。「酷URI的不要改變」與這個問題無關。如上所述，這兩個例子都可以在任何時候完全使用，因此是不會改變的URI。 – webjunkie 2009-02-10 20:46:22

@webjunkie。 /服務不是一個很酷的URI，它需要額外的查詢字符串是有意義的。查詢字符串不應被認爲是URI的頭等部分。 – 2009-02-10 20:56:58

@ S.Lott「服務」顯然是一個佔位符，就像x y z一樣。你把一個真正的服務名稱放在它給出URI意義的地方。 – webjunkie 2009-02-10 23:03:55

如果資源是獨立的參數的服務，它應該是

http://myservice.example.com/service?x=val&y=val&z=val

這是一個GET查詢。 REST背後的原理之一是您可以閱讀（但不能修改！）資源;你可以通過POST來修改資源&得到響應;你可以PUT寫入資源;並且您可以刪除以刪除資源。

如果這些參數特定的資源是永久性資源，它需要一個名稱。您可以（如果您以這種方式組織Web服務）POST到http://myservice.example.com/service?x=val&y=val&z=val以創建該服務的特定實例，並讓它返回一個ID來命名該實例，例如，

http://myservice.example.com/service/12312549

然後使用GET/POST/PUT/DELETE與該實例進行交互。

來源

2008-12-24 03:44:01

查詢參數很少「酷」。看看Google Chart API。是否應該爲所有字段使用一個/完整/路徑/符號？每個URL都會很酷嗎？

查詢參數很有用。可選字段可以省略。可以添加新密鑰以支持新功能。隨着時間的推移，舊字段可能會被棄用和刪除。這樣做是笨拙的/路徑/符號。

從報價http://www.xml.com/pub/a/2004/08/11/rest.html

URI不透明度[BP]

URI的創建者決定的URI的編碼，用戶不能從URI本身導出元數據。 URI不透明度僅適用於URI的路徑。查詢字符串和片段有特殊的意思是用戶可以理解。服務與其消費者之間必須有一個共享詞彙表。

這聽起來像查詢字符串是你想要的。

查詢字符串的一個缺點是它是無序的。以「？x = 1 & y = 2」結尾的GET與以「？y = 2 & x = 1」結尾的GET不同。這意味着瀏覽器和其他中間系統將無法緩存它，因爲緩存是基於完整的URL完成的。如果這是一個問題，那麼按照定義良好的順序生成查詢字符串。

來源

2009-02-10 15:39:48

-1

帶有類似/x/y/z/這樣的斜線的網址會強加一個層次結構，並不適合傳遞三個參數的確切情況。

如果像你說的，某某確實只是參數和順序並不重要，它會更RESTful的使用分號：

http://myservice.example.com/service/x;y;z/

如果你的「服務」，然而就是這樣工作的算法使用?x=val格式也不會有什麼不可靠的。

來源

2009-02-10 15:54:29 webjunkie

在構建URI時，這是我遵循的原則。我不知道它是否在所有的情況下

例如說完全可以接受的，我必須得到員工的詳細信息，那麼URI會是這樣的形式：

GET /員工/ 1/而不是GET/employees？id = 1因爲我將每個員工視爲資源，並且整個URI「employees/{id}」用於識別資源。另一方面，如果我的算法運算不能識別特定的資源，而只是需要對算法進行識別資源的輸入，那麼我使用查詢字符串。

比如GET /員工？empname =「％鮑勃％」 &的maxResults = 100會給我的名字在他們的字鮑勃全體員工，由僅限於100

查詢返回的最大成果

希望能回答你的問題

來源

2009-02-17 10:50:14 Prashanth

首先，將URI定義爲API的一部分違反了REST體系結構的約束條件。你不能這樣做，並調用你的API RESTful。

其次，原因查詢參數對非查詢資源訪問不利的原因是它們通常不被緩存。這也違反了HTTP標準。

來源

2009-07-20 19:13:49 aehlke

URI是嚴格劃分爲分層部分（路徑）和非分層路徑（查詢），並既用於識別資源

裏邊反URI規範本身（RFC 3986）明確規定的路徑和URI的查詢部分相等。

3.3節：

路徑組件包含數據[...]與[的]沿查詢組件用於標識一個資源。

第3.4節：

查詢組件包含[...]數據，連同 [...]路徑組件用來標識資源

所以在使用x/y/z與x=val&y=val&z=val時，您的選擇主要是在x，y或z本質上是分層結構還是非分層結構，並且如果您能夠在可預見的將來一直認爲它們是分層結構或非分層結構，與y您可能在選擇其中一項時遇到的技術限制。

但是要回答你的問題，正如其他人所指出的那樣：既不是RESTful，也不是RESTful，因爲它們最終都會識別資源。

來源

2010-08-01 19:40:49 mogsie

關於REST URL的詳細問題

回答

相關問題