Почему приложения RESTful легче масштабируются

Я всегда читал, что одной из причин выбора архитектуры RESTful является (среди прочего) лучшая масштабируемость для Web-приложений с высокой нагрузкой.

Почему? Одна из причин, почему я могу думать, состоит в том, что из-за определенных ресурсов, которые одинаковы для каждого клиента, кеширование становится проще. После первого запроса последующие запросы подаются из экземпляра memcached, который также хорошо масштабируется по горизонтали.

Но вы не могли бы также выполнить это с помощью традиционного подхода, в котором действия кодируются в URL-адресе, например. (Booking.php/идентификатор пользователя = 123 & travelid = 456 & Foobar = 789).

ОТВЕТЫ

Ответ 1

Часть REST действительно является частью URL (это R в REST), но S более важна для масштабирования: состояние.

Конечный сервер REST не имеет статуса, что означает, что серверу не нужно ничего хранить в запросах. Это означает, что между серверами не должно быть (много) связи, что делает его горизонтально масштабируемым.

Конечно, есть небольшой бонус в R (репрезентативный), поскольку балансировщик нагрузки может легко перенаправить запрос на нужный сервер, если у вас есть хорошие URL-адреса, а GET может перейти к подчиненному устройству, а POST - к мастерам.

Ответ 2

Я думаю, что Том сказал очень точно, однако другая проблема с масштабируемостью является препятствием для изменения при масштабировании. Таким образом, один из крупнейших арендаторов REST, как и предполагалось, - HyperMedia. В принципе, сервер будет владеть путями и передавать их клиенту во время выполнения. Это позволяет вам изменять код без нарушения существующих клиентов. Тем не менее, вы найдете большинство реализаций REST, чтобы просто быть RPC, скрывающимся под видом REST... который не масштабируется.

Ответ 3

"Масштабируемый" или "веб-масштаб" является одним из самых злоупотребляемых терминов, когда дело доходит до Интернета, облака и REST, и в основном используется для того, чтобы убедить руководство получить поддержку для продвижения своей команды разработчиков на поезде REST.

Это модное слово, которое не имеет значения. Если вы будете искать в Интернете "масштабируемость REST", вы обнаружите, что многие люди парируют друг друга без каких-либо конкретных доказательств.

Служба REST в равной степени масштабируется как услуга, открытая через интерфейс SOAP. Оба являются только HTTP-интерфейсами к службе приложений. Насколько хорошо эта служба действительно масштабируется, зависит полностью от того, как эта служба была фактически реализована. Можно написать службу, которая не может масштабироваться как все как в REST, так и в SOAP.

Да, вы можете делать что-то с SOAP, что делает его хуже, например, полагаться на состояние и сеансы. SOAP из коробки не делает этого. Это требует от вас использовать более умный балансировщик нагрузки, который вы хотите в любом случае, если вы действительно обеспокоены любой формой масштабирования.

Одна вещь, которую REST позволяет этому SOAP не делать, и что некоторые другие ответы здесь адресованы, кэширует ответы с кэшированием через прокси-сервер кеширования HTTP или на стороне клиента. Это может сделать услугу REST несколько более легкой загрузкой, чем услуга SOAP, когда множество ответов операций можно кэшировать. Все это означает, что в вашем сервисе заканчивается меньше запросов.

Ответ 4

Причина

A (возможно, не причина) заключается в том, что службы RESTful без сеанса. Это означает, что вы можете легко использовать балансировщик нагрузки для прямого запроса на различные веб-серверы без необходимости репликации состояния сеанса среди всех ваших веб-серверов или обеспечения того, чтобы все запросы с одного сеанса переходили на один и тот же веб-сервер.