一個URL據稱可以找到（而不是簡單地標識）一個資源;推論是相同的URL必須引用相同的資源。但是，對於像http://api.local/orders/333這樣的URL，其中api.local無法解析爲所有人的主機，並且在解決問題時甚至可能無法解析到相同主機，因此該規則似乎被違反。 （例如，你可能會在開發環境中的一個主機，而另一個環境中生活點api.local）*。本地服務URL是否爲RESTful？
api.local（或127.0.0.1）REST風格的主機名的網址？http://flickr/或http://flickr.local/或http://flickr.api）URL不是RESTful。應用程序是RESTful（或不），但URL不是。事實上，在一個RESTful應用程序中，URL是完全不相關的，所以僅僅是擔心你的URL是否是RESTful就表明你的應用程序不是。但是這與網址沒有任何關係。
的URL通過指定資源和協議的路徑用來訪問該資源所在的資源。你所有的例子都是RESTful。它們標識與REST客戶機想要訪問的REST客戶機相關的資源。
REST客戶端可以自由指定他想訪問的資源位置。 REST客戶端應該知道api.local服務器包含或不包含他想訪問的資源。
如果您的REST服務器意圖擁有通用的可訪問資源，那麼除非請求正確的URL，否則您應該使用找不到的資源進行響應。
完全可以接受的是，您有一種情況，在本地計算機上有另一臺REST服務器，而在Internet上有另一臺服務器。 REST客戶端將指定他想訪問的任何一個。
這就是說，這是不是最好的設計有很多不同的URL引用相同的資源。因此，使用api.local沒有任何問題，但在api.local和api引用不同的資源時最好允許這樣的事情。
URL代表「統一資源定位器」，而不是「通用資源定位器」。 URL中沒有暗示它應該是「全局」或「普遍」可訪問的。所以我沒有發現本地測試的* .local問題（對於我來說，有一個測試或開發環境可以從任何地方訪問）對我來說肯定不好。
我不認爲一個URL需要是全局或全局可訪問的，但不應該相同的URL總是指向相同的東西？ （不管是否可以訪問） – mjs 2010-06-24 06:49:24
啊，我明白你說的是什麼，一臺計算機上的「xyz.local」可能與另一臺計算機上的「xyz.local」不同。我認爲，從最嚴格的意義上講，但從務實的角度來看，這並不總是可能的...... – 2010-06-24 06:51:45
「只有一個URL應該返回資源」背後的主要實際問題之一是因爲對緩存的影響。 如果你有兩個相同資源的URL，那麼你最終可以在緩存中獲得兩個副本。如果你對它們中的一個做PUT，那麼緩存應該使兩者無效，但是它不知道這兩個副本之間的關係。
關於您使用的主機名可能會根據解除引用的位置解析爲不同的字節流的問題，我並不認爲這是一個問題。從概念上講，您正在訪問相同的資源，它實際上只是該資源的另一個實例。我廣泛使用它作爲發現機制的一種形式。我開發了一個託管在我稱爲「TMServer」的服務器上的企業應用程序。在一個組織內，只有一個TMServer實例，並且從該主機訪問所有資源。例如http://TMServer/Suppliers在我的其他客戶之一，該同一個URL將解析爲完全不同的供應商集合，但它在概念上仍然是「供應商列表」。
如果我的其中一位顧客試圖與另一家公司分享一個網址，那麼該網址需要擴展爲http://TMServer.company.com/Suppliers。然後這成爲一個普遍唯一的URI。
通過使用DNS別名，我可以輕鬆地使用我的.hosts文件重定向TMServer指向的位置進行測試，並通過在DNS服務器中添加條目我可以向網絡上的所有用戶廣播服務的可用性。
好的一點是，URL不是RESTful。也許我真的在問，「* .local」這個URL是否應該被稱爲URL。 （我承認這是一個極其棘手的問題！） 也許有關URL的規則實際上並不適用於全局，而只是在每個應用程序的範圍內。即URL定位應用程序本身內的資源，但不同的應用程序可以引用相同的'api.local'並且由它指代不同的事物，因爲他們從未意識到'api.local'在別處以不同的方式被解釋。 – mjs 2010-06-24 07:08:59