Netflix或Twitter风格的web服务应该使用REST还是SOAP？

我已经实现了两个REST服务：Twitter和Netflix。这两次，我都很难找到将这些服务作为REST而不是SOAP公开的决策所涉及的用途和逻辑。我希望有人能给我提供一些线索，让我知道我遗漏了什么，并解释为什么REST被用作此类服务的服务实现

实现REST服务比实现SOAP服务花费的时间要长得多。所有现代语言/框架/平台都可以在WSDL中读取并输出代理类和客户端。实现REST服务是手工完成的，并且通过阅读文档来实现。此外，在实现这两个服务时，由于没有真正的模式或参考文档，您必须“猜测”管道将返回什么

为什么要编写一个返回XML的REST服务呢？唯一的区别是，对于REST，您不知道每个元素/属性代表的类型-您可以自己实现它，希望有一天在您认为始终是int的字段中不会遇到字符串。SOAP使用WSDL定义数据结构，因此这是一个简单的问题

我听到有人抱怨说，用肥皂你就有肥皂信封的“开销”。在这个时代，我们真的需要担心一小部分字节吗

我听过这样一种说法，即使用REST，您只需将URL弹出到浏览器中即可查看数据。当然，如果您的REST服务使用简单或无身份验证。例如，Netflix服务使用OAuth，它要求您在提交请求之前对内容进行签名和编码

为什么每个资源都需要一个“可读”的URL？如果我们使用工具来实现服务，我们真的关心实际的URL吗

---

SOAP是一种面向对象的，远程过程调用技术堆栈。它的工作原理是在现有协议（HTTP）的基础上构建一个新的抽象

REST是一种面向文档的方法，它只使用现有协议（HTTP）的特性。“REST”只是一个时髦词——其概念是：只需按照设计的方式使用web即可

关于对问题的答复：

“实现REST服务比实现SOAP服务花费的时间要长得多。”

不，不可能无限长。如果您试图检索的内容已经是一个文档或文件，那么它实际上要快得多。例如，WMS（Web映射服务）的OGC规范定义了协议的SOAP和REST版本，这就是为什么几乎没有人实现SOAP版本的原因——这是因为如果您试图获取映射，只构建一个URL并从该URL获取图像字节要比将其封装到SOAP消息中容易得多。但是，是的，我同意如果web服务的目的是在域对象模型中传输一些强类型对象，那么SOAP更适合这种用途

“为什么还要编写返回XML的REST服务？”

嗯，是的，那可能很傻。但这取决于XML是什么。如果某个地方有一个明确定义的模式，那么就没有歧义。例如，您可以将WSDL URL看作是一种用于检索web服务信息的RESTful web服务。在这种情况下，增加另一个SOAP请求的开销将是毫无意义的

一般来说，当正在传输的内容可以看作是一个文件或单个单元时，REST获胜。当内容需要被视为具有成员的对象时，SOAP获胜

“我听到有人抱怨说，使用SOAP，你会有SOAP信封的“开销”。在今天这个时代，我们真的需要担心一小部分字节吗？”

对。不是在所有情况下，但有大量的交通网站，这是一个不同的地方。使用SOAP而不是REST的语义差异是否足以抵消？我对此表示怀疑。如果您正在执行对象远程处理协议，并且字节数起到了作用，那么SOAP可能并不适合您——也许您应该改用CORBA或DCOM

“我听过这样一种说法，使用REST，您只需将URL弹出浏览器即可查看数据。”

是的，如果在浏览器中查看数据有意义的话，这是一个支持REST的大论据。例如，对于图像数据，调试服务很简单——只需将URL粘贴到浏览器的地址栏中，然后查看图像的外观。或者，如果返回的数据是XML格式的，并且您有一个在浏览器中呈现为可读HTML的引用XML样式表，那么您可以在一个包中获得语义标记和轻松可视化的好处。但您是对的，在使用更复杂的身份验证方案时，这一好处几乎消失殆尽。如果您不能将所有身份验证信息编码到每个HTTP请求中，那么我认为它根本不算REST

“为什么我们需要每个资源都有一个“可读”的URL？如果我们使用一个工具来实现服务，我们真的关心实际的URL吗？”

那要看情况了。为什么我们需要网页上任何资源的可读URL？您可以阅读Tim Berners Lee的文章了解其基本原理，但基本上，只要资源在未来仍然有用，该资源的URI应该保持不变

显然，对于暂时性资源（如文章中的“今日金钱”链接），没有必要使用它，因为如果相应的