2016-12-25 55 views
0

Я никогда не использовал HATEOAS с RESTAPI, и я понимаю, что это HATEOAS, не нужно хранить URI и серверную отправку URI в ответе, который может использоваться для извлечения других ресурсов или связанных ресурсов.Увеличивает ли HATEOAS количество вызовов на сервер?

Но с HATEOAS мы не увеличиваем количество звонков? Если я хочу получить информацию о заказе клиента, и если я сначала получаю информацию о клиенте и получаю URI для своих заказов динамически, разве это не дополнительный вызов?

Свободное соединение можно понять, но я не понимаю точное использование этого уровня зрелости REST.

ответ

1

Зачем HATEOAS увеличивать количество требуемых запросов? Без службы, возвращающей URI, которую клиент может использовать для выполнения состояния trransition (собирать дополнительную информацию, вызывать некоторые задачи, ...), клиент должен иметь некоторые знания о том, как создать сам URI (следовательно, он тесно связан с сервисом), хотя клиенту по-прежнему необходимо вызывать конечную точку на стороне сервера. Таким образом, HATEOAS просто перемещает знания о том, как сгенерировать URI от клиента к серверу.

Обычно дополнительный запрос, отправленный на сервер, на самом деле не является проблемой, так как каждый вызов должен быть апатридом в любом случае. Если у вас есть структура балансировки нагрузки, дополнительный запрос на самом деле не оказывает заметного влияния на сервер.

Если вы заботитесь о количестве запросов, выданных клиентом на сервер (по какой-либо причине), вы можете посмотреть, например, HAL JSON, где вы можете встраивать содержимое под-ресурсов, хотя в случае клиента это может также оказать значительное влияние на производительность, так как у пользователей может быть много выпущенных заказов, которые могут быть весьма значительными, и клиент должен управлять всеми данными, даже если он не может его использовать. Обычно вместо встраивания большого количества элементов списка в ответ служба указывает клиенту на URI, где клиент может узнать, как получить эту информацию, если это необходимо. Часто такие URI предоставляют доступный для просмотра вид данных (например, заказы, размещенные клиентом).

Несмотря на то, что запрос на просмотр страницы позволяет увеличить количество или запросы, обрабатываемые службой, общая производительность будет возрастать, поскольку служба не должна возвращать клиенту все данные заказа и, следовательно, уменьшить нагрузку на резервную БД а также сокращение фактической длины содержимого ответа.

Чтобы подвести итог, HATEOAS предназначен для перемещения логики создания URI для вызова от клиентов к серверам и, следовательно, для дальнейшего отграничения клиентов от служб. Количество фактических запросов, которые клиенты должны выдавать, не соответствует требованиям HATEOAS, а относится к общему дизайну API и требованиям клиента.

+0

Хорошо! Поскольку URI генерируются сервером, и они не статически поддерживаются клиентом, я придерживался мнения, что для получения некоторой информации о клиенте нам может потребоваться пройти через некоторые дополнительные вызовы, пока мы не получим этот информационный URI от сервера в ответе, в котором случай, мы попадаем в URI и получаем наш ресурс. –