представления ресурса и токен доступа?
К чему я пришёл после изучения статей:
Настройки представления в виде параметров запроса:
api/v1/items/1
api/v1/items/1?fields=all
api/v1/items/1?fields=name,date,images
Jwt токен доступа в заголовке:
Authorization: Bearer <token>
В то же время, например, vk api даже токен принимает в параметрах запроса
1. Это лучшая практика? Видел мнение, что настраивать представление ресурса следует через заголовок "Accept":
https://stackoverflow.com/a/7853235
2. Если для настройки представления использовать параметры запроса, то по умолчанию лучше выдавать лёгкий или полный объект?
3. Что ещё лучше передавать в параметрах, а что в заголовках? В чём глобальная логика? Как я понял, параметры должны специфицировать получаемую информацию (представление), а заголовки передают любую метаинформацию для обслуживания запроса: токен, ожидаемый / передаваемый формат, и тд
api/v1/items/1/full api/v1/items/1/small api/v1/items/1/preview это не REST, это просто RPC В REST у ресурса должен быть строго один адрес, по которому мы получаем, модифицируем или удаляем ресурс
С чего бы это не rest?
Не вижу намека, вижу слова что это, дескать не рест, а rpc. Про restfull не было слов
вообще говоря, HTTP и REST - не одно и то же уместно ли это называть RPC - вопрос отдельный, впрочем
Ну как бы да. Сравнивать теплое с мягким - это глупо. Причем тут сравнение архитектуры и протокола?
Про рестфул понял. Не заметил в изначальном вопросе что он про restfull спрашивал)
Access token можно хранить в HTTP only cookie
Для чего? Почему просто не в заголовке? Просто интересно
Фронту не надо париться по поводу его хранения и передачи, он вообще даже не может на http only cookie никак повлиять
То есть ее читает и ставит только сервер
Обсуждают сегодня