AE
Алексей
С чего бы это не rest?
намек был на restfull
Size: a a a
2021 April 01
А
намек был на restfull
Не вижу намека, вижу слова что это, дескать не рест, а rpc. Про restfull не было слов
DC
Алексей
С чего бы это не rest?
вообще говоря, HTTP и REST - не одно и то же
уместно ли это называть RPC - вопрос отдельный, впрочем
уместно ли это называть RPC - вопрос отдельный, впрочем
AE
вообще говоря, HTTP и REST - не одно и то же
уместно ли это называть RPC - вопрос отдельный, впрочем
уместно ли это называть RPC - вопрос отдельный, впрочем
+
А
вообще говоря, HTTP и REST - не одно и то же
уместно ли это называть RPC - вопрос отдельный, впрочем
уместно ли это называть RPC - вопрос отдельный, впрочем
Ну как бы да. Сравнивать теплое с мягким - это глупо. Причем тут сравнение архитектуры и протокола?
А
намек был на restfull
Про рестфул понял. Не заметил в изначальном вопросе что он про restfull спрашивал)
2021 April 02
ch
С точки зрения дизайна RESTful API как правильнее передавать настройки представления ресурса и токен доступа?
К чему я пришёл после изучения статей:
Настройки представления в виде параметров запроса:
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
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. Что ещё лучше передавать в параметрах, а что в заголовках? В чём глобальная логика? Как я понял, параметры должны специфицировать получаемую информацию (представление), а заголовки передают любую метаинформацию для обслуживания запроса: токен, ожидаемый / передаваемый формат, и тд
Access token можно хранить в HTTP only cookie
ᴍ
https://pastebin.com/3WD5hLu0
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
ch
https://pastebin.com/3WD5hLu0
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
D
https://pastebin.com/3WD5hLu0
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
Хочу сделать поиск книги по названию, но выходит ошибка =
java.lang.NullPointerException
Хотя там есть поля с этим именем
А память кто за тебя под это поле выделит?)
AE
Э
Access token можно хранить в HTTP only cookie
Для чего? Почему просто не в заголовке? Просто интересно
ch
Для чего? Почему просто не в заголовке? Просто интересно
Фронту не надо париться по поводу его хранения и передачи, он вообще даже не может на http only cookie никак повлиять
ch
+ безопасность хранения таким способом будет лучше чем костыли классические
ch
Фронту не надо париться по поводу его хранения и передачи, он вообще даже не может на http only cookie никак повлиять
То есть ее читает и ставит только сервер
ch
В этом случае фронт получает access token у бека, на котором ресурс сервер?
Пользователь вводит правильный аатомзационные данные сервер их проверяет, после чего вместе с ответом 200 скажем он ставит http only cookie-у и дальше при каждом запросе с данного клиента он проверяет эту куку и смотрит что там ваоидный токен, фронт в этом не принимает участия он просто делает запрос как будто никакого токена вообще не нужно
АЦ
Пользователь вводит правильный аатомзационные данные сервер их проверяет, после чего вместе с ответом 200 скажем он ставит http only cookie-у и дальше при каждом запросе с данного клиента он проверяет эту куку и смотрит что там ваоидный токен, фронт в этом не принимает участия он просто делает запрос как будто никакого токена вообще не нужно
С куками есть беда - csrf
ch
Для этого же есть same origin policy вроде
АЦ
Для этого же есть same origin policy вроде
И оно не всегда работает, например для тега img оно не действует:)