SOAP 或 REST 作为客户端
我从 Web 服务本身的开发中看到很多问题，询问 SOAP 或 REST 哪个更好。然而，从客户的角度来看，没有太多关于利弊的讨论。如果您要编写一个应用程序，并需要在两个 Web 服务 API 之间进行选择，这两个 API 在各方面都很相似，除了一个是 SOAP，另一个是 REST，您会选择哪一个，为什么？ REST 的额外好处是允许 XML 或 JSON，两者之间还有其他主要区别吗？
I see multiple questions asking which is better, SOAP or REST from the development of the Web Service itself. However, not a lot of discussion of the pros/cons from the client perspective. If you were to write an Application and have a choice between two Web Service APIs that are similar in every way except one is SOAP and the other is REST, which would you choose and why? REST has the added benefit of allowing either XML or JSON, is there any other major difference between the two?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
哇，10个小时了，这个问题到目前为止还没有答案。通常这些类型的问题会立即被提出。
无论如何，这是对你的问题的有点奇怪的答案。选择应该取决于几个因素：
无论哪一个 API 具有更好的文档，都可能是更适合使用的 API。虽然不能保证这一点，但它是一个很好的指标。 SOAP 是否比 REST 更好并不重要，反之亦然，如果实现是垃圾，那么无论哪种方式你都会遭受损失。
如果这是一个由初创公司创建的全新 API，并且可能在明年发生显着发展，那么 REST API 可能会更容易管理。 SOAP api 往往非常脆弱，并且由于生成的客户端代理代码而需要频繁的客户端重新编译。
尽管我讨厌客户端生成的代理代码有 1001 个原因，但如果您需要让某些东西真正快速地工作的话。将您最喜欢的 IDE 指向 WSDL 块将很快为您提供一个可以使用的对象模型。这绝对是让某些事情发挥作用的最快方法。
如果客户端会存在很多年，那么我相信值得投入时间来开发一个好的 REST 客户端。基于 REST 的方法对于随着时间的推移而发生的不可避免的变化更具弹性。 REST 客户端版本比基于 SOAP 的客户端有更多选择。
最后一项是 REST API 是否是真正的 REST 接口的试金石。如果文档是 http 端点的目录，那么您可以非常确定设计者不知道 REST 是什么，因此请远离它。
Wow, 10 hours and no answer so far to this question. Usually these types of questions are jumped on in an instant.
Anyway, here is bit of strange answer to your question. The choice should depend on a few things:
Whichever API has the better documentation is likely to be the better API to use. This is not guaranteed, but it is a good indicator. It does not matter whether SOAP is better than REST or vice versa if the implementation is garbage you are going to suffer either way.
If this is a brand new API, created by a startup, that is likely to evolve significantly over the next year then a REST api will likely be easier to manage. SOAP apis tend to be pretty brittle and require frequent client recompilations due to the generated client proxy code.
Despite the 1001 reasons why I hate client generated proxy code, if you need to get something working really quick. Pointing your favorite IDE at chunk of WSDL will very quickly get you an object model to play with. It is definitely the fastest way to get something working.
If the client is going to be around for a number of years then I believe it is worth investing the time into producing a good REST client. A REST based approach is much more resilient to the inevitable changes that will occur over time. There are also much more options when it comes to version REST clients than SOAP based ones.
The last item is a bit of litmus test for whether the REST API is a real REST interface or not. If the documentation is a catalog of http endpoints then you can be pretty much assured that the designers don't know what REST is, so stay away from it.
你做出了一个有缺陷的假设。
你说：
说实话，SOAP API 很可能与 REST 系统完全不同，因此您无法在这个级别进行真正的比较。
REST 是一种架构，而不是一种协议。 SOAP 是一种协议，但不是一种体系结构。虽然可能，但您不太可能在 SOAP 协议之上创建 REST 架构，因为 SOAP 有效负载无法为 REST 系统提供很多功能。
SOAP 系统往往更多地基于 RPC，而 REST 系统则基于资源。两者在操作和设计上的差异很大。
就使用 SOAP 与基于 HTTP 的 XML/JSON（许多人错误地将其与 REST 混为一谈）而言，SOAP 系统的主要好处是可使用工具来使系统的接口和发布变得更加容易。
如今，许多 IDE 和服务器都可以轻松发布和使用 SOAP Web 服务。
在 Java 中，发布 SOAP 接口只不过是将“@WebService”粘贴到文件中并部署它。使用 Web 服务只不过是将 IDE 指向 WSDL（在发布 Web 服务时为您方便地创建），单击按钮，然后让工具创建编组数据并与服务通信所需的代理。
基于 HTTP 的 XML/JSON 的一个好处是您可能会跳过许多使 SOAP 自动化变得“容易”的样板。当然，Javascript 非常擅长使用 JSON，因此如果您的客户端空间包含 Web 浏览器，这可能是一个因素。
归根结底，如果您通过浏览器与服务器进行对话，HTTP 上的 XML/JSON 工作得很好，那么实际的 REST 架构也可以很好地工作。
如果您谈论的是服务器之间的 RPC，那么由于目前可用的工具，SOAP 更容易实现。
You're making a flawed assumption.
You say:
The truth be told, a SOAP API will very likely be completely different from a REST system, so you can't really compare at this level.
REST is an architecture, not a protocol. SOAP is a protocol, but not an architecture. While possible, it's unlikely you would create a REST architecture on top of the SOAP protocol, as the SOAP payloads don't offer a lot to a REST system.
SOAP systems tend to be more RPC based, REST systems are Resource based. The difference is significant between these two, operationally and in design.
As far as using SOAP vs XML/JSON over HTTP (what many people mistakenly conflate with REST), the primary benefit of a SOAP system is the tooling available to make interfacing to and publishing from systems much easier.
Today, many IDEs and servers can readily publish and consume SOAP web services.
In Java, publish a SOAP interface can be little more that sticking "@WebService" in a file and deploying it. Consuming a web service little more than pointing the IDE at a WSDL (conveniently created for you when the web service is published), clicking a button, and having the tools create the proxies necessary to marshal data and communicate with the service.
XML/JSON over HTTP has a benefit that you will likely skip much of the boiler plate that makes automating SOAP "easy". Javascript, of course, is quite adept at consuming JSON, so if you're client space includes Web Browsers, that can be a factor.
Boiled down, if you talking Browser to Server, XML/JSON over HTTP works pretty well, an actual REST architecture can work well as well.
If you're talking RPC between servers, then SOAP is much easier to implement because of the tooling available today.