Netflix 或 Twitter 风格的网络服务应该使用 REST 还是 SOAP? [英] Should a Netflix or Twitter-style web service use REST or SOAP?
问题描述
我实现了两个 REST 服务:Twitter 和 Netflix.两次，我都在努力寻找将这些服务公开为 REST 而不是 SOAP 的决定所涉及的用途和逻辑.我希望有人能告诉我我遗漏了什么，并解释了为什么 REST 被用作此类服务的服务实现.
I've implemented two REST services: Twitter and Netflix. Both times, I struggled to find the use and logic involved in the decision to expose these services as REST instead of SOAP. I hope somebody can clue me in to what I'm missing and explain why REST was used as the service implementation for services such as these.
实现 REST 服务比实现 SOAP 服务花费的时间无限长.所有现代语言/框架/平台都存在用于读取 WSDL 并输出代理类和客户端的工具.实现 REST 服务是手工完成的，并且通过阅读文档来获得它.此外，在实施这两项服务时，您必须猜测"什么会通过管道返回，因为没有真正的架构或参考文档.
Implementing a REST service takes infinitely longer than implementing a SOAP service. Tools exist for all modern languages/frameworks/platforms to read in a WSDL and output proxy classes and clients. Implementing a REST service is done by hand and - get this - by reading documentation. Furthermore, while implementing these two services, you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document.
为什么要编写返回 XML 的 REST 服务?唯一的区别是，使用 REST，您不知道每个元素/属性代表的类型 - 您需要自己实现它，并且希望有一天字符串不会出现在字段中你认为总是一个整数.SOAP 使用 WSDL 定义数据结构，因此这很简单.
Why write a REST service that returns XML anyway? The only difference is that with REST you don't know the types each element/attribute represents - you are on your own to implement it and hope that one day a string doesn't come across in a field you thought was always an int. SOAP defines the data structure using the WSDL so this is a no-brainer.
我听到有人抱怨说，使用 SOAP 会产生 SOAP Envelope 的开销".在这个时代，我们真的需要担心少量字节吗?
I've heard the complaint that with SOAP you have the "overhead" of the SOAP Envelope. In this day and age, do we really need to worry about a handful of bytes?
我听说过这样一种说法，即使用 REST，您只需将 URL 弹出到浏览器中即可查看数据.当然，如果您的 REST 服务使用简单身份验证或不使用身份验证.例如，Netflix 服务使用 OAuth，它要求您在提交请求之前对事物进行签名和编码.
I've heard the argument that with REST you can just pop the URL into the browser and see the data. Sure, if your REST service is using simple or no authentication. The Netflix service, for instance, uses OAuth which requires you to sign things and encode things before you can even submit your request.
为什么每个资源都需要一个可读"的 URL?如果我们使用工具来实现服务，我们真的关心实际的 URL 吗?
Why do we need a "readable" URL for each resource? If we were using a tool to implement the service, do we really care about the actual URL?
推荐答案
煤矿中的金丝雀.
我等这样的问题已经将近一年了.这一天不可避免地会到来，我相信在接下来的几个月里，我们会看到更多类似的问题.
I have been waiting for a question like this for close to a year now. It was inevitable that this day would come and I am sure we are going to see many more questions like this in the coming months.
警告标志
您说得完全正确，构建 RESTful 客户端比构建 SOAP 客户端需要更长的时间.SOAP 工具包带走了大量的样板代码，几乎不费吹灰之力就使客户端代理对象可用.使用 Visual Studio 之类的工具和服务器 URL，我可以在不到五分钟的时间内在本地访问任意复杂的远程对象.
You are absolutely correct, it does take longer to build RESTful clients than SOAP clients. The SOAP toolkits take away lots of boilerplate code and make client proxy objects available with almost no effort. With a tool like Visual Studio and a server URL I can be accessing remote objects of arbitrary complexity, locally in under five minutes.
返回 application/xml 和 application/json 的服务对客户端开发人员来说太烦人了.我们应该如何处理这些数据?
Services that return application/xml and application/json are so annoying for client developers. What are we supposed to do with that blob of data?
幸运的是，许多提供 REST 服务的站点也提供了一堆客户端库，以便我们可以使用这些库来访问一堆强类型对象.不过好像有点傻.如果他们使用 SOAP，我们可以自己对这些代理类进行代码生成.
Fortunately, lots of sites that provide REST services also provide a bunch of client libraries so that we can use those libraries to get access to a bunch of strongly typed objects. Seems kind of dumb though. If they had used SOAP we could have code-gen’d those proxy classes ourselves.
SOAP 开销，哈.这是致命的延迟.如果人们真的担心通过网络传输的多余字节数，那么 HTTP 可能不是正确的选择.你有没有看到用户代理头使用了多少字节?
SOAP overhead, ha. It’s latency that kills. If people are really concerned about the number of excess bytes going across the wire then maybe HTTP is not the right choice. Have you seen how many bytes are used by the user-agent header?
是的，您是否尝试过使用 Web 浏览器作为除 HTML 和 javascript 之外的任何其他内容的调试工具.相信我，这很糟糕.你只能使用两个动词，缓存不断地妨碍，错误处理吞噬了这么多信息，它一直在寻找一个该死的 favicon.ico.给我开枪吧.
Yeah, have you ever tried using a web browser as debugging tool for anything other than HTML and javascript. Trust me it sucks. You can only use two of the verbs, the caching is constantly getting in the way, the error handling swallows so much information, it’s constantly looking for a goddamn favicon.ico. Just shoot me.
可读的网址.只有名词，没有动词.是的，只要我们只进行 CRUD 操作并且我们只需要以一种方式访问对象的层次结构，这就很容易了.不幸的是，大多数应用程序都需要比这多一点的功能.
Readable URL. Only nouns, no verbs. Yeah, that’s easy as long as we are only doing CRUD operations and we only need to access a hierarchy of objects in one way. Unfortunately most applications need a wee bit more functionality than that.
即将到来的灾难
目前有大量开发人员正在开发与 REST 服务集成的应用程序，他们正在得出与您相同的结论.他们承诺了简单性、灵活性、可扩展性、可进化性和偶然重用的圣杯.网络本身的特性，怎么会出错.
There are a metric boatload of developers currently developing applications that integrate with REST services who are in the process of coming to the same set of conclusions that you have. They were promised simplicity, flexibility, scalability, evolvabilty and the holy grail of serendipitous reuse. The characteristics of the web itself, how can things go wrong.
然而，他们发现版本控制同样是一个问题，但编译器并不能帮助检测问题.随着数据结构的发展和 URL 的重构，手写客户端代码很难维护.仅围绕名词和四个动词设计 API 可能非常困难，尤其是 RESTful Url 狂热者会告诉您何时可以使用和不可以使用查询字符串.
However, they are finding that versioning is just as much of a problem, but the compiler doesn’t help detect issues. The hand written client code is a pain to maintain as the data structures evolve and URLs get refactored. Designing APIs around just nouns and four verbs can be really hard, especially with RESTful Url zealots telling you when you can and cannot use query strings.
开发人员会开始问，为什么我们要在同时支持 Json 格式和 Xml 格式上浪费我们的精力，为什么不只专注于一种格式并做得好呢?
Developers are going to start asking why are we wasting our effort on support both Json formats and Xml formats, why not just focus our efforts on one and do it well?
事情怎么会这么糟糕
我会告诉你出了什么问题.我们作为开发人员让营销部门利用我们的主要弱点.我们对灵丹妙药的永恒探索使我们看不到 REST 的真实面目.从表面上看，REST 似乎很简单.使用 Urls 命名您的资源并使用 GET、PUT、POST 和 DELETE.地狱，我们开发人员已经知道如何做到这一点，我们多年来一直在处理具有表和列以及具有 SELECT、INSERT、UPDATE 和 DELETE 的 SQL 语句的数据库.这应该是小菜一碟.
I’ll tell you what went wrong. We as developers let the marketing departments take advantage of our primary weakness. Our eternal search for the silver bullet blinded us to the reality of what REST really is. On the surface REST seems so easy and simple. Name your resources with Urls and use GET, PUT, POST and DELETE. Hell, us devs already know how to do that, we have been dealing with databases for years that have tables and columns and SQL statements that have SELECT, INSERT, UPDATE and DELETE. It should have been a piece of cake.
REST 的其他部分也有人讨论过，例如自我描述性和超媒体约束，但这些约束并不像资源识别和统一接口那么简单.在期望的目标是简单性的情况下，似乎增加了复杂性.
There are other parts of REST that some people discuss, such as self-descriptiveness, and the hypermedia constraint, but these constraints are not so simple as resource identification and the uniform interface. The seem to add complexity where the desired goal is simplicity.
这个经过淡化的 REST 版本在开发人员文化中以多种方式得到了验证.创建的服务器框架鼓励资源识别和统一接口，但没有做任何支持其他约束的事情.区分方法的术语开始浮出水面(HI-REST 与 LO-REST、企业 REST 与学术 REST、REST 与 RESTful).
This watered down version of REST became validated in developer culture in many ways. Server frameworks were created that encouraged Resource Identification and the uniform interface, but did nothing to support the other constraints. Terms started to float around differentiating the approaches, (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).
有些人大声疾呼，如果您不应用所有约束，那就不是 REST.你不会得到好处.没有半休息.但这些声音被贴上宗教狂热分子的标签，他们对自己宝贵的词被从默默无闻中偷走并成为主流而感到不安.嫉妒的人试图让 REST 听起来比实际更难.
A few people scream out that if you don’t apply all of the constraints it’s not REST. You will not get the benefits. There is no half REST. But those voices were labelled as religious zealots who were upset that their precious term had been stolen from obscurity and made mainstream. Jealous people who try to make REST sound more difficult than it is.
REST，这个词，肯定已经成为主流.几乎每个拥有 API 的主要网络资产都支持REST".Twitter 和 Netflix 是两个非常引人注目的公司.可怕的是，我只能想到一个具有自我描述性的公共 API，而真正实现了超媒体约束的只有少数.当然，像 StackOverflow 和 Gowalla 这样的网站在他们的回复中支持链接，但是他们的链接中有巨大的漏洞.StackOverflow API 没有根页面.想象一下，如果网站没有主页，该网站会有多成功！
REST, the term, has definitely become mainstream. Almost every major web property that has an API supports "REST". Twitter and Netflix are two very high profile ones. The scary thing is that I can only think of one public API that is self-descriptive and there are a handful that truly implement the hypermedia constraint. Sure some sites like StackOverflow and Gowalla support links in their responses, but there are huge gaping holes in their links. The StackOverflow API has no root page. Imagine how successful the web site would have been if there was no home page for the web site!
恐怕你被误导了
如果您已经做到了这一点，那么对您的问题的简短回答是那些 API(Netflix 和 Twitter)不符合所有限制条件，因此您将无法获得 REST api 应该带来的好处.
If you have made it this far, the short answer to your question is those APIs (Netflix and Twitter) do not conform to all of the constraints and therefore you will not get the benefits that REST apis are supposed to bring.
REST 客户端的构建时间确实比 SOAP 客户端要长，但它们不绑定到一项特定服务，因此您应该能够跨服务重用它们.以 Web 浏览器的经典示例为例.Web 浏览器可以访问多少个服务?订阅源阅读器怎么样?现在普通的 Twitter 客户端可以访问多少种不同的服务?是的，只有一个.
REST clients do take longer to build than SOAP clients but they are not tied to one specific service, so you should be able to re-use them across services. Take the classic example, of a web browser. How many services can a web browser access? What about a Feed Reader? Now how many different services can the average Twitter client access? Yes, just one.
REST 客户端不应该被构建为与单个服务交互，它们应该被构建来处理可以由任何服务提供的特定媒体类型.一个显而易见的问题是，您如何为提供 application/json 或 application/xml 的服务构建 REST 客户端.好吧，你不能.那是因为这些格式对 REST 客户端完全没用.你自己说的，
REST clients are not supposed to be built to interface with a single service, they are supposed to be built to handle specific media types that could be served by any service. The obvious question to that is, how can you build a REST client for a service that delivers application/json or application/xml. Well you can’t. That’s because those formats are completely useless to a REST client. You said it yourself,
你必须猜测"什么将穿过管道返回没有真正的架构或参考文档
you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document
对于像 Twitter 这样的服务，你是绝对正确的.但是，REST 中的自描述约束表示 HTTP 内容类型标头应准确描述通过网络传输的内容.传递 application/json 和 application/xml 不会告诉您有关内容的任何信息.
You are absolutely correct for services like Twitter. However, the self-descriptive constraint in REST says that the HTTP content type header should describe exactly the content that is being transmitted across the wire. Delivering application/json and application/xml tells you nothing about the content.
在考虑基于 REST 的系统的性能时，有必要放眼大局.在比较快速排序和 shell 排序时，谈论信封字节就像谈论循环展开.有些场景中 SOAP 可以表现得更好，有些场景中 REST 可以表现得更好.上下文就是一切.
When it comes to considering the performance of REST based systems it is necessary look at the bigger picture. Talking about envelope bytes is like talking about loop unwinding when comparing a quick-sort to a shell-sort. There are scenarios where SOAP can perform better, and there are scenarios where REST can perform better. Context is everything.
REST 通过非常灵活地支持哪些媒体类型以及对缓存提供复杂的支持，从而获得了很大的性能优势.尽管必须遵守几乎所有的限制条件，但缓存才能正常工作.
REST gains much of its performance advantage by being very flexible about what media types it supports and by having sophisticated support for caching. For caching to work well though nearly all of the constraints must be adhered to.
您关于可读网址的最后一点是迄今为止最具讽刺意味的.如果您真的遵守超媒体约束，那么每个 URL 都可以是一个 GUID，并且客户端开发人员在可读性方面不会有任何损失.
Your last point about readable urls is by far the most ironic. If you truly commit to the hypermedia constraint, then every URL could be a GUID and the client developer would lose nothing in readability.
URI 应该对客户端不透明这一事实是开发 REST 系统时最关键的事情之一.可读的 URL 对服务器开发人员来说很方便，结构良好的 URL 使服务器框架更容易分派请求，但这些是实现细节，不会对使用 API 的开发人员产生影响.
The fact that URIs should be opaque to the client is one of the most key things when developing REST systems. Readable URLs are convenient for the server developer and well structured URLs make it easier for the server framework to dispatch requests, but those are implementation details that should have no impact on the developers consuming the API.
Twitter API 甚至还没有接近 RESTful，这就是为什么您看不到在 SOAP 上使用它有任何好处的原因.Netflix API 更接近，但它使用通用媒体类型表明，即使不遵守单个约束也会对从服务中获得的好处产生深远的影响.
The Twitter API is not even close to being RESTful and that is why you are unable to see any benefit to using it over SOAP. The Netflix API is much closer but it’s use of generic media types demonstrates that failing to adhere to even a single constraint can have a profound impact on the benefits derived from the service.
这可能不全是他们的错
我对服务提供商做了很多倾销，但需要两个人才能以 RESTful 方式跳舞.一项服务可能会虔诚地遵循所有限制条件，而客户仍然可以轻松取消所有好处.
I’ve done a whole lot of dumping on the service providers, but it takes two to dance RESTfully. A service may follow all of the constraints religiously and a client can still easily undo all of the benefits.
如果客户端硬编码 url 以访问某些类型的资源，那么它会阻止服务器更改这些 url.任何基于隐式了解服务如何构建其 URL 的 URL 构造都是违规的.
If a client hard codes urls to access certain types of resources then it is preventing the server from changing those urls. Any kind URL construction based on implicit knowledge of how the service structures its urls is a violation.
对链接返回的表示类型进行假设可能会导致问题.根据 HTTP 标头中未明确说明的知识对表示的内容进行假设肯定会造成耦合，这将在未来造成痛苦.
Making assumptions about what type of representation will be returned from a link can lead to problems. Making assumptions about the content of the representation based on knowledge that is not explicitly stated in the HTTP headers is definitely going to create coupling that will cause pain in the future.
他们应该使用 SOAP 吗?
就我个人而言，我不这么认为.正确完成 REST 允许分布式系统长期发展.如果您正在构建的分布式系统的组件由不同的人开发并且需要持续多年，那么 REST 是一个不错的选择.
Personally, I don’t think so. REST done right allows a distributed system to evolve over the long term. If you are building distributed systems that have components that are developed by different people and need to last for many years, then REST is a pretty good option.
这篇关于Netflix 或 Twitter 风格的网络服务应该使用 REST 还是 SOAP?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
