我总是读到,选择 RESTful 架构的一个原因是(除其他外)为高负载的 Web 应用程序提供更好的可扩展性。
这是为什么?我能想到的一个原因是,由于每个客户端都定义了相同的资源,缓存变得更容易。在第一个请求之后,后续请求由一个 memcached 实例提供服务,该实例也可以很好地水平扩展。
但是你不能用传统的方法来完成这个,其中动作在url中编码,例如(booking.php/userid=123&travelid=456&foobar=789)。
我总是读到,选择 RESTful 架构的一个原因是(除其他外)为高负载的 Web 应用程序提供更好的可扩展性。
这是为什么?我能想到的一个原因是,由于每个客户端都定义了相同的资源,缓存变得更容易。在第一个请求之后,后续请求由一个 memcached 实例提供服务,该实例也可以很好地水平扩展。
但是你不能用传统的方法来完成这个,其中动作在url中编码,例如(booking.php/userid=123&travelid=456&foobar=789)。
REST 的一部分确实是 URL 部分(它是 REST 中的 R),但 S 对于扩展更重要:状态。
REST 的服务器端是无状态的,这意味着服务器不必跨请求存储任何内容。这意味着服务器之间不必(太多)通信,使其可以水平扩展。
当然,R(representational)有一个小小的好处,如果你有很好的 URL,负载均衡器可以轻松地将请求路由到正确的服务器,并且 GET 可以发送到从站,而 POST 发送到主站。
我认为 Tom 所说的非常准确,但是可扩展性的另一个问题是在扩展时改变的障碍。因此,按照预期,REST 的最大租户之一是超媒体。基本上,服务器将拥有路径并在运行时将它们传递给客户端。这使您可以在不破坏现有客户端的情况下更改代码。但是,您会发现大多数 REST 实现只是 RPC 隐藏在 REST 的幌子后面......这是不可扩展的。
当涉及到 Web、云和 REST 时, “可扩展”或“网络规模”是最常被滥用的术语之一,主要用于说服管理层获得他们的支持,让他们的开发团队加入 REST 列车。
这是一个没有价值的流行语。如果你在网上搜索“REST 可扩展性”,你会发现很多人在没有任何具体证据的情况下互相模仿。
REST 服务与通过 SOAP 接口公开的服务完全一样可扩展。两者都只是应用程序服务的 HTTP 接口。该服务的实际扩展程度完全取决于该服务的实际实施方式。可以编写无法在 REST 和 SOAP 中完全扩展的服务。
是的,您可以使用 SOAP 做一些使其扩展性更差的事情,例如依赖状态和会话。开箱即用的 SOAP 不会这样做。这需要您使用更智能的负载均衡器,如果您真的关心任何形式的扩展,无论如何都需要它。
REST 允许 SOAP 不允许的一件事,以及这里的一些其他答案解决的问题是,通过 HTTP 缓存代理或在客户端缓存可缓存的响应。当许多操作的响应是可缓存的时,这可能会使 REST 服务比 SOAP 服务负载更轻。这意味着更少的请求最终会出现在您的服务中。
The main reason behind saying a rest application is scalable is, Its built upon a HTTP protocol. Because HTTP is stateless. Stateless means it wont share anything between other request. So any request can go to any Server in a load balanced cluster. There is nothing forcing this user request go to this server. We can overcome this by using token.
Because of this statelessness,All REST application are very easy to scale. But if you want get high throughput(number of request capable in one second) in each server, then you should optimize blocking things from the application. Follow the following tips
一个原因(也许不是原因)是 RESTful 服务是无会话的。这意味着您可以轻松地使用负载平衡器将请求定向到各种 Web 服务器,而无需在所有 Web 服务器之间复制会话状态或确保来自单个会话的所有请求都转到同一 Web 服务器。