北海市岛尚生活网络科技有限公司
首页 | 联系方式 | 加入收藏 | 设为首页 | 手机站

产品目录

联系方式

联系人:业务部
电话: 00177-685667
邮箱:service@zzlphq.com

当前位置:首页 >> 新闻中心 >> 正文

为啥REST如此重要?

字号:
摘要:为啥REST如此重要?

英文原文:Why REST is so important

摘要:REST——表征状态转移,由于 REST 模式的 Web 服务更加简洁,越来越多的 Web 服务开始采用 REST 风格设计和实现。例如,Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找;雅虎提供的 Web 服务也是 REST 风格的。

本文我们将讨论 REST,它定义了一组体系架构原则,您可以根据这些原则设计以系统资源为中心的 Web 服务,这是一个非常容易让人误解的概念。本文主要是写给那些想设计 WebService API 但却对 REST 没有十分清晰认识的开发者们。在本文最后会附上一些资源供大家学习,这些资源讲解非常详细。

什么是REST

表征状态转移(Representional State Transfer),是 Roy Fielding( HTTP 规范的主要编写者之一)博士在 2000 年他的博士论文中提出来的一种软件架构风格。它并不是一个标准,而是通过表征(Representional )来描述传输状态的一种原则。其宗旨是从资源的角度来观察整个网络,分布在各处的资源由 URI 确定,而客户端的应用通过 URI 来获取资源的表征。获得这些表征致使这些应用程序转变了其状态。随着不断获取资源的表征,客户端应用不断地在转变着其状态。

目前在三种主流的 Web 服务实现方案中,因为 REST 模式的 Web 服务与复杂的 SOAP 和 XML-RPC 相对比,更加简洁,越来越多的 Web 服务开始采用 REST 风格设计和实现。例如,Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找;雅虎提供的 Web 服务也是 REST 风格的。

让我们来思考一下:

Marcus 是一个农民,他有 4 头牛,12 只鸡和 3 头奶牛。他现在模拟一个 REST API,而我是客户端。如果我想用 REST 来请求当前的农场状态,我仅会问:“State?”Marcus 会回答:“4 头猪、12 只鸡、3 头奶牛”。

这是 REST 最简单的一个例子。Marcus 使用表征来传输农场状态。表征的句子很简单:“4 头猪、12 只鸡、3 头奶牛”。

再往下看,看我如何让 Marcus 用 REST 方式添加 2 头奶牛?

按照常理,可以会这样说:Marcus,请在农场你再添加 2 头奶牛。难道这就是 REST 方式吗?难道就是通过这样的表征来传输状态的吗?不是的!这是一个远程过程调用,过程是给农场添加 2 头奶牛。

Marcus 很愤怒地响应到:“400,Bad Request”,你到底是什么意思?

所以,让我们重新来一次。我们怎样做到 REST 方式呢?该怎样重新表征呢?它应该是 4 头猪、12 只鸡、3 头奶牛。好,让我们再次重新表征……

我:“Marcus,……4 头猪、12 只鸡、5奶牛!”

Marcus:“好的”。

我:“Marcus,现在是什么状态?”

Marcus:“4 头猪、12 只鸡、5 头奶牛”。

我:“好!”

看到了吗?就这样简单。

为什么 RPC 也不够好?

从逻辑角度来看,为什么会更加青睐 REST 而不是 RPC(Remote Procedure Call,远程过程调用 ),因为它极大的降低了我们沟通的复杂度,通过把表征作为唯一的沟通的方式。无需去讨论过程(添加一头牛?增加一种动物类型?给鸡的数量翻倍还是卖掉所有猪?)我们只需讨论表征,并且使用这个表征来达到我们想要的目标,很简单,不是吗?我不希望和 Marcus 的沟通失败,因为我们彼此的理解过程会不一样,所以只需要知道最后的状态就行。但这仅仅是创建 RPC 会产生许多问题之一。如果你使用 RPC,你需要设计一些程序嵌入到某种结构中。这种结构需要存储参数、错误的代码、返回值等。我已经看到许多公司这样做,他们设计自己的 RPC-结构来实现客户端与服务器端的交互,但却产生许多问题。你为什么要这么做?为什么要创建自己的 RPC-结构?这样做的好处是?倘若我想要让应用程序使用许多 WebService,并且这些 WebService 带有多个 RPC-格式属性?那么我不得不去开发一些类似这样的东西:

[图片]

如果你们真的需要 RPC,至少要选择一个类似 SOAP 的标准。

但 SOAP 也很糟糕

即使 RPC 的标准真的很令人痛苦,但我不得不承认 ACID 事务,一个完整的标准化服务描述性语言 SOAP(Simple Object Access Protocol,简单对象访问协议)在某些环境下表现的还不错。尽管如此,SOAP 产品的性能开销很大,它是一个巨大的性能杀手。虽然 REST 不是一个标准,但在实现 RESTful Web 服务时可以使用其他各种标准(比如 HTTP、URL、XML、PNG 等)。

Session 更邪恶

你无需 Session!但有人会说:“我想要保存用户购物车里的商品,所以我必须要 Session!”不,这样想是错误的!即使没有 Session,你也可以做你任何你想做的事情。你可以只需在 URL 里封装购物车信息,或者为购物车创建另一个资源,比如“/carts/5235”。

不需要与客户端进行会话,通过这些操作(指在 URL 里封装购物车信息,或者为购物车创建另一个资源,比如“/carts/5235”)后,客户端向服务器发出请求后,哪怕你在服务器上执行卸载平台和操作系统、拆除服务器硬件、重新组装服务器、重新安装操作系统、平台、应用程序备份恢复操作,也不会影响客户端。

不要强迫客户端保存状态,这样做不仅复杂,而且还会带来许多问题,你应该从你的 Web 应用程序里删除有状态的东西。

不要重造超媒体

目前,超媒体已经相当普及,我提醒大家,不要再去重新造轮子。这里已经有许多,足够你使用了:

  • 采用原子链接规范的超媒体,类似 spring-hateoas 和 spring-data-rest。
  • JSON-HAL
  • JSON-LD
  • ……

其他资源

这里还有一些更加深入的资源供你参考使用:

  • Fowlers Article on the Richardson Maturity Model
  • A great slide on Hypermedia
  • A talk by David Zuelke on RESTful Webservices
  • Intro to REST (short video of GoogleDevelopers)
  • A talk of Lez Hazlewood (Stormpath)
  • A Cookbook for RESTful WebServices
  • Great German Book about REST

(编译:张红月,责编:王果)

来自:Why REST is so important