這是真的，來實現一個RESTful API，一個必須實現一個URL結構，看起來像這樣REST API網址是否必須如下所示？
http://example.com/post/
http://example.com/post/123
其中/123將用於編輯，刪除
另一種方式來問的問題是：可以看起來像這樣的URL稱爲RESTful？
http://example.com/script.php?method=get_title&blogid=123
你不有設計你的URI結構類似。它也可能是/some_obscure_string/base64_encoded_title/unique_id。這也可能是RESTful，取決於其他幾個因素。
但是，關於如何在REST風格的Web應用程序中設計URI以及儘可能簡單且儘可能人性化的幾種最佳實踐就是其中之一。
您的示例http://example.com/script.php?method=get_title&blogid=123也可以是RESTful，但查詢參數指示使用某種RPC-或RMI-over-HTTP代替。
總結：不要把太多的想法放在你的URI設計中。這將自動帶上您的應用程序的良好和適當的RESTful設計。
網址示例：
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
REST背後的理念是，一切的資源都有它自己的網址，並使用不同的HTTP方法與這些資源進行交互。定義URL結構是非常有意義的，以便不同資源之間的層次結構反映在URL中，但您不必這樣做。
如果你有這樣的
/all-posts/
/first-post
/some-stuff/second-post
/third-post
網址，你仍然可以提供一個基於REST的API來此。想法是，GET到/all-posts/返回每個帖子對象的URL列表，並且客戶端使用這些URL與資源進行交互。基本上這些URL應該被客戶端視爲不透明的數據。
只要嵌入在客戶端中的URL不會更改，您也可以更改結構而無需更改客戶端。
您的示例URL可能不屬於RESTful API，因爲它包含方法get_title。在REST中，URL表示的東西。要做什麼（如果它被修改，應該檢索內容，...）不是URL的一部分，因爲REST使用不同的HTTP方法。
REST概念的確基於它是由URL驅動的事實，而不是由大數據塊驅動。通過REST，您不必傳遞巨大的soap請求來調用方法 - 您的方法調用/對象創建/您想要做的任何操作都只需通過URL以及您在該URL中使用的動詞來調用。
REST的一個關鍵方面是url是資源。一個像
http://example.com/script.php?etc-etc-etc
沒有把資源標識符放在URI的資源部分。這並不是說RESTful API不應該使用get參數;實際上，這很好：
http://example.com/posts?sort=date_asc&offset=20&limit=10
可能是獲取最舊帖子的第3頁的URI的好方法。但是，以這種方式使用get參數只能用於方法也是GET的請求。 PUT，尤其是POST方法應該真正使用簡單的URI，並且僅在路徑部分中受影響的資源。
您的網址結構並不重要。重要的是每個URL只能標識1個資源。每個資源可以有多個指向它的URL，但每個URL只能指向1個資源。
RESTful URI設計是關於資源訪問的，它們應該以RESTful方式構造，所以你不應該有任何查詢字符串。
例如的GET
作者/
作者/ 1
作者/ 1 /書籍
作者/ 1 /書籍/ 10
作者/ 1 /書籍/ 10 /總結
等
這些天什麼都稱爲RESTfull ，看看它的發明者Roy Fielding博士的一些迴應，你會得到一些想法。值得對這個主題進行一些閱讀。
P.S你不需要在你的URI中發佈，獲取等等，HTTP協議目前主要用於使用REST API，你可以傳遞動詞作爲調用的一部分。還有一個內容協商的概念，即你可以從REST API（json，xml atc）請求任何可用的格式。
+1爲最後一點 – rojoca 2010-10-30 09:01:57
+1爲「儘可能簡單且儘可能人性化」 – AlcubierreDrive 2010-11-01 11:42:19