Nak*_*ran 1586
关于SOAP和REST的简单说明
SOAP - "简单对象访问协议"
SOAP是一种通过Internet传输消息或少量信息的方法.SOAP消息以XML格式化,通常使用HTTP(超文本传输协议)发送.
休息 - 代表性的国家转移
Rest是在客户端和服务器之间发送和接收数据的简单方法,它没有定义很多标准.您可以以JSON,XML甚至纯文本的形式发送和接收数据.与SOAP相比,它重量轻.
- SOAP不仅仅是在信封中发送数据.但是,它主要用于向服务器发送BLOB,忽略SOAP也提供的任何功能.所以基本上,大多数人使用像REST一样的SOAP和标准信封.(SOAP是过度工程的一个很好的例子) (73认同)
- 对于每个复杂的问题,都有一个清晰,简单和错误的答案.--HL Mencken (55认同)
- 继续阅读.虽然这个答案很有趣,但@ Pavel的答案更为完整. (17认同)
- SOAP不会强迫一个人使用HTTP或XML.HTTP和XML是WS-I中为互操作性定义的内容,但也可以通过JMS发送POJO.问题是,程序员不需要关心:服务总线管理传输和编码. (14认同)
- 这个例子是史诗般的! (5认同)
- 公平地说,这个家伙确实要求用"简单的英语"来表达.这与人们可以得到的一样简单.好有趣的答案. (2认同)
Bri*_*ndy 321
这两种方法都被许多大型玩家使用.这是一个偏好问题.我的偏好是REST,因为它更易于使用和理解.
简单对象访问协议(SOAP):
- SOAP在HTTP或有时TCP/IP之上构建XML协议.
- SOAP描述了函数和数据类型.
- SOAP是XML-RPC的后继者,非常相似,但描述了一种标准的通信方式.
- 有几种编程语言对SOAP有本机支持,您通常会将其提供给Web服务URL,您可以在不需要特定代码的情况下调用其Web服务功能.
- 发送的二进制数据必须首先编码为base64编码格式.
- 有几个与之相关的协议和技术:WSDL,XSD,SOAP,WS-Addressing
具象状态转移(REST):
- REST不需要通过HTTP,但我的下面的大多数点都会有HTTP偏差.
- REST非常轻量级,它说等一下,我们不需要SOAP创建的所有这些复杂性.
- 通常使用普通的HTTP方法而不是描述所有内容的大型XML格式.例如,要获取资源,请使用HTTP GET,将资源放在使用HTTP PUT的服务器上.要删除服务器上的资源,请使用HTTP DELETE.
- REST非常简单,因为它使用HTTP GET,POST和PUT方法来更新服务器上的资源.
- REST通常最适合与资源导向架构(ROA)一起使用.在这种思维模式中,一切都是资源,您将在这些资源上运作.
- 只要您的编程语言具有HTTP库,并且大多数编程语言都可以,您就可以非常轻松地使用REST HTTP协议.
- 可以根据请求简单地传递二进制数据或二进制资源.
我最喜欢的是这个.2013年11月27日更新:保罗·普雷斯科德的网站似乎已经脱机,本文不再可用,虽然可以在Wayback Machine上找到副本,但可以在CiteSeerX 上找到PDF .
- REST与HTTP无关(它与协议无关),在RESTful架构中使用XML也很好.GET/POST/PUT/DELETE只是正确使用HTTP - 这对REST来说是必要的,但还不够. (28认同)
- REST简单地说'使用统一的界面'.由于HTTP接口[GET,POST,PUT,DELETE,(UPDATE,HEAD)]成为Web的"统一接口",因此我认为REST(在Web上)在某种程度上依赖于HTTP! (14认同)
- REST客户端如何知道他可以使用哪些方法和类型？在SOAP中有WSDL,许多工具可以从中生成类和方法. (10认同)
- @jlp:REST客户端开发人员可以正确使用公开的REST接口. (3认同)
- @aehlke REST非常依赖于HTTP.否则说是疯了.REST方法通过HTTP RFC(由W3C TAG)稳固定义.除了加州大学欧文分校的罗伊菲尔丁博士论文之外,没有其他规范.请参阅:http://en.wikipedia.org/wiki/Representational_state_transfer (3认同)
- 嗨@Brenden,谢谢你的评论.你回应了我4年前写的东西 - 我同意它对HTTP的依赖. (3认同)
- http://zacstewart.com/2012/04/14/http-options-method.html - OPTIONS标头可用于帮助定义特定资源URL支持的动词. (2认同)
Pav*_*lov 257
休息
我理解REST的主要思想非常简单.我们已经使用了多年的Web浏览器,我们已经看到了网站的简易性,灵活性,性能等.HTML站点使用超链接和表单作为用户交互的主要方式.他们的主要目标是让我们的客户只知道我们可以在当前状态下使用的那些链接.REST简单地说'为什么不通过我们的应用程序使用相同的原则来驱动计算机而不是人类客户？' 将此与WWW基础架构的强大功能相结合,您将获得一个用于构建优秀分布式应用程序的杀手级工具.
另一种可能的解释是以数学方式思考人.每个应用程序基本上都是一个状态机,其业务逻辑操作是状态转换.REST的想法是将每个转换映射到对资源的某些请求,并为客户端提供表示当前状态中可用转换的链接.因此,它通过表示和链接对状态机进行建模.这就是为什么它被称为REpresentational State Transfer.
令人惊讶的是,所有答案似乎都集中在消息格式或HTTP动词使用上.事实上,消息格式根本不重要,REST可以使用服务开发人员记录的任何一种格式.HTTP谓词仅使服务成为CRUD服务,但尚未成为RESTful.真正将服务转变为REST服务的是超链接(也称为超媒体控件)与数据一起嵌入到服务器响应中,并且它们的数量必须足以让任何客户端从这些链接中选择下一个操作.
遗憾的是,除了Roy Fielding的论文外,在网上找到关于REST的正确信息相当困难.(他是派生REST的人).我会推荐"REST in Practice"一书,因为它提供了有关如何从SOAP演变为REST的全面分步教程.
肥皂
这是RPC(远程过程调用)架构风格的可能形式之一.从本质上讲,它只是一种允许客户通过服务边界(网络,进程等)调用服务器方法的技术,就好像它们调用本地方法一样.当然,它实际上不同于在速度,可靠性等方面调用本地方法,但这个想法很简单.
相比
在将任何形式的RPC与REST进行比较时,传输协议,消息格式,xsd,wsdl等详细信息无关紧要.主要区别在于RPC服务通过在RPC API中设计自己的应用程序协议来重新发明自行车,其语义只有它知道.因此,所有客户端必须在使用服务之前理解此协议,并且由于所有请求的专有语义,因此不能构建诸如高速缓存之类的通用基础结构.此外,RPC API不建议在当前状态下允许哪些操作,这必须从其他文档中获得.另一方面,REST意味着使用统一接口允许各种客户端对API语义有一定的了解,并使用超媒体控件(链接)来突出显示每个状态中的可用选项.因此,它允许缓存对扩展服务的响应,并且无需其他文档即可轻松发现正确的API使用情况.
在某种程度上,SOAP(与任何其他RPC一样)是试图隧穿服务边界,将连接媒体视为能够仅传输消息的黑盒子.REST决定承认Web是一个巨大的分布式信息系统,接受现实世界并学会掌握它而不是反对它.
当您控制服务器和客户端,并且交互不是太复杂时,SOAP似乎对内部网络API很有用.开发人员使用它更自然.但是,对于许多独立方使用的公共API,复杂而且大,REST应该更合适.但最后的比较非常模糊.
更新
我的经验意外地表明REST开发比SOAP更难.至少对于.NET.虽然有很好的框架,比如ASP.NET Web API,但是没有可以自动生成客户端代理的工具.没有什么比"添加Web服务引用"或"添加WCF服务引用"更像.必须手动编写所有序列化和服务查询代码.而且,那是很多样板代码.我认为REST开发需要类似于WSDL和每个开发平台的工具实现.事实上,似乎有一个好的理由:WADL或WSDL 2.0,但这些标准似乎都没有得到很好的支持.
更新(2016年1月)
事实证明,现在有各种各样的 REST API定义工具.我个人的偏好目前是RAML.
Web服务如何工作
嗯,这是一个过于宽泛的问题,因为它取决于特定Web服务中使用的体系结构和技术.但一般来说,Web服务只是Web中的一些应用程序,可以接受来自客户端的请求并返回响应.它暴露在网络上,因此它是一个网络服务,它通常全天候可用,这就是为什么它是一项服务.当然,它解决了一些问题(否则为什么有人会使用Web服务)为其客户.
- 到目前为止,这应该是最受欢迎的答案!我有一种幽默感,但是当StackOverflow上的喜剧答案特别重视时,它令人沮丧. (44认同)
- @TomHall我想这种情况有点特定于REST-RPC讨论,而不仅仅是SO.我想这就是我们没有合适的REST客户端工具的原因.至少在.NET上,实现REST服务客户端已证明比生成SOAP服务引用更困难.必须手动编写代理类.出于某种原因,人们认为REST好像根本就没有规则,而相反的原始想法则对架构施加了更多的限制.我希望社区了解REST - 然后我们可以期待更好的工具和采用. (3认同)
- @PavelGatilov 这个答案很棒。我读过其他 REST 解释，但从未“明白”驱动原则是可能的状态转换是响应的一部分。您花时间反思自己的经历并承认困难，这一事实对我们每个人都非常有价值。 (3认同)
Vin*_*hwa 39
这是您将找到的最简单的解释.
这篇文章以丈夫为妻的叙述,丈夫以纯粹的外行术语向妻子解释REST.必读!
我如何解释 - 休息给我的妻子(原始链接)
我怎么解释 - 休息给我的妻子(2013-07-19工作链接)
- 关于多态的部分是美丽的. (2认同)
cmd*_*cmd 37
SOAP - 简单对象访问协议是一种协议!
REST - REpresentational State Transfer是一种建筑风格!
SOAP 是一种用于传输消息的XML协议,通常通过HTTP传输
REST并且SOAP可以说是 不相互排斥的.RESTful架构可能使用HTTP或者使用SOAP其他通信协议.REST针对网络进行了优化,因此HTTP是一个完美的选择.HTTP也是Roy Fielding论文中讨论的唯一协议.
虽然REST和SOAP显然是非常不同的,但问题确实说明了这一事实,REST并且HTTP经常同时使用.这主要是由于HTTP的简单性以及它与RESTful原则的非常自然的映射.
基本REST原则
客户端 - 服务器通信
客户端 - 服务器架构具有非常明显的关注点分离.以RESTful样式构建的所有应用程序也必须是原始客户端服务器.
无状态
每个客户端对服务器的请求都要求完全表示其状态.服务器必须能够完全理解客户端请求,而无需使用任何服务器上下文或服务器会话状态.因此,所有州必须保留在客户端上.我们稍后将更详细地讨论无状态表示.
可缓存
可以使用高速缓存约束,从而使响应数据能够被标记为可高速缓存或不可高速缓存.标记为可缓存的任何数据都可以重用作对同一后续请求的响应.
统一界面
所有组件必须通过单一的统一接口进行交互.由于所有组件交互都通过此接口进行,因此与不同服务的交互非常简单.界面是一样的!这也意味着可以单独进行实现更改.这种变化不会影响基本的组件交互,因为统一的接口总是不变的.一个缺点是您遇到了界面.如果可以通过更改界面为特定服务提供优化,那么由于REST禁止此操作,您将失去运气.然而,从好的方面来看,REST针对Web进行了优化,因此REST在HTTP上非常受欢迎!
上述概念表示REST的定义特征,并将REST架构与Web服务等其他架构区分开来.值得注意的是,REST服务是一种Web服务,但Web服务不一定是REST服务.
有关REST和上述项目符号的详细信息,请参阅有关REST设计主体的此博客文章.
- 这是反映它不是/或REST和SOAP的最佳答案.+1注意到REST是*样式*. (2认同)
Dav*_*d G 12
我喜欢Brian R. Bondy的回答.我只想补充一点,维基百科提供了REST的清晰描述.本文将其与SOAP区分开来.
REST是一种状态信息交换,尽可能简单地完成.
SOAP是一种使用XML的消息协议.
许多人从SOAP迁移到REST的主要原因之一是与基于SOAP的Web服务相关联的WS-*(称为WS splat)标准非常复杂.请参阅维基百科以获取规格列表.这些规范中的每一个都非常复杂.
编辑:由于某种原因链接无法正确显示.REST = http://en.wikipedia.org/wiki/REST
WS-*= http://en.wikipedia.org/wiki/WS-*
- @koppor你的意思是它代表"简单对象访问协议"这个事实？另外,你知道协议是什么吗？协议基本上是关于两个或多个事物应该如何通信的一组规则,这正是SOAP的用途,一种标准的通信方式. (15认同)
- 它仍然是一种消息传递协议. (12认同)
- @Demizey你是否提到最新版本的SOAP,即1.2？http://www.w3.org/TR/soap12-part1/"SOAP"现在独立,因为在实践中它不被用作协议."SOAP 1.2不会拼出首字母缩略词." (http://www.w3.org/TR/2007/REC-soap12-part0-20070427/#L4697)您是否了解Web服务堆栈的层(例如)在"Web服务平台架构"一书中所描述的:Soap,Wsdl,Ws-Policy,Ws-Addressing,Ws-Bpel,Ws-Reliable Messaging等等？传输层通信通过HTTP,SMTP,RMI/IIOP,JMS或其他方式完成.SOAP用于消息传递层 (4认同)
SOAP Web服务和REST Web服务都可以使用HTTP协议和其他协议(只是提到SOAP可以是REST的底层协议).我将仅讨论与HTTP协议相关的SOAP和REST,因为这是它们最常用的方法.
肥皂
SOAP("简单"对象访问协议)是一种协议(和W3C标准).它定义了如何创建,发送和处理SOAP消息.
SOAP消息是具有特定结构的XML文档:它们包含一个包含标题和正文部分的信封.正文包含XML格式的实际数据 - 我们要发送.有两种编码样式,但我们通常选择文字,这意味着我们的应用程序或其SOAP驱动程序执行XML序列化和数据的反序列化.
SOAP消息作为HTTP消息传递,具有SOAP + XML MIME子类型.这些HTTP消息可以是多部分的,因此我们可以选择将文件附加到SOAP消息.
显然,我们使用客户端 - 服务器体系结构,因此SOAP客户端将请求发送到SOAP Web服务器,服务将响应发送回客户端.大多数Web服务使用WSDL文件来描述服务.WSDL文件包含我们要发送的数据的XML Schema(以下简称XSD)和WSDL绑定,它定义了Web服务如何绑定到HTTP协议.有两种绑定样式:RPC和文档.通过RPC样式绑定,SOAP主体包含带有参数(HTTP请求)或返回值(HTTP响应)的操作调用的表示.参数和返回值将根据XSD进行验证.通过文档样式绑定,SOAP主体包含一个针对XSD验证的XML文档.我认为文档绑定样式更适合基于事件的系统,但我从未使用过那种绑定样式.RPC绑定样式更为普遍,因此大多数人使用SOAP作为分布式应用程序的XML/RPC目的.Web服务通常通过询问UDDI服务器找到彼此.UDDI服务器是存储Web服务位置的注册表.
SOAP RPC
所以 - 在我看来 - 最流行的SOAP Web服务使用RPC绑定样式和文字编码样式,它具有以下属性:
- 它将URL映射到操作.
- 它使用SOAP + XML MIME子类型发送消息.
- 它可以有一个服务器端会话存储,没有约束.
- SOAP客户端驱动程序使用服务的WSDL文件将RPC操作转换为方法.客户端应用程序通过调用这些方法与SOAP Web服务进行通信.因此,大多数SOAP客户端都会因接口更改而中断(生成的方法名称和/或参数更改).
- 可以编写SOAP客户端,这些客户端不会因使用RDF的接口更改而破坏,并且通过语义查找操作,但语义Web服务非常少见,并且它们不一定具有非破坏客户端(我猜).
休息
REST(代表性状态转移)是一种建筑风格,在Roy Fielding 的论文中有所描述.它不像SOAP那样关注协议.它以没有约束的null体系结构样式开始,并逐个定义REST体系结构的约束.人们使用术语RESTful来实现所有REST约束的web服务,但根据Roy Fielding的说法,没有REST级别这样的东西.当Web服务不满足每个REST约束时,它就不是REST Web服务.
REST约束
- 客户端 - 服务器架构 - 我认为这部分对每个人都很熟悉.REST客户端与REST Web服务进行通信,Web服务在此后维护公共数据 - 资源状态 - 并将其提供给客户端.
- 无状态 - 缩写的"状态转移"部分:REST.客户端维护客户端状态(会话/应用程序状态),因此服务不能具有会话存储.客户端通过对服务的每个请求传输客户端状态的相关部分,这些服务响应资源状态的相关部分(由它们维护).因此请求没有上下文,它们总是包含处理它们的必要信息.例如,通过HTTP basic auth,客户端存储用户名和密码,并且每次请求都会发送它们,因此每次请求都会进行身份验证.这与仅通过登录进行身份验证的常规Web应用程序非常不同.我们可以使用任何客户端数据存储机制,如内存(javascript),cookie,localStorage等......如果需要,可以保留客户端状态的某些部分.无状态约束的原因是服务器可以很好地扩展 - 即使是非常高的负载(数百万用户) - 当它不必维护每个客户端的会话时.
- 缓存 - 响应必须包含有关它的信息,客户端是否可以缓存它.这进一步提高了可扩展性.
统一界面
- 资源标识 - REST资源与RDF资源相同.根据菲尔丁的说法,如果你可以命名,那么它可以是一种资源,例如:"当前的本地天气"可以是资源,或者"你的手机"可以是资源,或者"特定的网络文档"可以是资源.要识别资源,您可以使用资源标识符:URL和URN(例如书籍的ISBN编号).单个标识符应仅属于特定资源,但单个资源可以具有许多标识符,我们经常利用这些标识符,例如通过对URL等分页
https://example.com/api/v1/users?offset=50&count=25.URL具有一些规范,例如具有相同路径但不同查询的URL不相同,或者路径部分应包含URL的层次数据,并且查询部分应包含非分层数据.这些是如何通过REST创建URL的基础知识.顺便说一句.URL结构仅对服务开发人员有用,真正的REST客户端不关心它.另一个经常被问到的问题是API版本控制,这很简单,因为根据Fielding的说法,资源唯一不变的是语义.如果语义更改,则可以添加新版本号.您可以使用经典的3号版本控制,并仅将主要编号添加到URL(https://example.com/api/v1/).因此,通过向后兼容的更改没有任何反应,通过非向后兼容的更改,您将具有与新API根的非向后兼容语义https://example.com/api/v2/.所以老客户端不会破坏,因为他们可以使用https://example.com/api/v1/旧的语义. - 通过表示操作资源 - 您可以通过将资源的预期表示(以及HTTP方法和资源标识符)发送到REST服务来操纵与资源(资源状态)相关的数据.例如,如果要在结婚后重命名用户,则可以发送
PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}请求,其中该请求{name: "Mrs Smith"}是预期资源状态的JSON表示形式,换句话说:新名称.反之亦然,该服务向客户端发送资源表示以更改其状态.例如,如果我们想要读取新名称,我们可以发送GET https://example.com/api/v1/users/1?fields="name"检索请求,从而产生200 ok, {name: "Mrs Smith"}响应.因此我们可以使用此表示来更改客户端状态,例如我们可以显示"欢迎来到我们的页面太太史密斯!" 信息.资源可以有许多表示形式,具体取决于资源标识符(URL)或accept我们随请求发送的标头.例如,如果需要,我们可以发送史密斯夫人的图像(可能不是裸体)image/jpeg. - 自描述消息 - 消息必须包含有关如何处理它们的信息.例如URI和HTTP方法,内容类型标头,缓存标头,描述数据含义的RDF等......使用标准方法很重要.了解HTTP方法的规范很重要.例如,GET表示检索由请求URL标识的信息,DELETE表示要求服务器删除由给定URL标识的资源,依此类推...... HTTP状态代码也有规范,例如200表示成功,201表示已创建新资源,404表示在服务器上找不到所请求的资源等...使用现有标准是REST的重要组成部分.
超媒体作为应用程序状态的引擎(以下称为HATEOAS) - 超媒体是一种可以包含超链接的媒体类型.通过网络,我们遵循链接 - 通过超媒体格式(通常是HTML)描述 - 来实现目标,而不是在URL中键入URL.REST遵循相同的概念,服务发送的表示可以包含超链接.我们使用这些超链接向服务发送请求.通过响应,我们可以获得数据(可能还有更多链接),我们可以使用它来构建新的客户端状态,等等...这就是为什么hypermedia是应用程序状态(客户端状态)的引擎.您可能想知道客户如何识别并遵循超链接？通过人类它非常简单,我们读取链接的标题,可能填充输入字段,然后只需单击一下.通过机器,我们有(通过添加语义与RDF链接JSON-LD与九头蛇)或超媒体的具体解决方案(例如IANA链接关系和供应商特定的MIME类型由HAL + JSON).有许多机器可读的XML和JSON超媒体格式,只是它们的简短列表:
有时很难选择......
- 资源标识 - REST资源与RDF资源相同.根据菲尔丁的说法,如果你可以命名,那么它可以是一种资源,例如:"当前的本地天气"可以是资源,或者"你的手机"可以是资源,或者"特定的网络文档"可以是资源.要识别资源,您可以使用资源标识符:URL和URN(例如书籍的ISBN编号).单个标识符应仅属于特定资源,但单个资源可以具有许多标识符,我们经常利用这些标识符,例如通过对URL等分页
- 分层系统 - 我们可以在客户端和服务之间使用多个层.他们都不应该知道所有这些附加层,只是它旁边的层.这些层可以通过应用缓存和负载平衡来提高可伸缩性,也可以实施安全策略.
- 按需代码 - 我们可以发回代码,将客户端的功能扩展到浏览器,例如javascript代码.这是REST唯一的可选约束.
REST webservice - SOAP RPC Web服务差异
因此,REST Web服务与SOAP Web服务(具有RPC绑定样式和文字编码样式)非常不同
- 它定义了一个统一的接口(协议的内部).
- 它将URL映射到资源(而不是操作).
- 它使用任何MIME类型(而不仅仅是SOAP + XML)发送消息.
- 它具有无状态通信,因此它不能具有服务器端会话存储.(SOAP对此没有约束)
- 它服务于超媒体,客户端使用该超媒体包含的链接来请求服务.(SOAP RPC使用WSDL文件中描述的操作绑定)
- 它不会因URL更改而中断,只能通过语义更改来实现.(不使用RDF语义的SOAP RPC客户端因WSDL文件更改而中断.)
- 由于其无状态行为,它比SOAP Web服务更好地扩展.
等等...
SOAP RPC Web服务不满足所有REST约束:
SOAP和REST均指的是不同系统相互通信的方式。
REST使用类似于浏览器与Web服务器之间的通信的技术来执行此操作：使用GET请求网页，在表单字段中进行POST等。
SOAP提供了类似的功能，但是通过来回发送XML块来完成所有工作。SOAP的另一个关键组件是WSDL，它是一个XML文档，描述了支持哪些功能和数据元素。WSDL可用于以编程方式“发现”受支持的功能以及生成编程代码存根。
我认为这很简单，我可以解释一下。请，欢迎任何人纠正我或补充这一点。
SOAP 是一种消息格式，用于断开连接的系统（例如通过互联网）交换信息/数据。它与来回传送的 XML 消息有关。
Web 服务传输或接收 SOAP 消息。它们的工作方式不同，具体取决于编写的语言。
| 归档时间： |
|
| 查看次数： |
277748 次 |
| 最近记录： |