REST设计规则

1.简介

• REST(Representational State Transfer), 表述性状态转移是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格.
• REST只是一种概念、风格或者约束，是回归HTTP本身的建议.
• REST，SOAP，XML-RPC是目前三种主流的Web服务实现方案。REST相比其他两种更加简洁。

2.REST特点

REST应用应该具备的五点约束:

1.     每个资源都应该有一个唯一的标识
2.     使用标准的方法来更改资源的状态
3.     Request和Response的自描述
4.     资源多重表述
5.     无状态的服务

    
与RPC(Remote Procedure Call Protocol)的区别:

1.     REST强调资源有唯一的URI；而RPC更加强调过程(动词)，由统一的接口来调用它们。
2.     REST回归HTTP最初的设计；RPC仅仅只是把HTTP作为传输协议来使用。
3.     REST是由超文本驱动的；RPC是由方法驱动的。
4.     REST强调HTTP通信的语义可见性，通过消息头和标准的HTTP方法来体现；RPC把语义封装在HTTP消息体中。

    
3.如何设计REST接口

3.1用URL规划所有的资源

       资源就是我们服务器能提供的一个服务和返回的结果数据。对于软件来说，资源就是一个API接口。URL在REST设计中，是非常重要的，设计时需遵循一下准则:

1. 一个URI标识一个资源，但是一个资源可以被多个URI标识
2. 资源是有层次的，应该在URL中体现
3. 定义内部保留URL关键字
4. 编写URL说明文档
5. URL中不出现动词(因为都是资源)

 
3.2使用HTTP提供的基本方法来对资源进行操作
      CRDU操作定义如下:

1. POST   (创建资源Create)
2. GET    (获取资源Retrieve)
3. PUT    (修改资源Update)
4. DELETE (删除Delete)

 
4.资源内容协商

开发者在发送一个 REST API 请求的同时，根据应用场景，针对相同的资源，可能会期待不同的返回形式，如xml, json.

4.1使用 URI 模式进行内容协商

优点: 内容直观，无须解析请求头部内容
缺点：同一资源使用多个URL，造成URL浪费
 
REST API 请求，要求返回 XML 格式数据：
    GET  https://www.mydomain.com/books/cpluscplus/xml
REST API 请求，要求返回 JSON 格式数据：
    GET  https://www.mydomain.com/books/cpluscplus/json

4.2使用 URL 参数进行内容协商

优点: 内容直观，无须解析请求头部内容
缺点：过多的参数会导致 URL 的可读性变差，或者 URL 过长请求无法执行

REST API 请求，要求返回 XML 格式数据：
    GET  https://www.mydomain.com/books/cpluscplus?format=xml
REST API 请求，要求返回 JSON 格式数据：
    GET  https://www.mydomain.com/books/cpluscplus?format=json

4.3使用 Accept 头进行内容协商

优点: 同一资源URL固定
缺点：需解析请求的头部内容

支持的 MIME(Multipurpose Internet Mail Extensions) 类型:
    Accept: text/html;charset=UTF-8

支持的字符编码:
    Accept-Charset: utf-8

支持的数据编码:
    Accept-Encoding: gzip,deflate,sdch

支持的语言:
    Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6

5.正确的使用 HTTP 响应代码

代码	代码含义
200	请求成功，且服务器已创建了新的资源。
201	是否只显示处于警告状态的应用实例
301	重定向, 请求的网页已被永久移动到新位置。同时服务器自动将该请求者转到新位置。
302	重定向, 请求的网页临时移动到新位置。同时服务器自动转到不同的临时位置。
304	未修改，自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。
400	错误请求, 服务器不理解请求的语法。
401	未授权, 请求要求进行身份验证。
403	已禁止, 服务器拒绝请求。
404	未找到, 服务器找不到请求的网页。
405	方法禁用, 禁用请求中所指定的方法。
406	不接受, 无法使用请求的内容特性来响应请求的网页。
408	请求超时, 服务器等候请求时超时。
410	已删除, 如果请求的资源已被永久删除
412	未满足前提条件, 服务器未满足请求者在请求中设置的其中一个前提条件。
415	不支持的媒体类型, 请求的格式不受请求页面的支持。
500	内部服务器错误。

6.浏览器请求缓存

       当客户在短时间内，多次请求同一资源的时候，我们需要对请求进行缓存，以减少服务器的对数据的操作次数，提高服务器的效率。

client A ------> Get /first ------> 缓存(无) ------> 获取后台数据 ------> hellow world ------> 缓存(有) ------> client A
client B ------> Get /first ------> 缓存(有) ------> hellow world ------> 缓存(有) ------> client B

6.1使用 HTTP 头中的Cache-Control进行缓存处理

 无缓存(http 1.0只有此一种)
Cache-Control: no-cache
 
其他缓存定义, Cache-Control: 
public 所有内容都将被缓存
private 内容只缓存到私有缓存中
no-cache 所有内容都不会被缓存
no-store 所有内容都不会被缓存到缓存或 Internet 临时文件中
must-revalidation/proxy-revalidation 如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证
max-age=xxx (xxx is numeric) 缓存的内容将在 xxx 秒后失效, 这个选项只在HTTP 1.1可用, 并如果和Last-Modified一起使用时, 优先级较高
 
6.2使用 HTTP 头中的Expires进行缓存处理

通过“Expires”字段来指定内容过期时间(必须是GMT格式)，在此时间前的请求都不会导致后台程序重新请求数据:
    Expires: Thu, 01 Dec 1994 16:00:00 GMT
 
6.3使用 HTTP 头中的Last-Modified/ETag进行缓存处理

当数据内容几小时或者几天都不会变时，使用http头或者内容都不合适，需要我们将返回根据服务器内容的最后修改时间 Last-Modified，或者根据服务器内容生成电子标签 ETag.
当用户再次请求数据时，就可以在 HTTP 请求中使用 If-Modified-Since 或者 If-None-Match 头信息，把上次请求得到的时间戳或者电子标签传给服务器。

Last-Modified: Fri, 12 May 2006 18:53:33 GMT
ETag: "50b1c1d4f775c61:df3"

当收到一个有条件请求的 HTTP 头的 REST 请求的时候。我们的程序需要将收到的时间戳或者电子标签与当前内容作比较，就可以很容易的知道用户请求的数据内容在这段时间是否发生过修改。并根据比较结果返回给用户最新内容，或者用 HTTP 响应码 304 告知用户，内容没有变化。

If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT
If-None-Match: W/"50b1c1d4f775c61:df3"

6.4HTTP 内容中的meta进行缓存处理
meta中定义的内容会覆盖 HTTP头中的定义，但是作用是一样的.

7.并行写处理

       如果用户A/B同时获取了资源，然后都对资源做了修改。但是B晚于A提交修改，B的修改很可能会覆盖A的修改。此时使用的解决方案是使用If-Not-Modified-Since/If-Match :当用户发出修改请求时，在 HTTP 请求中使用 If-Not-Modified-Since 或者 If-Match 头信息, 把获取数据时得到的时间戳或者电子标签传给服务器。我们的程序通过与服务器当前内容的比较，就可以知道，这个修改请求是否是针对当前内容提出的。当服务器发现内容已经被其他用户修改过了，就不会执行修改请求，并返回 HTTP 响应码 412（未满足前提条件）给用户。

8.认证安全

HTTP 基本验证：
    GET /index.html HTTP/1.0
    Host：localhost
    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

除此紫外还可以用表单验证，LTPA 验证，Open ID 验证等方式，来满足更多的企业安全要求。