ReSTful URLS的標準是什麼？

Question

由於找不到chuffing工作，我一直在閱讀ReST和創建Web服務。我已經解釋了它的方式，未來就是在構建Web應用程序之前爲您的所有數據創建Web服務。這似乎是一個好主意。

然而，似乎有很多矛盾的想法是什麼最好的方案是ReSTful網址。

有人主張簡單漂亮的URL

http://api.myapp.com/resource/1 

此外，有些人喜歡在API版本添加到URL，像這樣

http://api.myapp.com/v1/resource/1

使事情更加混亂，有人主張增加內容類型來獲取請求

http://api.myapp.com/v1/resource/1.xml 
http://api.myapp.com/v1/resource/1.json 
http://api.myapp.com/v1/resource/1.txt 

而其他人認爲內容類型應該在HTTP標頭中發送。

Soooooooo ....這是很多變化，這讓我不確定什麼是最好的URL方案。我個人認爲包含版本號，資源定位器和內容類型的最全面的URL的優點，但我是新手，所以我可能是錯的。

另一方面，你可能會認爲你應該做「最適合你的任何事情」。但據我所知，這並不符合ReST的思路，因爲其目標是制定一個標準。

而且由於很多人會有比我更多的經驗，所以我想請教一些指導。因此，考慮到這一切...

ReSTful URLS的標準是什麼？

Answer 1

歡迎來到什麼是和什麼不是REST的混淆世界。首先，我會建議你在錯誤的地方閱讀了關於REST的內容。嘗試RESTWiki是一個很好的起點。

REST不是爲您的Web應用程序提供數據服務的絕佳解決方案。 「Web服務」（又稱SOAP，XML-RPC，WSDL，HTTP-POX）可能會有所幫助，但REST架構風格更傾向於客戶端 - 服務器場景而不是服務器服務器場景。

不要再考慮網址的樣子。他們看起來像使用哪個服務器端框架來實現RESTful服務，而不是服務本身的設計。客戶端應該從以前檢索的表示中發現URL，因此它並不關心URL的外觀。

話雖如此，使用您的示例網址來嘗試和區分你認爲應該是不同的資源，我還有一些其他的建議。

不要版本資源。即如果您有一個資源被url http://example.org/TodaysWeather訪問，請不要在http://example.org/V2/TodaysWeather創建資源。有很多其他更好的方式來表示版本，而不是創建一個全新的資源。搜索大量的其他討論。至於爲不同的內容類型創建不同的資源，我認爲這是一個上下文特定的決定。如果您的最終用戶使用瀏覽器訪問REST服務，並且它們足夠複雜以瞭解JSON和XML之間的差異，那麼請繼續並創建兩個資源。如果它是一臺機器客戶端，那麼我會使用內容協商來獲得所需的格式。

最後，要小心，因爲REST成爲流行語，因爲周圍存在的錯誤信息遠多於有效內容。

Answer 2

動詞不能放入URL中。這是沒有意義的。它已經在請求標題中。當你發送一個在URL中有GET的POST請求時，這太瘋狂了。

響應格式通常最好放入URL中，因爲標題不提供簡單明確的地方放置該信息。

Answer 3

我與S.Lott - Verb *不應該在那裏，因爲您想使用相同的URL來讀取記錄，並更新它以使其符合REST要求。

內容類型是別的東西，因爲它是相同的記錄，但具有多種編碼格式。 （閱讀FRBR的方式比您想要了解的區別問題更多）。可以使用HTTP Accept標頭處理決定發送哪個版本的響應。

唯一一個我討厭的是版本號，因爲我個人不會想到一個合適的HTTP頭來處理它的方面。 （預計接受編碼Pragma可能甚至是升級，但出於兼容性的原因，你會更經常地想降級到較舊的版本，我想）我可能會有一個版本較少的訪問器，它提供了最新的生產版本，但可能會考慮有一個版本不適合向後兼容的重大更改。

更新：版本問題可能取決於您對連接到您的服務的客戶端有多少控制權......如果你有從廣泛的公衆（我不這樣做）訪問，你可能更感興趣的是向後兼容性。根據所做的更改，您可能會認爲'版本2'是一種全新的資源，而不僅僅是原始版本的新版本。

Answer 4

版本控制：我通常在您的示例url中看到了它的位置，如果沒有指定版本，您應該使用最新的生產版本進行響應。一個考慮因素是是否將API版本放在您的響應字符串中以用於客戶端調試目的。

響應格式：返回格式應在用戶代理髮送的HTTP Accept報頭中指定。

請求字符串中的動詞：絕對不是。