簡單的理解，restful是一種url風格，或者說是規範，在以前的網址中，假定一個業務，取得資料網址為http://test/get,新增資訊的網址為http://test/post，類似這樣。
但是在restful風格中，取得資料和新增資料的網址均應為http://test，方法為get或者post；
所以，在restful風格中，一個網址就是一個資源，其形式類似於http://xxx.com/xx/{id}/{id} ,

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

高級別的模式是：

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 mvc中，有@requestparm, @requestbody和@pathvariable 三種註解來獲得瀏覽器端的引數，其中前兩者都是由瀏覽器post提交的引數，而@pathvariable 則是從網址中取得引數

@Controller和@RestController的區別？

官方文件： @RestController is a stereotype annotation that combines
@ResponseBody and @Controller.

意思是：
@RestController註解相當於@ResponseBody ＋ @Controller合在一起的作用。

• 在@controller註解中，返回的是字串，或者是字串匹配的模板名稱，即直接渲染檢視，與html頁面配合使用的，
  在這種情況下，前後端的配合要求比較高，java後端的程式碼要結合html的情況進行渲染,使用model物件（或者modelandview）的資料將填充user檢視中的相關屬性，然後展示到瀏覽器，這個過程也可以稱為渲染

• 而在@restcontroller中，返回的應該是一個物件，即return一個user物件，這時，在沒有頁面的情況下，也能看到返回的是一個user物件對應的json字串，而前端的作用是利用返回的json進行解析渲染頁面，java後端的程式碼比較自由。

1)如果只是使用@RestController註解Controller，則Controller中的方法無法返回jsp頁面，配置的檢視解析器InternalResourceViewResolver不起作用，返回的內容就是Return 裡的內容。
例如：本來應該到success.jsp頁面的，則其顯示success.

2)如果需要返回到指定頁面，則需要用 @Controller配合檢視解析器InternalResourceViewResolver才行。

3)如果需要返回JSON，XML或自定義mediaType內容到頁面，則需要在對應的方法上加上@ResponseBody註解。