关于使用XML-RPC或REST解决方案的简单性的论点易于理解,难以反驳。
我经常听到的另一个论点是SOAP增加的开销可能会显着影响使用的带宽,甚至可能会影响延迟。我想看到一项测试结果来量化这种影响。有人知道这方面信息的好来源吗?
关于使用XML-RPC或REST解决方案的简单性的论点易于理解,难以反驳。
我经常听到的另一个论点是SOAP增加的开销可能会显着影响使用的带宽,甚至可能会影响延迟。我想看到一项测试结果来量化这种影响。有人知道这方面信息的好来源吗?
REST作为一种协议并没有定义任何形式的消息信封,而SOAP却有这个标准。
因此,试图比较这两者有点过于简单化了,它们就像是苹果与橙子之间的比较。
话虽如此,一个SOAP信封(不包括数据)只有几KB,所以如果您通过SOAP和REST同时检索序列化对象,则在速度上不应该存在明显的差异。
REST !== XML over HTTP
。 - MikeSchinkelSOAP和其他使用XML的协议通常会使您的消息变得臃肿 - 这可能是一个问题,也可能不是,这取决于上下文。
类似JSON的东西会更加紧凑,也许序列化/反序列化速度更快 - 但不要仅仅因为这个原因就专门使用它。在任何时候都要做出有意义的决策,并在出现问题时进行更改。
除非重用HTTP 1.1 keepalive连接(许多实现不会),否则使用HTTP的任何内容都会为每个请求启动一个新的TCP连接; 这非常糟糕,特别是在高延迟链路上。 HTTPS更糟。如果您有很多来自一个发送方到一个接收方的短请求,请考虑如何消除这种开销。
无论是SOAP还是其他任何RPC协议,使用HTTP总是会产生这种开销。其他RPC协议通常允许您保持连接。
关于这个问题,已经有一些研究,您可能会觉得很有启发性。请参见以下内容:
此外,还有一个(有点过时的)有趣的性能对话主题在MSDN论坛上。
简而言之,大多数来源似乎都认为SOAP和REST在一般数据的性能方面大致相同。然而,一些结果似乎表明,在处理二进制数据时,REST的性能实际上可能会更低。有关此更多详细信息,请参见我链接的论坛中的链接。如果您正在接收大量基于SOAP操作的INFORMATION(get*类型的调用),目前没有办法进行缓存。但是,如果您使用REST实现这些相同的操作,则有可能可以缓存数据(取决于您的业务背景),如上所述。因为SOAP在其操作中使用POST,所以它无法在服务器端缓存信息。
SOAP明显更慢。负载(Payloads)更大,需要更长时间来组装、传输、解析、验证和处理。
我想这里的主要问题是RPC和SOAP之间的比较。
它们都通过具有存根对象和原始/复杂数据类型的方式提供通信抽象,让您在不真正知道所有底层处理方式的情况下进行操作。
我总是更喜欢(JSON-)RPC,因为
尽管有理由使用SOAP,例如如果您需要命名参数而不是依赖其正确的顺序。
您可以从此stackoverflow question获取更多详细信息。