问题频道,致力于打造生活常识、生活百科大全!
您的当前位置: 光学精密机械网

网友提问

RESTful Web Services到底是干什么的啊~

[ 关键字: ]

大体是什么?怎么总体把握它啊。。。

赞助商链接

REST(英文:Representational State Transfer,简称REST)描述了一个架构样式的网络系统,比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中,他是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中,REST相比于SOAP(Simple Object Access protocol,简单对象访问协议)以及XML-RPC更加简单明了,无论是对URL的处理还是对Payload的编码,REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准,而更像是一种设计的风格。
  REST (REpresentation State Transfer) 描述了一个架构样式的网络系统,比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中,他是 HTTP 规范的主要编写者之一。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
  Web service是一个平台独立的,低耦合的,自包含的、基于可编程的web的应用程序,可使用开放的XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。
  Web Service技术, 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件, 就可相互交换数据或集成。依据Web Service规范实施的应用之间, 无论它们所使用的语言、 平台或内部协议是什么, 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块, 可以执行具体的业务功能。Web Service也很容易部署, 因为它们基于一些常规的产业标准以及已有的一些技术,诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
    Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

网友回答

大致理解:就是一些接口。可以发布你得资源。
将资源层面的操作统一接口,便于其他管理软件、管理模块接入。具体如下:
通过统一资源抽象模型,实现了异构资源操作的归一性;
实现了资源访问入口的统一和封装;
实现了各类资源的集中管理;
实现资源管理操作的聚焦,以实现模块的最大化复用。
可以参考参考这个网站:http://www.36wu.com/Service.aspx
我发现,现在人们不再使用“web service”这一词汇了,人人使用“api”。 恐怕现在说“人们不再使用这个词汇了”还为时尚早,毕竟还是有很多地方使用它,如云和移动计算,cloud ide,以及社交网络等还在使用该词汇。leonard的观点应该是“这个词汇不再像以前用得那么频繁了”。 我注意到,人们所使用的词汇呈现交替现象,而现在“web service”一词已几乎匿迹了。当我说“web service”的时候,人们知道我在说什么,但是这让我感觉自己“out了!”就像执拗地在漫天“开源”的世界里使用“免费软件”一词。 他问到,这一微妙变化是否意味着业界一些根本性的、重要的事情的发生呢?同时,众所周知,rest支持者口中的”web service”是有别于soap社区所说的web service。那么,这些变化仅在rest社区发生吗?soap社区中“web service”一词使用频率的下降与ws-*使用的明显下降能够简单地挂上钩吗? 不过,leonard担心这种变化会不会带来问题? [我相信]人们在2007年左右不再说“web service”是有原因的,但是,将“api”作为一个通用的词汇将会导致软件产品的向更糟糕的方向发展。[……] 那么,“web service”一词真正消亡了?被“api”取代了?如果答案是肯定的,那么其隐含着什么呢?会不会因为“api”一词在web中(可能)带来的混淆而导致软件实现更差呢?leonard此文的一条评论说到: 我认为,api不能自描述。明显,并非所有的web service能做到这一点,但是至少它们有专门用于描述的标准格式。拿我经历的一件有趣的事来说吧,最近一家客户聘请我们使用其web service(不是api)开发一个应用。它们是soap,却是巴洛克式的,晦涩难懂。他们为何称其为“web service”而非“api”也许有其自己的理由。但是,我的确看到很多网站毫不遮掩地吹嘘他们的api。 所以,不存在绝对的黑与白,很多东西游走于中间的灰色地带。
RESTful Web Services是什么: REST的全称是Representation State Transfer,它描述了一种设计Web应用的架构风格,它是一组架构约束条件和原则,满足这些约束条件和原则的应用程序或设计就是 RESTful风格的。而符合RESTful风格的Web Services,就是我们所说的RESTful Web Services。
尽管REST在国内技术领域已算不上什么新鲜名词了,但是关于REST的中文资料并不多见。到目前为止,好像也就只有Roy Thomas Fielding博士论文的中译版。随着《RESTful Web Services中文版》的即将面世,这种REST中文资料奇缺的局面有望得到改善,该书也是目前国内出版的以REST为主题的第一本书籍。鉴于本书的原版也才于2007年5月出版,短短一年间就推出了中文版,不得不由人感叹国内出版社的效率。此外,由于出版商O'Reilly一贯的口碑,本书的质量自然令人期待。《RESTful Web Services》全书对以下3个问题进行了回答:什么是RESTful服务 如何设计和实现RESTful服务 RESTful服务的应用 什么是RESTful服务这是本书前3章的主题。在这部分,作者从客户端的角度对Web服务进行了介绍,并指出了RESTful服务的特别之处。在本书的第一章,《Programmable Web及其分类》。作者将常见的Web服务架构分成3类:REST式、面向资源的架构 RPC式架构 REST-RPC混合架构 决定Web服务属于哪种分类的秘密在于以下两个问题的答案:服务的方法信息是否出现在HTTP方法中? 服务的作用域信息是否出现在URI中? 两个极端的答案:全是和全否,分别对应REST式架构和RPC式架构。处于中间的则是REST-RPC混合架构。对于Programmable Web一词感觉陌生的读者也不必为此介怀,这是一种按Web使用者分类的方式。顾名思义,Programmable Web是指供程序使用的Web,与之对应的另一词Human Web,其使用者即为人类。但是严格的说,人类也是通过程序(如浏览器)来对Web进行浏览,因此,Human Web实际是Programmable Web的特例。本部分的其他两章分别对Web服务客户端的编写和RESTful服务特点进行了介绍,并举例说明了REST的一些重要概念:资源、表示、统一接口。如何设计和实现RESTful服务回答这个问题的第4~9章是本书的核心,而第4章《面向资源的架构(Resource-Oriented-Architecture,ROA)》则是该部分的核心。提出ROA的目的,作者在前言中已经说得非常清楚:我们通过制定这个面向资源的架构(ROA),把来自坊间传言(folklore)的经验提炼为Web服务设计的最佳实践(best practices)。作者这样描述ROA:ROA是一种把实际问题转换成REST式Web服务的方法:它令URI、HTTP和XML具有跟其他Web应用一样的工作方式,令人程序员们容易使用它。在这一章中,作者介绍了ROA的功能组成:资源 资源名称 资源的表示 资源间的连接 以及ROA的功能特性:可寻址性 无状态性 连通性 统一接口 本部分的后续章节谈到了ROA的实践,分别介绍了面向资源的服务设计、服务实现、REST和ROA的最佳实践,以及服务的技术构件。RESTful服务的应用作为本书的最后部分,第10~12章以每章一个专题的形式介绍了RESTful服务的应用。这些专题是:面向资源架构 VS 大Web服务 将Ajax作为REST客户端 REST式服务框架 对于第10章《面向资源架构 VS 大Web服务》,你或许会感到有些奇怪:只不过是架构的比较罢了,怎么算得上是专题应用?如果你认真地读过本书的前言,应该会看出些端倪。本章所讲的内容正是“应用REST”的前提:如何推荐REST?

赞助商链接