REST 与 SOAP 的可演化性
我得到了更改链接 uri 的好处，但这实际上不是这个问题的目的。
我所说的可进化性是指向服务添加新功能或修改（如果可能）现有功能，实际上就是这样。
SOAP 并没有那么糟糕，因为 REST 社区在谈到可演化性时往往会谈论它。例如：
- 在 REST 中我们可以添加新的相关 - 在 SOAP 中我们可以添加新的方法。两个都 类型的老客户将继续使用新服务。
- 在 REST 中，我们可以添加新的表单字段并设置其默认值 - 在 SOAP 我们可以将服务参数作为某些 ServiceArgs 类，并且 向 ServiceArgs 添加新字段。这很丑陋，但它有效。
当 SOAP 客户端崩溃而您无能为力，而 REST 客户端却可以优雅地处理这种情况时，有哪些可演化性示例？
谢谢！
I get the benefits of changing link uris, but that's really not what this question is about.
What I mean by evolvability is adding new features to a service or modifying (when possible) existing ones and that's actually it.
SOAP isn't that bad as REST community tends to talk about it when it comes to evolvability. For example:
- In REST we can add new rel - in SOAP we can add new method. Both
types of old clients will continue working with new services. - In REST we can add new form field and set its default value - in
SOAP we could have service arguments as some ServiceArgs class and
add a new field to ServiceArgs. That's ugly, but it works.
What are the evolvability examples when SOAP clients break and you can do nothing about it, while REST clients are handling the situation gracefully?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SOAP 是一种基于契约的技术。整个客户端/服务器交互都被编写并编入一个大文档（
WSDL）中，并且必须得到双方的同意和尊重才能正常工作。如果任何一方决定添加功能，另一方必须与之同步“发展”。双方完全结合，齐头并进，粘在一起，永远结婚。增强 SOAP 服务的典型方法是为新版本的服务创建新的 WSDL 文档，同时维护旧版本。另一种技术是创建一个新接口来包含新方法并继承旧方法。您在 #1 中描述的方法在 IMO 中违反了 SOAP 规则，因为客户端和服务器现在将使用不同的合约，并且它之所以有效，是因为附加更改（例如新方法）可以被硬塞在其中大多数时候事情都会成功。一旦有人做出破坏性更改，客户端的合同将与服务器的合同不匹配，游戏就结束了。这是一个难以管理的过程，这就是为什么大多数组织选择为每个新版本的 API 创建全新的 WSDL。
REST 并不能神奇地消除所有这些问题，但它不强迫您将整个分布式系统的“契约”捆绑到一个工件中，从而使事情变得更容易管理。你使用的是HTTP吗？太好了，那么您就可以使用 Web 所使用的所有精彩 HTTP 功能：代理服务器、URL、内容协商、身份验证等。您想使用 JSON 编码和 XML 进行通信吗？把自己打垮。任何时候在 REST 中执行都很简单，不会影响现有客户端。你想要安全感吗？好吧，开始使用 HTTP 的内置支持来挑战经过身份验证的凭据。所有这些东西（HTTP、JSON 等）都是标准化的，并在不同的地方进行描述，这正是它应该的样子。
SOAP 将传输协议、位置信息、有效负载描述、编码选择和 RPC 方法合并到一个巨大的文档中。如果您想对该列表中的任何内容进行任何更改，则需要一个新文档。更糟糕的是，有些事情根本无法改变。
REST 将这些东西分开，以便各个部分可以独立发展。您的 URL（或更准确地说是“URI”）会在运行时返回，并假设客户端
有听过这样的笑话吗：保时捷车主只要烟灰缸满了就买一辆新车？这就是 SOAP。本来应该是微不足道的改变需要进行重大改革。 REST 为您提供吸尘器。您不必使用它，但它肯定更便宜。
SOAP is a contract-based technology. The entire client/server interaction is written up and codified in a big document (the
WSDL) and must be agreed upon and honored by both sides in order for things to work. If either side decides to add features, the other side must "evolve" in lock-step with it. Both sides are completely coupled, joined at the hip, glued together, married, for ever.The typical approach to enhancing your SOAP services is to create new WSDL documents for the new versions of the service, while also maintaining the older ones. Another technique is to create a new interface to contain new methods and inherit from the old one. The approach you describe in #1 is IMO breaking the SOAP rules, because the client and server will now be using different contracts and it only works because additive changes (like new methods) can be shoe-horned in and most of the time things will work. The moment someone makes a destructive change then the client's contract will not match the server's and it's game over. It's a difficult process to manage, which is why most organizations opt to create entirely new WSDL for each new version of the API.
REST doesn't magically make all of these problems go away, but it makes things easier to manage by not forcing you to bundle your entire distributed system's "contract" into one artifact. You're using HTTP? Great, then you get to use all of the wonderful HTTP features that the web uses too: proxy servers, URLs, content negotiation, authentication, etc. You want to communicate using JSON encoding as well as XML? Knock yourself out. It's trivial to do in REST at any time, without affecting existing clients. You want security? Fine, start challenging for authenticated credentials using HTTP's in-built support for exactly that. All of these things (HTTP, JSON, etc) are standardized and described in different places and that's exactly how it should be.
SOAP combines the transmission protocol, location information, payload description, encoding choice and RPC methods into one ginormous document. If you want to make any change to anything in that list, you need a new document. Worse still, some of those things can't be changed at all.
REST separates those things out so that the pieces can evolve independently. Your URLs (or "URIs", to be more precise) are returned at runtime and assuming the client doesn't start to hardcode them are evolvable without any changes needed to the client. Additive changes to your media types are trivial if your documentation makes it clear that new fields may appear in the future. You've also got the option of versioning your media types, allowing the co-existence of v1/v2/v3... media types within your system, and the client can pick (using the
AcceptandContent-Typeheaders in HTTP) which one they want to use.Ever heard the joke about the Porsche owner who buys a brand new car whenever the ashtray gets full? That's SOAP. What should be a trivial change requires a major overhaul. REST gives you the vacuum cleaner. You don't have to use it, but it sure is cheaper.