最近，我正在使用RESTfull的方式構建一個web服務。儘管現在有很多的一般的指導和提示告訴你如何定義restful介面，但是卻沒有一個明確的標準或大家都接受的schema定義去遵循。

在網上獲取了一些資訊後，我打算打破這一局面：）我打算分享一下我定義的規則和結構，並且很希望能得到一些反饋來幫助我完善這個規則，所以，不要猶豫，請毫無留情給我指出錯誤和毛病吧。</div>

高級別的模式是： http(s)://server.com/app-name/{version}/{domain}/{rest-convention}

這裡，{version}代表api的版本資訊。{domain}是一個你可以用來定義任何技術的區域(例如：安全-允許指定的使用者可以訪問這個區域。)或者業務上的原因。(例如：同樣的功能在同一個字首之下。)

{rest-convention} 代表這個域(domain)下，約定的rest介面集合。 單資源( singular-resourceX ) url樣例：order/  (order即指那個單獨的資源X)

• GET - 返回一個新的order
• POST- 建立一個新的order，從post請求攜帶的內容獲取值。

單資源帶id(singular-resourceX/{id} ) URL樣例：order/1 ( order即指那個單獨的資源X )

• GET - 返回id是1的order
• DELETE - 刪除id是1的order
• PUT - 更新id是1的order，order的值從請求的內容體中獲取。

複數資源(plural-resourceX/) URL樣例:orders/

• GET - 返回所有orders

複數資源查詢(plural-resourceX/search) URL樣例：orders/search?name=123

• GET - 返回所有滿足查詢條件的order資源。(例項查詢，無關聯) - order名字等於123的。

複數資源查詢(plural-resourceX/searchByXXX) URL樣例：orders/searchByItems?name=ipad

• GET - 將返回所有滿足自定義查詢的orders - 獲取所有與items名字是ipad相關聯的orders。

單數資源(singular-resourceX/{id}/pluralY) URL樣例：order/1/items/ (這裡order即為資源X，items是複數資源Y)

• GET - 將返回所有與order id 是1關聯的items。

singular-resourceX/{id}/singular-resourceY/ URL樣例：order/1/item/

• GET - 返回一個瞬時的新的與order id是1關聯的item例項。
• POST - 建立一個與order id 是1關聯的item例項。Item的值從post請求體中獲取。

singular-resourceX/{id}/singular-resourceY/{id}/singular-resourceZ/ URL樣例：order/1/item/2/package/

• GET - 返回一個瞬時的新的與item2和order1關聯的package例項。
• POST - 建立一個新的與item 2和order1關聯的package例項，package的值從post請求體中獲得。

上面的規則可以在繼續遞迴下去，並且複數資源後面永遠不會再跟隨負數資源。 總結幾個關鍵點，來更清晰的表述規則。

• 在使用複數資源的時候，返回的是最後一個複數資源使用的例項。
• 在使用單個資源的時候，返回的是最後一個但是資源使用的例項。
• 查詢的時候，返回的是最後一個複數實體使用的例項(們)。

希望你的關注能幫助我完整這個結構並解決你可能偶然遇到的問題。 在下一篇文章裡，在這個結構完善之後，我將會一些技術上的樣例如何在Spring MVC3.1中，使用它。 OneCoder注：OneCoder只做翻譯，不代表統一文中觀點，Rest URL的定義本來也算是一個仁者見仁智者見智的事情。該文下面的評論中，就有人發表的不同的觀點。