BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

CRUD不适合REST吗?

| 作者 Boris Lublinsky 关注 0 他的粉丝 ,译者 马国耀 关注 1 他的粉丝 发布于 2009年8月4日. 估计阅读时间: 4 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

Arnon Rotem-Gal-Oz在他的新博文"CRUD不适合REST"中这样开篇:

表面上看起来它们很相配(无论从技术上还是架构上),然而,一旦深入了解,你就会发现它们并不相配。

今天,REST架构风格的常见实现是基于HTTP协议及其相应动作(如POST,GET, PUT和DELET)的。而且,这些动作经常会被实现者映射为CRUD术语——Create,Read,Update和Delete。典型的做法是1对1映射。

  • GET通常被映射为CRUD中的Read,只是GET还提供了超越开箱即用(Out-of-the-box)的SELECT(即Read)映射的一些特征。
  • DELETE通常被映射为CRUD中的Delete
  • PUT通常映射为CRUD中的Update,只不过增加了一些限制:
    • PUT替换的对象是整个资源,而Update可以替换一部分。
    • PUT可以用于创建一个资源(当客户端设定RUI时)
  • POST通常被映射为CRUD中的Create,但它仅支持创建子资源,可是POST支持对资源的部分更新。

Arnon认为:

HTTP动作更加面向文档而不是数据库,至少在谈到HTTP动作时,执行Update,Delete和Create新资源采用的做法和CRUD在数据库的世界里的做法是不完全一样的。

然而,CRUD不适合于REST的最大原因是架构上的,REST的核心是使用超媒体实现的协议状态机。Arnon引用Tim Ewald的话

……这是我所理解的。每一种交互协议都有一个状态机,有些很简单,有些则比较复杂。当你通过RPC来实现协议时,你是在创建用于修改交互状态的方法。从交互端点看来,状态是由一个黑盒子维护的。由于协议状态是隐藏的,所以很容易出错。比如,你很有可能在初始化之前就调用某个流程。很长一段时间里,人们一直通过为接口的类型信息下注解的方式来寻找避免这类问题出现的方法,但是我从没有看到任何主流的解决方法。事实上,协议的状态隐藏在方法调用的背后,在方法调用的过程中隐式地修改状态,这个事实更增了版本控制的趣味。

REST的精髓是通过URI来显式描述协议的状态。协议状态机的当前状态是由最近一次操作的URI以及该操作获取到的状态描述决定的。若要修改状态,那么就对URI进行相应的目标状态的操作,使资源呈现期待的新状态。状态描述包括指向其他状态的链接(状态图中的弧线),通过这些链接可以从当前状态移动到目标状态。基于浏览器的应用就是这么工作的,而且你的应用程序协议没有理由不能那样工作。(ATOM发布协议是一个经典的状态机例子,尽管它被经常认为是关于实体的,而不是状态机的)

接着John Evdemon&rsquo的文章中所阐述的为什么CRUD服务是SOA的反模式,Arnon描述了CRUD REST的缺点:

  • 限制了服务的整体概念——没有业务逻辑。
  • 暴露了内部的数据库结构,或者数据接口,而不是仔细考虑后的接口。
  • 鼓励直通服务和数据的做法。
  • 建立的是块(Blob)服务(数据源)
  • 鼓励细小的多重服务(为块服务定义多重接口),而忽略了分布式计算的若干谬误。
  • 仅仅是“批着羊皮”的C-S结构。

Arnon在博文结尾的时候再次强调,仅仅采用诸如HTTP,XML,JASON等标准(尽管他们很有用)还不能构成 REST,而只有采用了REST架构才算真正的REST。

这篇博文的重要性在于它提醒到:REST和SOA类似,它不是一组标准和流行的API,而是一种架构模型,这才是需要去理解和遵循的。

查看英文原文:Is CRUD Bad for REST?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

从来就没有什么救世主,也不靠REST和SOA by 陈 实

这些天看了RESTful Web Services一书,看来看去,其实RESTful也就是一种充分利用http来实现功能而不通过添加额外API的想法。但,从来没有什么架构救世主,当然也不能全靠RESTful了,我们这些死写程序的在实际应用中还是要灵活点比较好。

Re: 从来就没有什么救世主,也不靠REST和SOA by Colder Xihk

大牛们只知道说教 却不肯指出一条明路
小菜们才是实践者 具体的困难无人知晓

小菜的实现不正规 大牛就出来指手划脚
小菜听烦了不理踩 继续实践着山寨之路

终于有一天理论得以推广
小菜说: 看起来还不错
大牛说: 技术又一次被滥用了

提起无人知晓, 突然想起一部电影:
www.verycd.com/topics/44616/

不要因为手里拿着榔头,就看到的一切都是钉子 by Great Way

手段永远是为目的服务的,没有最好的技术,只有最适合的。

和那篇Roy Thomas Fielding的文章是一个意思 by Lee John

RESTFul的核心是url驱动,换个角度说,是url导致状态变迁,仅仅把rest看作web版的crud是阉割了自己的应用

REST的意义何在? by Lee Bruce

不知道REST的意义何在?还不如直接把数据库暴露出来的方便。
REST对于简单的数据库操作还行,但是对于有着复杂业务逻辑的应用显然是不适用的。

Re: REST的意义何在? by Zhang Gavin

是的,尤其是用户一个动作触发多个业务逻辑时,REST就很难解决

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT