Разве HATEOAS не умножает HTTP-запросы? - PullRequest
Новая
       9

Разве HATEOAS не умножает HTTP-запросы?

0 голосов
/ 02 июля 2018

Я наткнулся на HATEOAS в своих исследованиях и думал: не умножает ли HATEOAS HTTP-запросы?

Давайте рассмотрим базовый пример customer и order.

Допустим, вы хотите получить заказ, конечная точка будет /orders/2 со следующим ответом JSON: 

{
    "id": 2,
    "total": 50.00,
    "links": [{
        "rel": "customer",
        "href": "http://api.domain.com/customer/1
    }]
}

А что, если мне также нужен клиент? Нужно ли сделать еще один запрос на /customer/1? Разве это не перегружает трафик HTTP?

Не могу ли я получить пару customer + order с одной конечной точкой, например /customers/1/orders/2?

Или просто отправьте customer в ответе /orders/2 JSON? 

{
    "id": 2,
    "total": 50.00,
    "customer": {
        "id": 1,
        "name": "Dylan Gauthier"
    }
}

Какая выгода от того или иного решения? Когда мне нужно одно или другое?

Спасибо! : -)

Ответы [ 2 ]

0 голосов
/ 12 июля 2018

Просто добавьте к Николас 'ответ:

Встраивание связанных ресурсов

Плюсы : спасает вас от поездки на сервер

Минусы : Хотя это спасает вас в первый раз и может содержать несколько строк кода, вы отказываетесь от кеширования: если что-то меняется в связанном ресурсе (который вы встроили), кеш клиента больше не действителен, поэтому клиент должен сделать запрос снова. Конечно, если вы используете кеширование HTTP. Что вы должны ...

Если вы хотите пойти по этому пути, вам лучше использовать что-то вроде GraphQL ... но подождите!

Собирается "чистый" HATEOS

Плюсы : ресурсы имеют независимые жизненные циклы; легче сделать так, чтобы каждый (тип) ресурса развивался без влияния на другие. Благодаря использованию кеша сверхурочно общая производительность значительно улучшается.

Минусы : больше запросов (при первом доступе), это может быть немного медленнее при первом доступе; еще немного кода для управления HATEOS ...

Лично я склонен использовать второй подход, когда это возможно.

Классическая веб-аналогия:

Если это поможет, классический веб-сайт - это просто еще один API, который обслуживает связанные с HTML ресурсы, а клиентское приложение - это сам браузер. Если вы когда-нибудь делали html / css / js, вы можете подойти к нему так же: Для данного конкретного веб-сайта, учитывая его навигационную архитектуру ... и т. Д., Вы бы предпочли встроить все / часть css / js (связанные ресурсы) в html-страницы (основной ресурс) или нет.

0 голосов
/ 02 июля 2018

Если сервер только поставляет клиента и заказ отдельно, то вам нужно сделать два запроса независимо от того, следуют ли они за REST или нет.
Ничто в отношении REST или его ограничения HATEOAS не мешает серверу предоставлять заказчику и заказу на одном и том же ресурсе, в точности так, как вы предложили: 

GET /orders/2

{
    "id": 2,
    "total": 50.00,
    "customer": {
        "name": "Dylan Gauthier"
    }
}

Но клиент в этом ответе не имеет связи с идентификатором /customers/1 - сервер может объединить две идеи: 

{
    "id": 2,
    "total": 50.00,
    "links": [{
        "rel": "customer",
        "href": "http://api.domain.com/customer/1
    }],
    "resources": {
        "http://api.domain.com/customer/1": {
            "name": "Dylan Gauthier"
        }
    }
}

или, что еще лучше, сгруппируйте ссылки по их связи с запрашиваемым ресурсом: 

{
    "id": 2,
    "total": 50.00,
    "links": {
        "customer": [{
            "href": "http://api.domain.com/customer/1"
        }]
    },
    "resources": {
        "http://api.domain.com/customer/1": {
            "name": "Dylan Gauthier"
        }
    }
}

Несмотря на то, что для клиента было бы немного труднее напечатать имя клиента (не нужно никаких затрат, ум), он позволяет клиенту получать больше информации о клиенте, если он этого хочет!

...