我总是读到一个理由选择一个RESTful架构（等等）的web应用更好的可扩展性与高负载。
这是为什么？ 其中一个原因，我能想到的是，由于定义的资源这对每一个客户一样，缓存变得更加容易。 所述第一请求之后，后续请求从分布式缓存实例，它也是公水平缩放服务。
但不能也与在动作在URL编码传统的方法做到这一点，如（booking.php /用户id = 123＆travelid = 456＆foobar的= 789）。
Answer 1:
REST的一部分确实是URL的一部分（这是在REST的R）但S的比例是比较重要的：状态。
REST的服务器端是无状态的，这意味着服务器没有存储跨请求任何东西。 这意味着不必在服务器之间（多）通信，使其水平扩展 。
当然，有一个在R（代表性的）一个小的奖金，一个负载均衡器可以轻松地将请求路由到，如果你有很好的URL和GET可以去一个奴隶，同时POST的去掌握了正确的服务器。
Answer 2:
我认为汤姆说是非常准确的，但是可扩展性的另一个问题是在缩放改变屏障。 所以，它的目的是REST的最大的住户之一是超级媒体。 基本上，服务器将自己的路径，并将它们在运行时传递到客户端。 这可以让你改变你的代码，而不会破坏现有的客户。 然而，你会发现REST的大多数实现简单是REST的幌子......这是不可扩展的背后隐藏的RPC。
Answer 3:
“可扩展性”或“网络规模”是最被滥用的词汇之一，当它涉及到网络，云和REST，主要用于说服管理层让他们的移动他们的开发团队登上火车REST支持。
这是一个没有保持价值流行语。 如果你搜索“REST的可扩展性”的网站，你会发现有很多人人云亦云对方没有任何具体的证据。
REST服务是暴露了一个SOAP接口的服务正是同样可扩展性。 两者都只是HTTP接口的应用服务。 如何好这个服务实际上秤上这项服务是如何切实执行完全取决于。 它可以编写无法在REST和SOAP为所有规模的服务。
是的，你可以做的事情与SOAP，使得它扩展糟糕的是，像依靠国家和会话。 SOAP开箱并没有这样做。 这需要您使用更智能的负载均衡器，你想无论如何，如果你真的关心缩放的任何形式。
有一两件事，REST允许SOAP不和这里的一些其他的答案地址时，缓存通过HTTP缓存代理服务器或在客户端缓存响应。 这可能使一个REST服务有些负载较轻比SOAP服务时，很多操作者的回应是缓存。 所有这一切意味着更少的请求，在服务结束。
Answer 4:
一个原因（也许不是这个原因）是RESTful服务是无会话。 这意味着你可以很容易地使用负载平衡器来请求定向到不同的Web服务器，而无需复制之间的所有Web服务器的会话状态或确保从单一会话的所有请求到同一个Web服务器。
Answer 5:
背后说休息的应用是可扩展的最主要的原因是，它在一个HTTP协议构建的。 由于HTTP是无状态的。 无状态意味着它不会共享其他要求之间的任何东西。 因此，任何请求都可以去在负载均衡集群的任何服务器。 没有什么迫使该用户请求到这个服务器。 我们可以通过使用令牌克服这一点。
正因为如此无国籍的，所有的REST应用很容易扩展。 但是，如果你想获得高吞吐量的每个服务器（的能够在一秒钟内请求数），那么你应该从优化应用程序拦截的事情。 按照下面的提示
- 使每个REST资源是一个小的实体。 不要读加入多个表的数据。
- 读取数据库从接近数据
- 使用高速缓存（Redis的），而不是数据库（您可以节省磁盘I / O）
- 总是因为这些块将服务器资源（CPU）保持理想的数据源尽可能近，它没有其他请求可以使用的资源，而它是理想的。
文章来源: Why are RESTful Applications easier to scale
