RESTFUL API

http://www.runoob.com/w3cnote/restful-architecture.html

https://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/

respresentational state transfer

表现层状态转移

REST  一种风格，符合这种风格的api就是RESTFUL API

具体包括 

1   资源与 URI 

REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源能够是实体(例如手机号码)，也能够只是一个抽象概念(例如价值) 。下面是一些资源的例子：

• 某用户的手机号码
• 某用户的我的信息
• 最多用户订购的GPRS套餐
• 两个产品之间的依赖关系
• 某用户能够办理的优惠套餐
• 某手机号码的潜在价值

要让一个资源能够被识别，须要有个惟一标识，在Web中这个惟一标识就是URI(Uniform Resource Identifier)。

URI既能够当作是资源的地址，也能够当作是资源的名称。若是某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具备自描述性，须要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：

• https://github.com/git
• https://github.com/git/git
• https://github.com/git/git/blob/master/block-sha1/sha1.h
• https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
• https://github.com/git/git/pulls
• https://github.com/git/git/pulls?state=closed
  • 使用-或_来让URI可读性更好
  • 使用/来表示层级关系
  • 使用?来过滤资源
  • 使用,;来表示同级资源的关系

2 统一资源接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预约义的操做，不论什么样的资源，都是经过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。　　

3 

资源的表述

客户端经过HTTP方法能够获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，能够有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源自己。 例如文本资源能够采用html、xml、json等格式，图片能够使用PNG或JPG展示出来。

资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。

那么客户端如何知道服务端提供哪一种表述形式呢?

答案是能够经过HTTP内容协商，客户端能够经过Accept头请求一种特定格式的表述，服务端则经过Content-Type告诉客户端资源的表述形式。

在URI里边带上版本号

服务器端不该该保存会话状态

 

4  资源的连接 

咱们知道REST是使用标准的HTTP方法来操做资源的，但仅仅所以就理解成带CURD的Web数据库架构就太过于简单了。

这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermedia as the engine of application state）"。 超媒体是什么?

当你浏览Web网页时，从一个链接跳到一个页面，再从另外一个链接跳到另一个页面，就是利用了超媒体的概念：把一个个把资源连接起来.

要达到这个目的，就要求在表述格式里边加入连接来引导客户端。在《RESTful Web Services》一书中，做者把这种具备连接的特性成为连通性。下面咱们具体来看一些例子。

下面展现的是github获取某个组织下的项目列表的请求，能够看到在响应头里边增长Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来连接项目全部者和项目地址。

5状态的转移

实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。

客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

服务端不须要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。

这种无状态通讯原则，使得服务端和中介可以理解独立的请求和响应。

在屡次请求中，同一客户端也再也不须要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。

但有时候咱们会作出违反无状态通讯原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。

这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。

固然，若是Cookie保存的是一些服务器不依赖于会话状态便可验证的信息（好比认证令牌），这样的Cookie也是符合REST原则的。