Nikita
Как нужно сказать на собеседовании, я не знаю) Каждый хочет услышать свое.
Сервер знает на момент принятия запроса только то, что ему сказал клиент. То есть все, что нужно серверу для построения нужного запроса для клиента, должно лежать в самом запросе. Запрос выполнили, данные отдали, забыли
Nikita
Но так как я хреново знаком с серверной разработкой, то я не уверен насчет id сессии
Anonymous
В REST не бывает сессий.
Anonymous
Если нужен ААА стек, его делают через какие-нибудь токены, например.
Paks
можно ьыло бы так сказать?
ну я перед отображением товаров - их с сервера и спрошу, что бы показать
Paks
как они могут неактуальными оказаться?
Stanislav
В REST не бывает сессий.
То есть в рест каждый раз при запросе надо передавать тот же токен, правильно? А в браузерах сейчас с куками как, тоже везде рест получается?
Anonymous
Anonymous
И сервер знает про нее.
Anonymous
А токен каждый раз валидируется.
Anonymous
все так. А в случае СОАПа наверное это происходилобы само собой, без твоего участия. На более низком уровне какого-то фреймоворка. Но клиент был бы тяжелее
Anonymous
Примерно это и имел в виду, спасибо
Разница в том, что сервер не запоминает токены которые навыдавал.
Paks
То есть в рест каждый раз при запросе надо передавать тот же токен, правильно? А в браузерах сейчас с куками как, тоже везде рест получается?
я каждый раз токен отдельным параметром передавал. но это мы юзали лишь для того, что бы разрывать "залогиненность" юзера
Stanislav
Разница в том, что сервер не запоминает токены которые навыдавал.
Стоп, тогда не понял. А как он идентифицирует юзера?
Anonymous
Стоп, тогда не понял. А как он идентифицирует юзера?
Например токен это соль+пароль в хеше.
Anonymous
Он потом у себя делает такой же токен и сравнивает.
Anonymous
Клиент не знает соль, у него только токен есть.
Stanislav
Ну, не переломится.
Не, я же просто уточняю. Я в свое время делал отправку именно токена каждый раз. Это было не очень правильно?
Anonymous
Токен клиенту дается при четком запросе токена.
Anonymous
как они могут неактуальными оказаться?
Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален.
Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0.
И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то
Anonymous
А в авторизованных зонах его просто в запрос в хедер ставят.
Anonymous
Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален.
Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0.
И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то
Такой ответ просто приходит на попытку сделать заказ на товар.
Anonymous
Нет смысла делать какие-то вебсокеты чтобы такое пересылать.
Anonymous
Типа "Не могу заказать, кончилось".
Anonymous
потому и рест.
Anonymous
Ребята, а что отвечать на собеседовании при вопросе: что такое REST?
все время считал, что это методы работы с апи для того, что бы гонять json'ы (мб и не json'ы) от приложения к серверу с помощью get/post запросов?
На собеседовании выдвинули: это не просто архитектура для того, что бы json'ы гонять.
А для чего еще он юзается при програмировании под ифоны?
Это протокол взаимодействия между элементами архитектуры, главной особенностью которого является отсутствие хранения состояния элементов архитектуры друг у друга
Paks
Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален.
Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0.
И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то
при заказе ему сообщит, что тавар уже отсутствует, либо товар резервируется при нажатии заказать
Anonymous
>резервируется
No.
Anonymous
то есть между запросами клиент не знает состояние сервера. Может он выключается в этот момент вообще
Anonymous
Все операции должны быть атомными.
Anonymous
Никаких "резервирований".
Paks
ну все кинотеатры так делают, как только ты билет выбираешь, тебе дается 15 мин на офррмление, он недоступен больше для покупки, например
Anonymous
И никаких сессий
Anonymous
Они делают предпокупку. Это уже не REST.
Anonymous
Anonymous
Через рест можно
Anonymous
Но не нужно.
Anonymous
Нужно
Anonymous
Это удобно
Anonymous
Нет.
Anonymous
Это мудачество, онлайн оплата должна бесшумно в один клик уходить.
Anonymous
Хранение состояний это сто кейсов, это неудобно
Anonymous
Какие 15 минут?
Nikita
Клиент может 15 минут оплачивать
Paks
а может и не оплачивать, если не оплатил - билет стал активным, и кто-то другой может купить
Anonymous
Нахуй такой клиент не нужен.
Anonymous
Они делают предпокупку. Это уже не REST.
Ну как - рест, но такой... "держим в уме что еще 15 минут будет зарезервирован". То есть в этим 15 минут происходит violation принципов REST.
Anonymous
Если нужно, можно запросить рефреш токен
Anonymous
И такой сервер, который оплату по 15 минут ждет.
Paks
если так произойдте, то первый получит при нажатии кнопки оплатить: сори, билет уже куплен
Anonymous
15 минут, это же ахуеть вообще.
Nikita
Нахуй такой клиент не нужен.
Ты решаешь проблемы пользователей, а не проблемы написать красиво код
Anonymous
это плохо просто потому, что например на сервере это время может быть уменьшено до 10 минут, а клиент все еще будет надеятся на 15 минут
Anonymous
Я вот жаловался когда у нас бизнес процесс 5 минут шел, и добился ускорения до 2-х.
Paks
ну это стандартная процедура во всех кинотеатрах/жд/ и т.д.
Anonymous
А тут 15.
Paks
у клиента отсчет времени идет
Anonymous
Ты решаешь проблемы пользователей, а не проблемы написать красиво код
Я служу богу Машине.
Paks
через сколько этот билет у него могут украсть
Anonymous
ЧЕТВЕРТЬ ЧАСА, БЛДЖАД.
Anonymous
Для клиента должно быть столько, сколько ему нужно
Anonymous
[Времени]
Anonymous
Нет, клиент — тупой примат, нужно чтобы он кнопку нажал и сразу заебись все.
Anonymous
Как это опровергает мой тезис?
Paks
Anonymous
В идеале твоим ПО и шимпанзе должно уметь воспользоваться с первого раза.
Anonymous
Anonymous
А шимпанзе не умеет в часы.
Paks
Твои билеты зарезервированы на 13 мин. 42 сек., Чтобы никто не смог их купить.
Если ты не успеешь провести оплату за это время, билеты вернутся в свободную продажу и тебе придется заново пройти процедуру выбора мест и оплаты.
Перед оплатой билетов, пожалуйста, убедитесь, что ты не ошибся в выборе кинотеатра, фильма, даты и сеанса.
Anonymous
Нет, клиент — тупой примат, нужно чтобы он кнопку нажал и сразу заебись все.
на практике же нужно связаться с платежной системой, дождаться пока там завершиться транзакция. А клиентв метро, связь прерывается и т.п.
Anonymous
на практике же нужно связаться с платежной системой, дождаться пока там завершиться транзакция. А клиентв метро, связь прерывается и т.п.
У нас платежи в 2 минуты проходили, топ.
Anonymous
С карточки.
Anonymous
В идеале твоим ПО и шимпанзе должно уметь воспользоваться с первого раза.
Шимпанзе может свернуть приложение и продолжить пользоваться им через полчаса
Paks
к чуваку могли во время оплаты позвонить
Anonymous
Шимпанзе может свернуть приложение и продолжить пользоваться им через полчаса
И? Ты предлагаешь запомнить где он остановился?