yuan对《REST实战》的笔记(14)

yuan
yuan (自己是一切问题的答案)

在读 REST实战

REST实战
  • 书名: REST实战
  • 作者: Jim Webber/Savas Parastatidis/Ian Robinson
  • 副标题: 超媒体和系统架构
  • 页数: 388
  • 出版社: 东南大学出版社
  • 出版年: 2011-10
  • 第16页
    每一个表述都是针对相同的底层资源的一个视图,通过Web的内容协商(content negotiation)机制在运行时进行转换格式的协商。
    2011-10-17 21:44:27 回应
  • 第48页
    注7: 这是一种简化。事实上,资源可以被创建,但是发出 GET 请求的客户端不需要为此负责。如果你的服务支持通过 GET 请求创建资源,为此负责的是服务本身,而不是服务的客户端!
    所以想要说明“URI 隧道技术并非是对 Web 友好的”,这个例子举得根本不合适嘛。
    2014-09-01 14:14:49 回应
  • CRUD 式 Web 服务
    当消费者收到包含 ETag 的响应时,它就可以(并且应该)在向这个资源发送的任何后续请求中使用这个值。 当然,消费者没有义务转发他们收到的 ETag,因此服务不要期望因为产生了 ETag,就一定能在后续请求中接收到它。 If-None-Match 主要用于条件式 GET 请求,而 If-Match 则一般用于其他的请求方法,在多位消费者相互竞争的场合中,如果没有适当的协调,将会导致难以预料的副作用。 除了 ETag 及与其相关的 If-Match,If-None-Match 头信息之外,HTTP 还支持基于时间戳的 Last-Modified 头信息及其两个相关的条件头信息:If-Modified-Since 和 If-Unmodified-Since。这些基于时间戳的条件头信息的作用实际上与 If-Match 和 If-None-Match 头信息一样,但是它们实现的条件机制只精确到秒,这是受到 HTTP 所使用的时间戳格式的限制。因为计算时间戳通常比计算散列容易,当资源的变化频率低于每秒钟一次时,我们通常更喜欢在解决方案中选择使用 If-Modified-Since 和 If-Unmodified-Since。 实际上,我们往往是用时间戳作为可以便宜得到的 ETag 头信息值,而不是作为 Last-Modified 值。通过一开始就使用 ETag,可以确保更细粒度的 ETag 升级路径完全由服务来决定。服务可以由使用时间戳改成使用散列,而不会对客户端造成影响。
    那实际上,服务器端把时间精确到微秒然后再转换成浮点数或者整数作为 ETag 不就能避免因 HTTP 时间戳格式限制而无法普遍地使用时间戳么?
    不过,当然时间戳可能永远无法比散列值来得精确。
    另外,在该例中,ETag 主要是用作并发时校正资源状态,ETag 的另一个用途是缓存控制。
    2014-09-14 16:29:15 回应
  • 通过 WADL 自动消费服务
    WADL 这玩意似乎用处不大。
    2014-09-14 17:07:20 回应
  • 将超媒体作为应用状态的引擎
    超媒体系统的特征是:根据(与应用协议参与者交换的)资源表述中的链接进行转移。这些链接会对参与该应用协议的其他资源进行广告(advertise)。这些链接常常会被一些语义标记增强,以给出它们所标识的资源在领域中的含义。
    感觉背后的意思是我们之前一直在滥用重定向(302, 301)。这些以前重定向之后才能看到的链接现在应该附带放在响应体里边。
    而重定向似乎可以通过其它响应代码在响应头中带上 Location 信息通过客户端实现。
    在每一次交互中,服务和消费者交换的都是资源的状态表述,而不是应用的状态。被转移的表述中包括反映了应用状态的链接。这些链接会对合法的应用状态迁移进行广告。但应用状态并不显式地记录在消费者收到的表述中,而是由消费者根据所有资源的状态(很可能分布于消息者目前正在与之交互的很多个服务中)推断出来。
    消费者不需要理解特定的 URI 结构,只需要理解出现的链接的语义或业务上下文。
    二级模型依赖 URI 模板或者 WADL 这样的协议描述,而超媒体依赖链接的语义。这样看来 REST 客户端最终形态应该是个 Web 爬虫。
    2014-09-15 16:20:02 回应
  • 超媒体格式
    超媒体驱动的分布式系统对其消费者提出的要求与 Web 对人类提出的要求类似,即消费者必须要发现资源并与之进行交互,从而实现应用的目标。
    所谓语义网是用来理解资源的么?
    2014-09-27 14:51:43 回应
  • URI 模板和耦合
    一般来说,最好只暴露固定的 URI。这些固定的 URI 充当服务的入口点,之后由超媒体接管。
    2014-09-27 16:15:20 回应
  • 处理超媒体格式
    媒体类型是在 HTTP 头信息 Content-Type 中进行声明的。由于此信息位于相关的载荷消息体之外,消费者可以根据它们来确定如何处理某一种表述,而不必事先打开载荷消息体并深入探究其内容——这些事情处理起来的代价可能会很高,例如解密操作。
    决定如何处理表述的是 Content-Type 头信息,而不是 XML 命名空间,这是 Web 上的惯例。
    服务和消费者受 HTTP 应用协议语义的制约。如果服务声明载荷为一种特殊格式,消费者应该接受这条指令,而不应该深入检查载荷的内容来再次猜测处理模型。
    2014-10-03 09:33:36 回应
  • HTTP 惯用语
    契约定义了消费者在特定的上下文中应该用哪一个 HTTP 惯用语(方法、头信息和状态代码)与被链接资源进行交互。 这类信息可能有几个来源。很多超媒体控件具有描述转移选项的属性。例如,XHTML 的 <form> 元素包含了一个 method 属性,它指定用来发送表单数据的 HTTP 方法。有时候,可以使用当前的应用上下文来确定接下来使用哪一个惯用语。如果消费者收到与 ETag 头信息相伴随的表述,就可以合理假设对相同资源的后续请求都必须依赖一个前提条件:If-Match 或者 If-None-Match。同样地,状态代码 303 See Other 和相伴随的 Locations 头信息是指示接收者,要对 Location 头信息的 URI 执行一个 GET 请求。 在当前载荷和处理上下文都没有表明要使用哪些惯用语时,可以在被链接资源的 URI 上使用 OPTIONS。
    我们一定要记住,使用 OPTIONS 方法可以查询资源当前所支持的 HTTP 术语的信息。不过,如果我们发现(消费者)必须使用多个 OPTIONS 请求或者必须用“最佳猜测请求法(best-gues requests)”来探索所链接资源,就应该关注分布式应用可预测性的健壮性。
    2014-10-03 11:26:09 回应
  • 超媒体协议
    PUT 原来这样用:
    POST 一个 order 之后,要对其进行 payment,这时候因为目标是已知的,所以不能用 POST,而应该用 PUT。
    想想 Rails 在 REST 上真是带错了路,硬套“对某个资源 CRUD”的概念。
    2014-10-03 17:54:55 回应
<前页 1 2 后页>