unREST是新的REST吗?

可以这么说,仅仅是提到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?

This entry was posted in SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s