設計RESTful URI

我正在創建一個RESTful API。我讀設計RESTful URI

http://microformats.org/wiki/rest/urls

，但本網站不給我足夠的「好」的設計我的API的做法。具體來說，我將編寫一個API（只有遠處的GET方法），它將提供函數來轉換地理座標。

實施例：甲地理散列是的座標單一值表示，因此 /convert/geohash/u09tvkx0.json?outputformat=latlong

很有意義。另一方面 /convert/latlong.xml?lat=65 & long = 13 & outputformat = UTC需要兩個輸入值。

看到我的「問題」？什麼使得一個好的API需要多個輸入參數？

（試圖通過「分析」，「確定」良好做法嘰嘰喳喳& FF但是失敗）

來源

2011-03-13 JohnDoe

在被認爲是「技術上」正確的REST URI方面，有使用的查詢字符串參數與否沒有什麼區別。在RFC 3986，它指出：

查詢組件包含非分層數據，與路徑組件（3.3節）數據一起，用於標識一個資源

這就是爲什麼你難以找到明確的「最佳實踐」。話雖如此，許多REST API確實在URI中嵌入了多個參數而不使用查詢字符串。例如，要識別汽車的和車型，您會看到帶有URI的網站：cars.com/honda/civic。在這種情況下，它是非常明顯的2和所以在URI中的所有東西之間的關係是「hackable」。當您只有一個唯一標識資源的參數時，堅持使用非查詢字符串方法也更容易;但如果它像搜索查詢一樣，那麼我可能會將它保留在查詢字符串中。這個SO question也有關於不同方法的有趣討論。

在你上面的例子中，我會堅持查詢字符串參數。儘管REST通常具有更直觀的URL，但這不是REST的意思。 REST更多的是關於超媒體和HATEOAS。

來源

2011-03-13 11:55:39

感謝您對此的解釋！它填補了我與REST「設計原則」的概念鴻溝。沒有意識到HATEOAS，但我喜歡這種態度。 – JohnDoe 2011-03-14 16:34:11

有設計一個REST API

摘要時所要遵循幾個REST最佳實踐VS混凝土
CRUD操作
錯誤處理
API版本
過濾
安全
分析
文檔
穩定性和一致性
URL結構

來源

2015-11-18 17:09:29 Techie

回答

相關問題