BT

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

unREST是新的REST吗?

| 作者 Mark Little 关注 14 他的粉丝 ,译者 丁雪丰 关注 4 他的粉丝 发布于 2011年7月13日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

可以这么说,仅仅是提到REST这个词就能引起人们的两极分化。有段时间REST努力抗击WS-*浪潮,随后出现了一个巅峰,这就像一个障碍,REST开始走下坡路了,人们认为REST有好处但也许没有其他人想象的那么多。抵制对“REST拥护者(RESTafarians)”相信的东西照单全收的主要倡导者之一就是Jean-Jacques Dubray,他最近发表了一篇文章,讨论他所谓的unREST。JJ是这样开篇的:

自2007起,一小撮人告诉整个业界“Web”可以教会大家关于分布式计算的所有东西,我们之前所做的都是错的。四年过去了,我们只能说这一说法仍然未被证实。

JJ论证的核心是REST在设计时考虑了浏览器,任何试图脱离该上下文使用REST的做法无疑都是unRESTful的:

REST在设计时考虑了终端用户,操作用户代理:浏览器[...]。任何将REST原则应用于代理至服务器(agent-to-server)场景的软件的做法都是错的。[...]是时候该继续前进了,这种非常规思路的复杂性没有带来一点好处,反而降低了生产力,它强迫所有人手工编码那些在上一种分布式计算范式中唾手可得的东西。

用JJ的话来说,REST“并不适用于目前的问题”,“做到RESTless很酷”。这意味着什么呢?JJ列出了一些规则,包括:

  • 定义领域专用统一接口:“不要害羞,忘记那4个HTTP动词吧,甚至可以定义自己的动词:Query/Do/Notify/Synchronize就很不错。它意味着你Web API中的全部方法都是查询、动作、通知或同步请求类型的。”
  • 规定消息:对于需要相互通信的两个端点,它们必须要能理解所交换的消息。正如JJ所说的“能明确标明版本的消息定义对健康的API定义来说是必不可少的。消息可扩展性是让分布式计算运作的重要属性。”
  • 规定端点之间的契约,并保证它们被打上版本:端点之间的接口和它们交换的消息是契约的组成部分。JJ说把机器可读的契约变为只有人类可读的这种做法是行不通的,他相信其结果只能是浪费大量时间。“统一接口并不足以构成契约,它只是契约定义的基础部分。”JJ坚信要构建“一个健康的Web API消费者生态系统”的唯一途径就是使用机器可读的契约,为它们标上版本以保证契约的进化和重用。

归纳起来:JJ相信有了这3条规则我们就拥有了创建成功API的基础。他指出这篇文章并非基于自己的突发奇想,在过去的至少十年时间里他都在和基于Web的协议打交道,包括ebXML。你认同他的观点或是他最后的评论吗?

你可以自由选择unREST,暗地里嘲笑那些要求你对HTTP标头、“链接”、7个首字母缩写(译注:估计是REST API)惊叹不已的人,他们或许还会带着REST传道士的口吻说你其实并不理解REST。REST只是一个(恶)梦,unREST才是你想要做的。

随着人们越来越多地讨论REST,尤其是在这样的领域里,如果JJ是对的,那么要改变这些做法就为时已晚了,也有可能它们本身就已经是unRESTful的了?也许unREST正在回到那“糟糕的旧时代”?

查看英文原文:unREST as the new REST?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

7个首字母缩写 by shu nan

7个首字母缩写估计是HATEOAS

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT