這是怎麼樣的後續問題this one。RESTful架構中的給定URI是否總是返回相同的響應？
所以是具有用於RESTful架構的任何給定URI的芯租戶一個獨特的反應？這裏的很多討論都傾向於這個方向，但我沒有把它看作是一個「硬性和快速」的規則。我知道它的價值（用於緩存，抓取，傳遞鏈接等），但我也看到像Twitter API違反它的事情（對http://api.twitter.com/1/statuses/friends_timeline.xml的請求將根據給定的用戶名而不同）有些時候它可能是必要的 - 更不用說按時間順序分頁的資源也會隨着新元素的添加而改變。
我是否應該爭取從同一個URI完全消除不同的反應，或者我是否認爲有時它不實際，只要我最小化它的發生，我就會體面。
不同的響應，但相同資源的表示（取決於conneg和條件請求標頭）。在Rest架構中，URI標識一個且只有一個資源（但資源可以具有多個URI）。根據授權用戶呈現不同的資源（HTTP身份驗證，Cookie，...）是不好的做法，因爲相同的URI代表每個用戶的不同資源，如Twitter示例中所示。我不能讓您查看我的時間表並給出URI，因爲這與您的時間軸上的的URI相同。用戶必須在URI中進行編碼，並且訪問受到授權機制的限制。要使單個接入點根據經過身份驗證的用戶呈現不同的資源，請使用重定向（例如，303 See Other，302 Found，...）
你有沒有對你的'壞習慣'聲明有任何參考？根據登錄用戶返回不同的內容是完全合法的。例如，我可以定義一個快捷方式URL'/ my/things'，它返回登錄用戶的東西，並返回響應，並將'Content-Location'頭設置爲'/ users/123/things'來表示規範的位置對於該資源（參見RFC 2616第14.14節） – 2010-04-20 17:09:18
如果/ my/things和/ users/123/things應該表示相同的資源，那麼只有一個應該返回200，另一個應該返回303 See Other。 – 2010-04-20 18:58:29
Content-Location應該用於給出返回的資源變體的URI（不同的表示形式，例如conneg），或者在POST的情況下返回創建的資源（而不是使用201 + Location，後者更加嚴格）。在這種情況下，這是一種不同的資源。通過獲取此URI，您無法確保客戶端將檢索哪個資源。如果UA是瀏覽器，則不能複製/越過URI，因爲Content-Location不可直接訪問。 URI是資源標識符，即它們標識資源，總是相同的（參見Roy論文的第5.2節） – 2010-04-20 18:58:39
在REST沒有說同樣的反應 - 但你shuld準備處理的東西，如「如果修改，因爲」請求頭當他們感覺;）
的tritter API還有其他的問題，很明顯 - 如：這是一個設計決定。一旦你讓朋友時間表被隔離，例如，它會是有意義的把朋友的名字元素下的時間表 - 他們顯然對這個決定;）
它運行到設計決策。看的OData（如http://odata.netflix.com/Catalog/） - 這使得SNSE爲每一個URL返回相同的數據在給定時間（高速緩存），因爲它是一個完全公開cataloque。對於其他場景，這可能沒有意義。
一些請求頭不改變返回什麼（同時仍然的RESTful）：
Accept頭可用於確定響應的格式（HTML vs XML vs JSON）Authorized標頭至少可以確定是否返回401,403或200。真正的問題是Authorized標題（它決定了用戶）是否可以用來更改響應的內容。我還沒有看到任何關於它的官方聲明，但我懷疑很多人寧願在URL中的用戶和用於驗證訪問Authorized頭。我懷疑任何一種方式仍然是RESTful。
問題是，有多少中間緩存可以處理基於auth頭的響應變化。如果緩存對於特定的應用程序並不重要，那麼可能使用單個網址即可。但爲什麼要冒這個風險？ – 2010-04-20 19:10:40
REST規則＃1。切勿使用Twitter API作爲指南;-) – 2010-04-20 18:53:48
Touché;）...我想隱含的問題是RESTful是布爾狀態還是滑動比例。許多「大名」應用程序彎曲或破壞了一些規則，但仍稱自己爲「RESTful」。 – keithjgrant 2010-04-20 20:55:35