Comments 4
Очень рекомендую ознакомиться модель зрелости REST сервисов Ричардсона в дополнение к этому материалу.
Как по мне, подход с передачей ссылок может быть справедлив, если это шлет бекенд на фронтенд, чтобы там не хранить информацию о endpoint для работы с данными.
Кстати для описанного в статье реализована спецификация JSON API, как раз работает в описанном формате.
В случае, когда у нас серверное API с большим количеством данных, мы получаем огромное дублирование данных (при хайлоаде очень заметный трафик).
С каким успехом, лучше уже чтобы у API был метод, где мы можем получить схему URL'ов API.
Плюс, часто бывает, что нужен реально идентификатор сущности клиенткой стороне (например у вас другой сервис работает с этим API), для каких-то действий. Тогда что, делать запрос на урл, чтобы получить ID? парсить URL? хранить в БД URL? а если нужно сделать запрос на другой ендпоинт? или в процессе хочешь делать запросы по разным версиям?
Это можно решить путем работы с UUID или каким-то генерируем ключом, который не соответствует реальному ID в БД, таким образом, клиент не знает реального ID и работает с его представлением.
Кстати для описанного в статье реализована спецификация JSON API, как раз работает в описанном формате.
В случае, когда у нас серверное API с большим количеством данных, мы получаем огромное дублирование данных (при хайлоаде очень заметный трафик).
С каким успехом, лучше уже чтобы у API был метод, где мы можем получить схему URL'ов API.
Плюс, часто бывает, что нужен реально идентификатор сущности клиенткой стороне (например у вас другой сервис работает с этим API), для каких-то действий. Тогда что, делать запрос на урл, чтобы получить ID? парсить URL? хранить в БД URL? а если нужно сделать запрос на другой ендпоинт? или в процессе хочешь делать запросы по разным версиям?
предоставление ключей базы данных или прокси для них в полях тех сущностей, которые ассоциированы с этими ключами
Это можно решить путем работы с UUID или каким-то генерируем ключом, который не соответствует реальному ID в БД, таким образом, клиент не знает реального ID и работает с его представлением.
Полностью с тобой согласен. Плюсик жаль поставить не могу, кармы маловато :)
Почему-то все ребята придерживающиеся такого подхода думают, что:
На адекватном серьёзном фронте сейчас тайпскрипт, все строготипизированно. Фронту надо описывать все поля которые им пришли и т/д. То есть провести очень много работы.
Почему бы в таком случае url не описать?
Много кейсов когда нужен именно идентификатор. А вырезать его из строки при необходимости — бред полный.
Опять же соглашусь c тобой, что лучше иметь эндпоинт который даст тебе список всех роутов для актуальных ресурсов. Это самое нормальное решение.
Почему-то все ребята придерживающиеся такого подхода думают, что:
На фронтенде сидят люди которые вообще ничего могут не кодить и ты им дай ответ на сущность вместе с урлом, а они eager load'ом просто будут тянуть все данные которые ты им выплюнешь. Меняй список полей в объекте, меняй все вообще, там ребята динамически все подгрузят ....
На адекватном серьёзном фронте сейчас тайпскрипт, все строготипизированно. Фронту надо описывать все поля которые им пришли и т/д. То есть провести очень много работы.
Почему бы в таком случае url не описать?
Много кейсов когда нужен именно идентификатор. А вырезать его из строки при необходимости — бред полный.
Опять же соглашусь c тобой, что лучше иметь эндпоинт который даст тебе список всех роутов для актуальных ресурсов. Это самое нормальное решение.
А вы слышали что-нибудь про HATEAOS?
Sign up to leave a comment.
Проектирование API: почему для представления отношений в API лучше использовать ссылки, а не ключи