logo标签列表

SOAP - 有什么用处？

restsoap
53
我的意思是，SOAP 到底有什么意义呢？
Web 服务已经存在了一段时间，而且似乎“SOAP”和“Web 服务”的术语在很长一段时间内是可以互换的。然而，对我来说，SOAP 总是笨拙和过于复杂。
然后 REST 出现了，突然之间 Web 服务变得有意义起来。
正如 Joel Spolsky 所说，给程序员一个 REST URL，他们就可以立即开始使用服务并理解它。
SOAP 被混淆在 WSDL 和海量冗长的 XML 后面，尽管是基于 Web 的，但你不能像访问 SOAP 服务一样简单地用 Web 浏览器访问它。
所以我的问题的本质是：
  • 有没有任何好的理由在某些情况下选择 SOAP 而不是 REST？
  • 你现在正在使用 SOAP 吗？如果接口是 REST，是否更好？
  • 我错了吗？
11个回答
12
正如Joel Spolsky所说，给程序员一个REST URL，他们就可以立即开始玩弄服务并找出其中的奥秘。而如果该服务有一个良好规范且可读的机器交互合同，则程序员将不必浪费时间去解决它。（这并不意味着WSDL / SOAP一定是良好实现规范合同的例子，但这正是WSDL的目的）
最初，SOAP是一种简单的协议，允许您向消息添加头，并具有对象实例与XML结构的标准映射。在消息中放置处理元数据简化了客户端代码，并意味着您可以非常简单地持久化和排队消息。
当我在2001年构建SOAP服务时，我从未需要过头部处理细节。这是在WSDL之前，当时通常使用GET获取信息和查询（与大多数声称为REST的应用程序没有任何区别； REST在使用超链接进行服务发现方面更具优势），并使用带有SOAP负载的POST执行操作。创建资源的那些操作将返回所创建资源的URL给客户端，而客户端随后可以GET资源。我认为导致SOAP失去重点的原因是WSDL使人们很容易只考虑RPC，而不是创建资源的操作。
6
是的，我在那个帖子中已经发表了我的观点。请到那里查看我的评论。 - Brian Campbell
6

我认为，SOAP可能更加“灵活”，但结果它太过复杂（你提到的WSDL对我个人来说总是一个绊脚石）。

我理解REST。它很简单。唯一的缺点可能是你只能针对单个资源执行这4个基本操作，这可能不完全符合你对数据的观点。

6
1
你能否转述一下你在这里链接的内容，以防链接失效？如果链接失效了，你的帖子将毫无意义。 - Tim Post
@tim - 已更新答案，提供了一个新链接，指向同样的内容并且可以正常访问。 - DanSingerman
链接已经失效了。也许重新表述会更有用；-) - Ian1971
谢谢。这是值得的。 - Ian1971
4
WSDL的目的是自动发现。其想法是您不必编写客户端代码，它将自动生成。
顺便说一句，超越WSDL的下一步是语义Web服务。
2
如果它可以，你就不会问这个问题了;-) - vartec
3
如果您不需要WS-*系列协议的功能；如果您不需要自描述服务；如果您的服务不能完全按照HTTP协议定义的资源进行描述；如果您不想为与服务的每次交互编写XML，并在此之后解析它；那么您需要使用SOAP。
否则，当然可以使用REST。
有关自描述服务的价值存在一些问题。当涉及到无法理解这个问题时，我的想象力无法帮助我。这是我的问题。尽管如此，我仍然认为，任何使用比“Hello, world”更复杂的服务的人都会知道让其他人编写接受参数、创建要发送到服务的XML、发送它、接收响应，然后将其转换回对象的代码是有价值的。
现在，我想RESTful服务可能不需要这样做；至少对于不处理复杂对象的RESTful服务来说可能不需要。即使是像http://www.earthtools.org/webservices.htm这样相对简单的服务（我已经将其用作调用RESTful服务的示例），也需要了解返回数据的结构。即使上述服务提供了XML模式——不幸的是它没有描述整个响应。有了这个模式，仍然需要手动处理XML，或者使用工具从模式生成可序列化的类。
当服务在WSDL中描述，并且您使用类似于Visual Studio中的“添加服务引用”或svcutil.exe程序或我忘记Eclipse中该命令是什么的工具时，所有这些都会为您完成。
如果您需要示例，请从EarthTools服务开始，然后转到任何其他具有更复杂消息传递的服务。
顺便说一句，还需要自我描述的另一件事是描述服务支持的消息传递模式和协议。如果唯一的选择是HTTP或HTTPS上的HTTP动词，则可能不需要此功能。如果使用WS-Security等内容，则情况会变得更加复杂。
HTTP并没有描述任何东西。它不描述消息的结构，可用的操作等等。它对于帮助创建客户端程序调用服务毫无作用。 - John Saunders
1
是的，那些并不是真正的例子。一个REST服务可以有API文档，描述它的工作原理。我使用过的每个SOAP服务也都需要API文档。那么SOAP在实践中到底能为你带来什么好处呢？如果可能，请举个例子加以说明。 - DanSingerman
如果一个“REST”服务提供application/xml或application/json格式的数据，并期望客户端事先知道这些格式，那么他们就错了。是的，我知道你可以给我展示1001个这种情况的例子。唉。 - Darrel Miller
@Darrel：使用WSDL的SOAP服务可以向客户端提供格式、安全需求以及可能返回的故障等知识。它不是轻量级的，但也不是为了轻量级而设计的。如果你需要轻量级，请使用REST。 - John Saunders
@Darrel：现在的运行时就是编译时。在MSDN上查找“CodeDom”。此外，像SSIS和Windows Workflow Foundation这样的工具通过读取WSDL来配置与Web服务通信的能力。这不是新鲜事，也不是火箭科学。 - John Saunders
显示剩余3条评论
2
-1：@Dan：SOAP和WS-*规范是W3C制定的，而不是WS-I（http://www.w3.org/TR/soap/）。 - John Saunders
@John，这样说是否正确：WS-*规范由OASIS/WSI推动，然后由W3C批准（或完善）？如果是这样的话，除非另一个团体采取主动，否则这些标准的新开发实际上已经结束了，对吗？ - Jeff Sternal
@Jeff：WS-I只是一个互操作性组织。我不认为他们与标准有任何关系。标准一直都是由W3C拥有的。 - John Saunders
你完全误读了这个。WS-I互操作性组正在并入标准化组织OASIS。如果有什么不同，那就是这表明互操作性问题已经足够成为主流，不再需要单独的组织来解决。 - John Saunders
2

我发现SOAP最适合在服务很可能被企业现成软件(COTS)消费时使用。由于SOAP/WSDL采用了明确定义的契约，大多数COTS软件包都内置了消费此类服务的功能。这使得BPM/工作流程工具等可以轻松地消费定义好的服务而无需定制。除此之外，对于应用程序，REST是我首选的Web服务实现。

1

我认为SOAP适合Java和.NET用户，他们可能更熟悉旧的CORBA和COM技术，对互联网技术了解较少。

REST也有一个主要的缺点：对于如何实际实现这样的系统几乎没有指导。你会发现许多公共的RESTful API的设计存在很大差异。事实上，许多违反REST的关键方面（例如使用GET进行操作或使用POST进行检索），并且在基本用法上存在分歧（POST/GET vs POST/GET/PUT/DELETE）。

1
我认为SOAP适合那些有工具支持的人。如果你知道自己没有支持，并且必须自己处理所有的XML或JSON处理，那么我可以理解你希望事情尽可能简单。但是，如果你可以使用工具，那么就必须有元数据提供给工具使用。 - John Saunders
0

SOAP是一种轻量级的基于XML的结构化协议规范，用于实现服务。它用于在分散、分布式环境中交换结构化信息。SOAP使用XML技术在任何传输层协议上交换信息。它独立于任何特定的编程模型和其他实现特定的语义。了解有关XML SOAP消息框架的更多信息。

基于XML的消息框架，具有以下特点： 1）可扩展：简单性仍然是SOAP的主要设计目标之一。SOAP定义了一个通信框架，允许以分层扩展的方式添加诸如安全性、路由和可靠性等功能。

2）互操作性：SOAP可以在任何传输协议上使用，例如TCP、HTTP、SMTP。SOAP今天为HTTP提供了明确的绑定。

3）独立性：SOAP允许任何编程模型，并且不与远程过程调用（RPC）绑定。SOAP定义了处理单个单向消息的模型。SOAP还允许任意数量的消息交换模式（MEP）。了解有关SOAP的更多信息。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接