最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

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:421908
用户头像

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

关注

评论

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

基于SVDD算法的半监督风控模型

索信达控股

算法 风控模型 半督导算法

gitlab-runner构建解决java缓存问题

ilinux

千万不要小瞧复杂度分析,代码详解复杂度的重要性

小Q

Java Python 学习 数据结构 算法

电脑数据恢复用哪款软件比较好

淋雨

EasyRecovery

HTTP与HTTPS,HTTPS更加安全。

喀拉峻

网络安全 安全 信息安全 HTTP

ShowMeBug 中如何科学的识别用户浏览器?

ShowMeBug

大前端 浏览器 WebRTC

ShowMeBug 黑科技丨一招快速实现架构绘图之鼠标同步

ShowMeBug

思维导图 实时同步 绘图库

腾讯安全推出御界NDR「横移检测版」,全面检测域渗透攻击

腾讯安全

第四范式OpenMLDB在金融风控数据库的计算优化实践

第四范式开发者社区

第四范式 开源技术 OpenMLDB datafun

网络篇夺命连环12问

冇先生

Apache Pulsar 在能源互联网领域的落地实践

Apache Pulsar

架构 云原生 Apache Pulsar 消息系统 用户案例 能源互联网

速看!从源码到实战,腾讯大牛纯手码48W字SpringCloud实战笔记

Java 编程 程序员 面试 SpringCloud

今天面了个腾讯拿38K出来的大佬,让我见识到了基础的天花板

收到请回复

Java 程序员 后端

如何在 MySQL / MariaDB 中导入导出数据,导入导出数据库文件、Excel、CSV

蒋川

MySQL 数据库 MariaDB 卡拉云

阿里内部疯传的分布式架构手册,轻松吊打小日子过的不错的面试官

编程 程序员 架构 分布式

腾讯云开源百万级服务发现和治理中心“北极星”,打造可持续微服务生态

科技热闻

绝绝子!美团大牛吐血整理总结“消息队列核心知识笔记”是真的吊

编程 程序员 MQ 队列

外包学生管理系统架构文档

Steven

架构实战营

FlyFish 1.0发布,新增4个可视化组件

云智慧AIOps社区

大前端 低代码 数据可视化

腾讯云数据库TDSQL首次登上财报!TDSQL在不同金融机构核心系统中的渗透率明显提升

科技热闻

架构实战营-模块三作业

无名

架构实战营 「架构实战营」

Aeron是如何实现的?—— Conductor

BUG侦探

Aeron Conductor

第三阶段总结

张靖

#架构实战营

腾讯Q3财报:腾讯企点服务超100万家企业,显著降低客服成本

科技热闻

无锡农商行王宗:敏态转型,实现科技引领业务的华丽转身

BoCloud博云

微服务 云原生

视频通信关键技术探索及实践

网易云信

音视频 通信云

❤️这应该是Postman最详细的中文使用教程了❤️(新手使用,简单明了)

六十七点五

软件测试 性能测试 Postman 自动化测试 接口测试

安全漏洞之经典上传漏洞

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

吐血整理:常用的大数据采集工具,你不可不知

小术晓术

大数据 数据采集

今日谈:数字信号常用编码、香农公式、信道复用技术

Regan Yue

计算机网络 网络工程师 11月日更

《大教堂与集市》

石云升

读书笔记 开源 11月日更

REST-*组织_SOA_Boris Lublinsky_InfoQ精选文章