REST中的乾淨URI

Question

我正在爲客戶端設計一個新的Web API。我之前並沒有設計過所謂的RESTful API，而且我非常懷疑有關「做什麼」和「不該做什麼」的炒作的正確性。

也許這是我的，但有一點我不明白的是爲什麼這麼多的重點放在了URI的結構上。擁有URI代表資源，而不是。

然後，應用程序需要「預測」URI包含的內容，它具有處理非自然URL結構的許多有效代碼和條件。

對於我們使用的東西就像是幾個世紀：

get_all_products.php 

和：

get_product.php?id=1234 

只要一切是有據可查的，我不明白爲什麼我們需要使應用程序更復雜。

畢竟我們不是爲搜索引擎創建API的！

Answer 1

實際上大多數人完全誤解了Roy Thomas Fielding最初提出的問題，很少有所謂的RESTful應用程序真的是RESTful。

Roy在他的博客文章REST APIs must be hypertext-driven中表達了他對使用REST API調用基於HTTP的接口的人感到沮喪，實際上他們不是。

一個RESTful應用程序的關鍵要素之一是點：

• 甲REST API應該超出了最初的URI（書籤）的先驗知識來輸入，並設置適當的標準化的媒體類型的對於目標受衆（即，可能被使用該API的任何客戶理解）。從那時起，所有應用程序狀態轉換必須由客戶機選擇服務器提供的選擇來驅動，這些選擇存在於接收到的表示中，或者由用戶對這些表示的操作所暗示。轉換可以由客戶對媒體類型和資源通信機制的知識來確定（或限制），這兩者都可以即時改進（例如，按需編碼）。 （這裏的失敗意味着帶外信息正在驅動交互而不是超文本。）

這實際上是大多數普通網站的行爲。

他在這裏描述的是而不是人們認爲他們在應用程序中使用URL重寫和所謂的單一入口點來實現，它與主題無關！

如果沒有超出初始URI的表示形式存在，並且服務器的響應沒有提供進一步的鏈接，那麼確實無法確定應用程序狀態轉換如何超越這一點。無論您如何構建您的URI以及如何構建您的URI，您都不會創建真正的RESTful應用程序。

使用的URI，如：

https://www.example.com/api/1.0/products/ 

可以使客戶知道，如果「1234」是「產品/」部分之後進入，具體的產品被取出。並且促進POST，PUT和DELETE方法可能會進一步使客戶端確定可以在該特定資源上執行哪些操作，但它仍然不是真正的RESTful應用程序，因爲除此之外，無法僅繼續使用服務器提供的選擇。

你真正擁有的是帶外信息驅動交互，而不是超文本，句號！

創建一個HTTP接口，確保你用清晰的複製/粘貼示例（沒有任何假設）記錄一切，並且只是KISS，不要跟着炒作！