关闭

RESTFul小结

标签: restpostputuri
245人阅读 评论(0) 收藏 举报
分类:

RESTFul简介

    REST全称是Representational State Transfer,中文意思是表述性状态转移。 它首次出现在2000年Roy Fielding的博士论文中,Roy Fielding是 HTTP 规范的主要编写者之一。 REST指的是一组架构约束条件和原则。如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构。

资源与URI

    REST围绕资源展开讨论,包括资源的定义、获取、表述、关联、状态变迁等。一切都是资源,比如资源间的关系,资源本身。资源可以被识别,需要有个唯一标识,在Web中这个唯一标识就是URI(Uniform Resource Identifier)。 URI既可以看成是资源的地址,也可以看成是资源的名称。如果某些信息没有使用URI来表示,那它就不能算是一个资源, 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则,具有自描述性,需要在形式上给人以直觉上的关联。URI设计技巧,规范:

使用_或-来让URI可读性更好
使用/来表示资源的层级关系
使用?用来过滤资源
,或;可以用来表示同级资源的关系

统一资源接口

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

    如果按照HTTP方法的语义来暴露资源,那么接口将会拥有安全性和幂等性的特性。例如GET和HEAD请求都是安全的, 无论请求多少次,都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的,无论对资源操作多少次, 结果总是一样的,后面的请求并不会产生比第一次更多的影响。

  • GET

    安全且幂等
    获取表示
    变更时获取表示(缓存)

    200(OK) - 表示已在响应中发出
    204(无内容) - 资源有空表示
    301(Moved Permanently) - 资源的URI已被更新
    303(See Other) - 其他(如,负载均衡)
    304(not modified)- 资源未更改(缓存)
    400 (bad request)- 指代坏请求(如,参数错误)
    404 (not found)- 资源不存在
    406 (not acceptable)- 服务端不支持所需表示
    500 (internal server error)- 通用错误响应
    503 (Service Unavailable)- 服务端当前无法处理请求
  • DELETE

    不安全但幂等
    删除资源

    200 (OK)- 资源已被删除
    301 (Moved Permanently)- 资源的URI已更改
    303 (See Other)- 其他,如负载均衡
    400 (bad request)- 指代坏请求
    404 (not found)- 资源不存在
    409 (conflict)- 通用冲突
    500 (internal server error)- 通用错误响应
    503 (Service Unavailable)- 服务端当前无法处理请求

  • PUT

    不安全但幂等
    用客户端管理的实例号创建一个资源
    通过替换的方式更新资源

    如果未被修改,则更新资源(乐观锁)
    200 (OK)- 如果已存在资源被更改
    201 (created)- 如果新资源被创建
    301(Moved Permanently)- 资源的URI已更改
    303 (See Other)- 其他(如,负载均衡)
    400 (bad request)- 指代坏请求
    404 (not found)- 资源不存在
    406 (not acceptable)- 服务端不支持所需表示
    409 (conflict)- 通用冲突
    412 (Precondition Failed)- 前置条件失败(如执行条件更新时的冲突)
    415 (unsupported media type)- 接受到的表示不受支持
    500 (internal server error)- 通用错误响应
    503 (Service Unavailable)- 服务当前无法处理请求

  • POST

    不安全且不幂等
    使用服务端管理的(自动产生)的实例号创建资源
    创建子资源
    部分更新资源

    如果没有被修改,则不过更新资源(乐观锁)

    200(OK)- 如果现有资源已被更改
    201(created)- 如果新资源被创建
    202(accepted)- 已接受处理请求但尚未完成(异步处理)
    301(Moved Permanently)- 资源的URI被更新
    303(See Other)- 其他(如,负载均衡)
    400(bad request)- 指代坏请求
    404 (not found)- 资源不存在
    406 (not acceptable)- 服务端不支持所需表示
    409 (conflict)- 通用冲突
    412 (Precondition Failed)- 前置条件失败(如执行条件更新时的冲突)
    415 (unsupported media type)- 接受到的表示不受支持
    500 (internal server error)- 通用错误响应
    503 (Service Unavailable)- 服务当前无法处理请求

幂等性

    幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴,正如编译器只能帮助检查语法错误一样,HTTP规范也没有办法通过消息格式等语法手段来定义它,这可能是它不太受到重视的原因之一。但实际上,幂等性是分布式系统设计中十分重要的概念,而HTTP的分布式本质也决定了它在HTTP中具有重要地位。

PUT与POST异同

    POST所对应的URI并非创建的资源本身,而是资源的接收者。比如:POST http://www.csdn.com/articles的语义是在http://www.csdn.com/articles下创建一篇帖子,HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源,它们具有不同的URI;所以,POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如:PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的;因此,PUT方法具有幂等性。

资源的表述

    上面提到,客户端通过HTTP方法可以获取资源,是吧? 不,确切的说,客户端获取的只是资源的表述而已。 资源在外界的具体呈现,可以有多种表述(或成为表现、表示)形式,在客户端和服务端之间传送的也是资源的表述,而不是资源本身。 例如文本资源可以采用html、xml、json等格式,图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据,例如,HTTP头“Content-Type” 就是这样一个元数据属性。

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

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

以github为例,请求某组织资源的json格式的表述形式:
这里写图片描述

使用URI后缀来区分表述格式

    像rails框架,就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说,无疑是更为直观,但混淆了资源的名称和资源的表述形式。

状态的转移

    REST原则中的无状态通信原则。初看一下,好像自相矛盾了,既然无状态,何来状态转移一说?
其实,这里说的无状态通信原则,并不是说客户端应用不能有状态,而是指服务端不应该保存客户端状态。

应用状态与资源状态

    实际上,状态应该区分应用状态和资源状态,客户端负责维护应用状态,而服务端维护资源状态。 客户端与服务端的交互必须是无状态的,并在每一次请求中包含处理该请求所需的一切信息。 服务端不需要在请求间保留应用状态,只有在接受到实际请求的时候,服务端才会关注应用状态。 这种无状态通信原则,使得服务端和中介能够理解独立的请求和响应。 在多次请求中,同一客户端也不再需要依赖于同一服务器,方便实现高可扩展和高可用性的服务端。

    但有时候我们会做出违反无状态通信原则的设计,例如利用Cookie跟踪某个服务端会话状态,常见的像J2EE里边的JSESSIONID。 这意味着,浏览器随各次请求发出去的Cookie是被用于构建会话状态的。 当然,如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息(比如认证令牌),这样的Cookie也是符合REST原则的。

应用状态的转移

    状态转移到这里已经很好理解了, “会话”状态不是作为资源状态保存在服务端的,而是被客户端作为应用状态进行跟踪的。 这些类似“下一页”之类的链接起的就是这种推进状态的作用–指引你如何从当前状态进入下一个可能的状态。

结束语

    REST 约束作为一个整体应用时,将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性,RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。


0
0

猜你在找
【套餐】Hadoop生态系统零基础入门
【套餐】嵌入式Linux C编程基础
【套餐】2017软考系统集成项目——任铄
【套餐】Android 5.x顶级视频课程——李宁
【套餐】深度学习入门视频课程——唐宇迪
【直播】广义线性模型及其应用——李科
【直播】从0到1 区块链的概念到实践
【直播】计算机视觉原理及实战——屈教授
【直播】机器学习之凸优化——马博士
【直播】机器学习&数据挖掘7周实训--韦玮
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    文章分类
    最新评论