我经常读到选择 RESTful 架构的一个原因是（除其他外）为高负载的 Web 应用程序提供更好的可扩展性。
这是为什么呢？我能想到的一个原因是，由于每个客户端都定义了相同的资源，缓存变得更容易。在第一个请求之后，后续请求由一个 memcached 实例提供服务，该实例也可以很好地水平扩展。
但是你不能用传统的方法来完成这个，其中动作在 url 中编码，例如(booking.php/userid=123&travelid=456&foobar=789)。
【问题讨论】：
标签： web-services rest architecture
REST 的一部分确实是 URL 部分（它是 REST 中的 R），但 S 对于扩展更重要：状态。
REST 的服务器端是无状态的，这意味着服务器不必跨请求存储任何内容。这意味着服务器之间不必（太多）通信，使其可横向扩展。
当然，R（代表性）有一个小好处，即如果您有不错的 URL，负载均衡器可以轻松地将请求路由到正确的服务器，而 GET 可以转到从属服务器而 POST 则发给 master。
【讨论】：
我认为 Tom 所说的非常准确，但是可扩展性的另一个问题是在扩展时改变的障碍。因此，按照预期，REST 的最大租户之一是超媒体。基本上，服务器将拥有路径并在运行时将它们传递给客户端。这使您可以在不破坏现有客户端的情况下更改代码。但是，您会发现大多数 REST 实现只是 RPC 隐藏在 REST 的幌子后面......这是不可扩展的。
【讨论】：
“可扩展”或"web scale" 是涉及网络、云和 REST 时最常被滥用的术语之一，主要用于说服管理层获得他们的支持，让他们的开发团队加入 REST 列车。
这是一个没有价值的流行语。如果你在网上搜索“REST 可扩展性”，你会发现很多人在没有任何具体证据的情况下互相模仿。
REST 服务与通过 SOAP 接口公开的服务完全一样可扩展。两者都只是应用程序服务的 HTTP 接口。该服务的实际扩展程度完全取决于该服务的实际实施方式。可以编写无法在 REST 和 SOAP 中完全扩展的服务。
是的，您可以使用 SOAP 做一些使其扩展性更差的事情，例如依赖状态和会话。开箱即用的 SOAP 不会这样做。这需要您使用更智能的负载均衡器，如果您真的关心任何形式的扩展，无论如何都需要它。
REST 允许 SOAP 不允许的一件事，以及此处的一些其他答案解决的问题，是通过 HTTP 缓存代理或在客户端缓存可缓存的响应。当许多操作的响应是可缓存的时，这可能使 REST 服务比 SOAP 服务负载更轻。所有这一切都意味着您的服务中的请求会减少。
【讨论】：
一个原因（也许不是原因）是 RESTful 服务是无会话的。这意味着您可以轻松地使用负载平衡器将请求定向到各种 Web 服务器，而无需在所有 Web 服务器之间复制会话状态或确保来自单个会话的所有请求都发送到同一 Web 服务器。
【讨论】：
说 REST 应用程序可扩展的主要原因是，它建立在 HTTP 协议之上。因为 HTTP 是无状态的。无状态意味着它不会在其他请求之间共享任何内容。因此任何请求都可以发送到负载平衡集群中的任何服务器。没有任何东西会强制此用户请求转到此服务器。我们可以通过使用令牌来克服这个问题。
由于这种无状态性，所有 REST 应用程序都非常容易扩展。但是，如果您想在每台服务器中获得高吞吐量（一秒钟内能够处理的请求数），那么您应该优化阻止应用程序的内容。请遵循以下提示
【讨论】：