REST 与 SOAP 的可进化性 [英] REST vs SOAP evolvability
问题描述
我得到了更改链接 uri 的好处，但这实际上不是这个问题的内容.
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 并没有那么糟糕，因为 REST 社区在谈到可进化性时倾向于谈论它.例如:
SOAP isn't that bad as REST community tends to talk about it when it comes to evolvability. For example:
- 在 REST 中我们可以添加新的 rel - 在 SOAP 中我们可以添加新方法.两个都类型的老客户将继续使用新服务.
- 在 REST 中，我们可以添加新的表单字段并设置其默认值 - 在SOAP 我们可以将服务参数作为一些 ServiceArgs 类和向 ServiceArgs 添加一个新字段.这很丑陋，但确实有效.
当 SOAP 客户端中断而您无能为力，而 REST 客户端正在优雅地处理这种情况时，可进化性示例有哪些?
What are the evolvability examples when SOAP clients break and you can do nothing about it, while REST clients are handling the situation gracefully?
谢谢！
推荐答案
SOAP 是一种基于合同的技术.整个客户端/服务器交互被编写并编码在一个大文档(WSDL)中，并且必须得到双方的同意和尊重才能使事情正常进行.如果任何一方决定添加功能，另一方必须与其同步进化".双方完全耦合，在臀部连接，粘在一起，结婚，永远.
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.
增强 SOAP 服务的典型方法是为服务的新版本创建新的 WSDL 文档，同时维护旧版本.另一种技术是创建一个新接口来包含新方法并继承旧方法.您在 #1 中描述的方法是 IMO 打破了 SOAP 规则，因为客户端和服务器现在将使用不同的合同，并且它只能起作用，因为附加更改(如新方法)可以硬塞进来大多数时候事情都会奏效.一旦有人做出破坏性更改，那么客户端的合同将与服务器的合同不匹配，游戏就结束了.这是一个难以管理的过程，这就是为什么大多数组织选择为 API 的每个新版本创建全新的 WSDL.
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 并没有神奇地让所有这些问题消失，但它使事情变得更容易管理通过不强迫您将整个分布式系统的合同"捆绑到一个工件中.你在使用 HTTP 吗?太好了，那么您还可以使用 Web 使用的所有精彩 HTTP 功能:代理服务器、URL、内容协商、身份验证等.您想使用 JSON 编码和 XML 进行通信吗?把自己打昏.随时在 REST 中做是微不足道的，而不会影响现有客户端.你想要安全吗?好的，开始使用 HTTP 的内置支持来挑战经过身份验证的凭据.所有这些东西(HTTP、JSON 等)都在不同的地方进行了标准化和描述，这正是它应该的样子.
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 将传输协议、位置信息、有效载荷描述、编码选择和 RPC 方法组合成一个庞大的文档.如果您想对该列表中的任何内容进行任何更改，您需要一个新文档.更糟糕的是，其中一些事情根本无法改变.
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 将这些东西分开，以便各个部分可以独立发展.您的 URL(或URI"，更准确地说)在运行时返回并假设客户端 不会开始对它们进行硬编码 无需对客户端进行任何更改即可进化.如果您的文档明确指出将来可能会出现新字段，那么对您的媒体类型进行额外的更改是微不足道的.您还可以选择对媒体类型进行版本控制，允许 v1/v2/v3... 媒体类型在您的系统中共存，并且客户端可以选择(使用 Accept 和Content-Type HTTP 中的标头)他们想使用哪个.
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 Accept and Content-Type headers in HTTP) which one they want to use.
听说过保时捷车主在烟灰缸装满时购买全新汽车的笑话吗?那就是肥皂.应该是微不足道的改变需要大修.REST 为您提供真空吸尘器.您不必使用它，但它肯定更便宜.
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.
这篇关于REST 与 SOAP 的可进化性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
