rest restful-api

前言

• rest是Representational State Transfer的简称，直译过来就是：表述性状态转移(什么鬼?)。
• rest这个概念出自美国的一位博士的论文，讲到rest的章节地址在这里：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#fig_5_8
• 而我理解的restful-api是一种后端接口api的规范标准，是一种定义接口的风格，核心理念在于：URL定位资源，用HTTP请求方法（GET,POST,DELETE,DETC）描述操作。

restful api url规范

• 服务端提供的restful api中：url应该以名词(常为复数形式)命名，不应该包含动词。然后URL是用来定位资源，资源是restful中的核心。
• 通过http协议的动词来实现资源的扭转：
  • GET 获取资源
  • POST 新建/更新资源
  • PUT 更新资源
  • DElETE 删除资源
• 举个，假如有个资源表示好友信息，传统的接口定义可能会像这样：

http://api.qc.com/getFriends?id=12345 获取好友信息
http://api.qc.com/updateFriends  更新好友信息

而restful就应该像下面这样，通过一个URL定位资源：

http://api.qc.com/v1/friends/12345
定位id为12345的好友资源
get方法请求URL表示获取资源
post方法请求并传递相关参数，实现更新资源

• URL的组成可能包括：模块名称、版本号、资源名称、资源id等等。
• 还有接口返回的http状态码也应该要对应规范：
  • 2XX：表示正常
  • 3XX：表示资源位置已转移
  • 4XX：表示客户端错误
  • 5XX：表示服务端错误

无状态原则

• Statelessness：无状态原则是RESTful架构设计中一个非常重要的原则，无状态是相对于有状态而言的。在理解什么是无状态的交互请求之前，首先我们需要了解什么是有状态，并对两者进行比较以加深认识。

Web服务的状态

• Web服务建立在Web应用程序的协议之上，如：HTTP协议。Web服务的状态指的是请求的状态，而不是资源的状态。是两个关联用户(Client与Server)进行交互操作时所留下来的公共信息(工作流、用户状态信息等数据)。这些信息可以被指定在不同的作用域中，如：page、request、session、application或全局作用域，一般由Server中的Session来保存这些信息。

基于状态的Web服务

• 在基于状态的Web服务中，Client与Server交互的信息(如：用户登录状态)会保存在Server的Session中。再这样的前提下，Client中的用户请求只能被保存有此用户相关状态信息的服务器所接受和理解，这也就意味着在基于状态的Web系统中的Server无法对用户请求进行负载均衡等自由的调度(一个Client请求只能由一个指定的Server处理)。同时这也会导致另外一个容错性的问题，如果指定的Server在Client的用户发出请求的过程中宕机，那么此用户最近的所有交互操作将无法被转移至别的Server上，即此请求将无效化。

基于无状态的Web服务

• 在无状态的Web服务中，每一个Web请求都必须是独立的，请求之间是完全分离的。Server没有保存Client的状态信息，所以Client发送的请求必须包含有能够让服务器理解请求的全部信息，包括自己的状态信息。使得一个Client的Web请求能够被任何可用的Server应答，从而将Web系统扩展到大量的Client中。

总结两者的区别

• 因为无状态原则的特性，让RESTful在分布式系统中得到了广泛的应用，它改善了分布式系统的可见性、可靠性以及可伸缩性，同时有效的降低了Client与Server之间的交互延迟。无状态的请求有利于实现负载均衡，在分布式web系统下，可以有多个的Server，每个Server都可以处理Client发送的请求。有状态的请求的状态信息只保存在第一次接收请求的Server上，所以后来同一个Client的请求都只能由这台Server来处理，Server无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用Server来处理，而有状态的请求则会因为存储请求状态信息的Server宕机而承担状态丢失的风险。Restful风格的无状态约束要求Server不保存请求状态，如果确实需要维持用户状态，也应由Client负责。