写点什么

REST-* 组织

  • 2009-09-28
  • 本文字数:2095 字

    阅读完需:约 7 分钟

JBoss 已在月初的 JBoss 世界大会上正式宣布了它的新项目“ REST-* ”。

REST-* 试图从以下几个方面将自己和 WS-* 区别开:

WS-* 是一组很好的规范,它们定义了实现基于网络的中间件服务所需要的各种协议和信封格式。尽管比起 CORBA 它已有很大进步,然而它仍然存在一些缺点,而这些缺点正是 REST-* 试图解决的。主要是:

**WS-* 不利用 HTTP:**WS-* 使用 HTTP 作为传输协议。WS-* 服务主要使用 HTTP 作为连接建立的机制,却忽视了其它丰富且久经考验的特性,而正是这些特性促使了 Web 的成功……由于我们集中关注 RESTful 原则,所以我们提出的规范将会完全利用 HTTP 协议的优势,而不是重新发明自己的技术。

**WS-* 入门的门槛高:**WS-* 协议栈难于实现,并且,客户端和服务端都要使用复杂的协议栈……我们希望最大限度地降低这套规范的入门门槛。

**WS-* 依赖于信封格式:**WS-* 协议栈依赖于 SOAP,所有 WS-* 发送的消息都要遵循信封格式……而 HTTP 消息已经足够完善,它很简单、健壮、而且非常灵活。

该项目的架构目标是:

低入门门槛:对使用该规范的用户,入门门槛应该足够低。他们应该不需要为了使用规范而安装任何库或者软件包……

通过扩展去描述边界情况:边界情况可能是使得主规范变得复杂的原因之一,它应该描述在一个独立的子规范中,并将它们放在主规范之上。

实用 REST:当某规范致力于遵循 RESTful 原则时,简单性的要求绝不该让步于纯粹的 RESTafarian。如果你要使用 REST 的原则创建更简单的设计,那么这就是你应选择的路。

80/20 原则:规范应该保持简单……它应该覆盖 80% 的常用情况,而边界情况不应该出现在主规范之中……

避免信封格式:只要有可能,就应该避免信封格式……信封格式倾向于在 HTTP 上打通一个隧道,而不是直接利用 HTTP……大多数情况下,HTTP 头在传输请求,响应和资源的元数据方面已经足够。

不要扩展数据格式:如果可能,规范就不应该定义新数据格式

根据大会的宣布,JBoss 试图建立一个类似于 JBoss.org 的完全协作的社区,而不是由提供商驱动,为提供商服务的社区 。他们设想着通过开源的方式:

……定义新协议……但是整个这事情的重点之一是记录人们以 RESTful 方式工作(包括 HTTP 和非 HTTP)的指导意见和最佳实践,这可能包含安全,管理等。

(顺便提一下,上述引自 Mark Little 的一段话已经相悖于前面提到的架构目标,因为他提到新协议以及非 HTTP 的支持。)

Mark 认为:

如果最后我们的结果的是一个聚集器,包含指向解决这些那些问题的“标准”方式,那么这已经是一个成功的产出了……开展该工作的原因是因为社区需要它。人们不断提出相同的问题, 虽然有很多书,以及该领域的专家回答了问题,但却没有清晰的答案。在某些情况下,我们可能得到许多不同的答案。这意味着答案不存在吗?不然。然而如果是真正理解 REST 的人都不同意的答案,对于那些只求使用 REST 的人来说有何意义呢?这就是 REST-* 要做的:将社区联系起来,试图产出一些指导原则,当人们需要答案时就有地方可以找到它。

尽管这个新项目试图远离 REST 和 WS 的争论:

REST 和 WS-* 孰优孰劣已经在很多文章,博客以及公开邮件列表中争论了很久。这里我们不想再重述那些争论,欲了解更多信息,请在 Google 上搜索“REST vs. WS-*”

不过,它还是通过引用 WS* 的一些特性有效地进行了比较,比如,它试图表达 WS* 很重,而 REST 是轻量级的。然而,两种标准都可以“手动”实现,(假定都是用 HTTP 传输的话,)所需的代码量是相同的。再者,一个支持自动混编 / 拆散以及消息路由的运行时,所包含的代码量也是相同的(比如,RestEasy——它是一款不错的框架,发布版只包含 38 个 jar 包)。如果在相同抽象层进行比 较的话,所需的代码两是相同的。讨论该问题的邮件列表还在继续。

因此,毫无疑问,REST* 的宣布引起了很多回复,Steve Jones 在他的博文 REST-*,你能否快成熟中总结得很 好:

REST-* 项目的最后产出可能是记录现有的经验,这其中的挑战之一是,很多人并没有真正理解 REST 是什么,所以当他们要构建更高层的类系统以及实现跨组织间的互操作时,自然会很痛苦 。一部分原因当然来自预付款协议以及迟早验收等方面的问题,但还有一部分原因看起来像是纯粹的势利或者是某些人不愿意分享那些晦涩的知识。

他继续说道:

如果 REST 是达摩克里斯之剑,能够洞穿现今企业集成的挑战的话,那么记录下这是如何实现的以及相关标准(使让人们更清楚地了解如何进行开发)有什么问题呢?更重要地,人们(比如 SAP 或 Oracle)可以通过标准的方式创建 REST 接口,使得服务可以很容易地被其他提供商的解决方案所使用。这个项目可以决定是否要用 WADL,以及 Atom 和 AtomPub 是否能覆盖所有的企业场景,或者最少包含所有那些重要的标准。(比如,我们不再要对应于于可恶的 WS-TX 的 REST-TX)

不论是 REST 还是 WS,都有其实际的应用场景。问题不应该是哪个更为优越,而应该是他们如何共存,以及在特定场景下谁更合适。另一个重要的方面是不管它们多强大,都要确保所进行的比较是基于有缺点的, 而不是信仰。WS* 创建了很多有价值的标准和模式,那想想这些模式能否能应用于 REST 是否更有意义呢?


查看英文原文: REST-*.org

2009-09-28 08:422052
用户头像

发布了 184 篇内容, 共 79.2 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

优秀程序员都在注意的十个点

好好学习,天天向上

Java 设计模式 代码 技巧

第三课作业

杰语

架构实战营 模块三:学习总结

👈

架构实战营

MySQL索引原理浅析

逸少

MySQL 索引结构 索引

架构实战营 - 模块三总结

凯迪

架构实战营

作业三架构设计文档

大肚皮狒狒

【LeetCode】制作 m 束花所需的最少天数Java题解

Albert

算法 LeetCode 5月日更

架构实战营模块三作业

冷大大

作业 架构实战营 模块三

架构实战训练营 - 模块三课后作业

Johnny

架构实战营

架构实战营 - 模块三作业

凯迪

ARTS - week 8 补打卡

steve_lee

架构训练营——模块2作业

圆心角

架构训练营模块3作业《消息队列架构设计文档》-江哲

江哲

初识Golang之err概述

Kylin

Go 语言 5月日更

架构师实战营 模块三作业(基于自研集群 + MySQL 存储的消息队列系统架构设计文档)

好吃不贵

业务架构

服务器又被挖矿了,怎么防?

运维研习社

挖矿 5月日更 Linux安全

架构实战营 模块三课后作业

iProcess

架构实战营

消息队列详细设计架构文档

Hesher

架构 MQ Architecture 消息队列 架构实战营

假如只剩下canvas标签

执鸢者

大前端 canvas

自研集群 + MySQL 存储详细架构文档

@oo?金樱子

前端百题斩[001]——typeof和instanceof

执鸢者

面试 大前端

applet跨域访问安全性问题(java.security.AccessControlException:access denied)

xcbeyond

跨域 5月日更 疑难杂症

霸气!这份清华学霸整理的Java线程池笔记,2小时从入门到入坟

飞飞JAva

Java

自研集群+MySQL架构设计文档模板

9527

架构实战营

GreenPlum的CURD

数据社

greenplum 5月日更

消息中间件详细架构设计文档

白发青年

架构实战营

架构实战营-模块3-作业

笑春风

模块三作业 - 消息队列系统架构设计文档

青鸟飞鱼

架构实战营

一文看懂 Go 的数据类型

Rayjun

Go 语言

模块3作业 3

杨彬

#架构实战营

挖矿探索一:狗狗币-mac普通电脑

程序员架构进阶

比特币 区块链 28天写作 5月日更

REST-*组织_SOA_Boris Lublinsky_InfoQ精选文章