RESTful @Controller和@RestController使用

简单的理解，restful是一种url风格，或者说是规范，在以前的网址中，假定一个业务，取得数据网址为http://test/get,添加信息的网址为http://test/post，类似这样。
但是在restful风格中，取得数据和添加数据的网址均应为http://test，方法为get或者post；
所以，在restful风格中，一个网址就是一个资源，其形式类似于http://xxx.com/xx/{id}/{id} ,

例如某购物网站，产品有很多种类，每种产品下有很多子类型，那么http://shop.com/laptop/lenovo/1103
代表了联想1103型号电脑，而http://shop.com/laptop/hp/1024 代表了2014型号电脑。

最近，我正在使用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请求体中获得。

---

上面的规则可以在继续递归下去，并且复数资源后面永远不会再跟随负数资源。

总结几个关键点，来更清晰的表述规则。
在使用复数资源的时候，返回的是最后一个复数资源使用的实例。
在使用单个资源的时候，返回的是最后一个但是资源使用的实例。
查询的时候，返回的是最后一个复数实体使用的实例(们)。

---

最后推荐一个RESTful 非常好的文章：http://blog.jobbole.com/41233/

在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注解。