и сами не соответствуют тому чего хотят увидеть от тебя

ну просто в резюме конкретно писал - разработка клиент-серверных приложений (REST:Get/post/multipart)

тут думаю понятно, что это касается сервера, а не работы UI c кордатой

хотя с ней у меня зачасту тоже отношения: записал/прочитал

хотя с ней у меня зачасту тоже отношения: записал/прочитал

а там могут быть иные?)))

хотя с ней у меня зачасту тоже отношения: записал/прочитал

это ж CRUD

я помню собеседовался года 2 назад, мне там тим лид задачку дал, я ему сказал ответ - он говорит не правильно! в общем спорил спорил, попрощался и ушел, домой пришел написал этот код и оказался прав, потом ему на почту скинул и сказал - вы сами нихера не знаете, с тех пор на собеседования не езжу

зато все любят фразу RESTfullAPI

да я все время считал что эта абривиатура лучше обьяснит с чем я работал, бо все бекендщики говорят: юзаем рестфул

делай то-то то-то, такие-то такие то запросы

а там могут быть иные?)))

хз)

а там могут быть иные?)))

Удалил

При взаимодействии классов внутри iOS приложения в нужно чтобы как можно больше классов придерживались REST. Ну это уже имхо

Удалил

ну под "записал" - удаление тоже имеется ввиду как само собой

В нашем контексте это можно сказать антонимы)

REST это получается синоним lose coupling?

Я бы сказал REST включает в себя слабую связь

ну то есть на собеседовании нужно было сказать что РЕСт - это не СОАП, сервер ничего не знает о клиенте и его состоянии, да и клиент узнает о сервере только в какие-то моменты, в результате клиент получается не толстый, а тонкий и легкий. Зато нусть нужда в синхронизации и стало быть более надежном канале связи, если мы хотим что-то сделать с объектами которые в нашем клиенте являются например отображением записей из БД сервера? А то пользователь захочет выбрать товар на клиенте, а на сервере он уже тютю, нет его, удален.

можно ьыло бы так сказать?

Как нужно сказать на собеседовании, я не знаю) Каждый хочет услышать свое. Сервер знает на момент принятия запроса только то, что ему сказал клиент. То есть все, что нужно серверу для построения нужного запроса для клиента, должно лежать в самом запросе. Запрос выполнили, данные отдали, забыли

Но так как я хреново знаком с серверной разработкой, то я не уверен насчет id сессии

В REST не бывает сессий.

Если нужен ААА стек, его делают через какие-нибудь токены, например.

можно ьыло бы так сказать?

ну я перед отображением товаров - их с сервера и спрошу, что бы показать

как они могут неактуальными оказаться?

В REST не бывает сессий.

То есть в рест каждый раз при запросе надо передавать тот же токен, правильно? А в браузерах сейчас с куками как, тоже везде рест получается?

То есть в рест каждый раз при запросе надо передавать тот же токен, правильно? А в браузерах сейчас с куками как, тоже везде рест получается?

Нет, куки хранят сессию.

И сервер знает про нее.

А токен каждый раз валидируется.

все так. А в случае СОАПа наверное это происходилобы само собой, без твоего участия. На более низком уровне какого-то фреймоворка. Но клиент был бы тяжелее

Нет, куки хранят сессию.

Примерно это и имел в виду, спасибо

Примерно это и имел в виду, спасибо

Разница в том, что сервер не запоминает токены которые навыдавал.

То есть в рест каждый раз при запросе надо передавать тот же токен, правильно? А в браузерах сейчас с куками как, тоже везде рест получается?

я каждый раз токен отдельным параметром передавал. но это мы юзали лишь для того, что бы разрывать "залогиненность" юзера

Разница в том, что сервер не запоминает токены которые навыдавал.

Стоп, тогда не понял. А как он идентифицирует юзера?

Стоп, тогда не понял. А как он идентифицирует юзера?

Например токен это соль+пароль в хеше.

Он потом у себя делает такой же токен и сравнивает.

Клиент не знает соль, у него только токен есть.

Он потом у себя делает такой же токен и сравнивает.

При каждом запросе?

При каждом запросе?

Ну, не переломится.

Ну, не переломится.

Не, я же просто уточняю. Я в свое время делал отправку именно токена каждый раз. Это было не очень правильно?

Токен клиенту дается при четком запросе токена.

как они могут неактуальными оказаться?

Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален. Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0. И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то

А в авторизованных зонах его просто в запрос в хедер ставят.

Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален. Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0. И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то

Такой ответ просто приходит на попытку сделать заказ на товар.

Нет смысла делать какие-то вебсокеты чтобы такое пересылать.

Типа "Не могу заказать, кончилось".

Такой ответ просто приходит на попытку сделать заказ на товар.

Ну все верно

потому и рест.

Ребята, а что отвечать на собеседовании при вопросе: что такое REST? все время считал, что это методы работы с апи для того, что бы гонять json'ы (мб и не json'ы) от приложения к серверу с помощью get/post запросов? На собеседовании выдвинули: это не просто архитектура для того, что бы json'ы гонять. А для чего еще он юзается при програмировании под ифоны?

Это протокол взаимодействия между элементами архитектуры, главной особенностью которого является отсутствие хранения состояния элементов архитектуры друг у друга

Блять, да так. Ты же не сказал серверу заблокировать записи в БД? Чтобы их никто не могу удалить. Между тем как ты запросил список товаров и тем как отправил информацию о товарах на сервер, какой-то товар вполне может быть удален. Или ладно, более реалистичная ситуация - не удален, а его остаток на складе уменьшился до 0. И тебе нужно разрулить ситуацию - либо чтобы сервер сказал клиенту, "чувак, пока ты думал у меня заончился такой-то товар, смогу исполнить заказ без него", либо например чтобы клиенту (физ.лицу) перезвонил оператор, либьо еще как-то

при заказе ему сообщит, что тавар уже отсутствует, либо товар резервируется при нажатии заказать

>резервируется No.

то есть между запросами клиент не знает состояние сервера. Может он выключается в этот момент вообще

Все операции должны быть атомными.

Никаких "резервирований".

ну все кинотеатры так делают, как только ты билет выбираешь, тебе дается 15 мин на офррмление, он недоступен больше для покупки, например

И никаких сессий

Они делают предпокупку. Это уже не REST.

ну все кинотеатры так делают, как только ты билет выбираешь, тебе дается 15 мин на офррмление, он недоступен больше для покупки, например

Токен сгорает

Через рест можно

Но не нужно.

Нужно

Это удобно

Нет.

Это мудачество, онлайн оплата должна бесшумно в один клик уходить.

Хранение состояний это сто кейсов, это неудобно

Какие 15 минут?

Клиент может 15 минут оплачивать

а может и не оплачивать, если не оплатил - билет стал активным, и кто-то другой может купить

ERROR: S client not available

Нахуй такой клиент не нужен.

Они делают предпокупку. Это уже не REST.

Ну как - рест, но такой... "держим в уме что еще 15 минут будет зарезервирован". То есть в этим 15 минут происходит violation принципов REST.

Если нужно, можно запросить рефреш токен

И такой сервер, который оплату по 15 минут ждет.

если так произойдте, то первый получит при нажатии кнопки оплатить: сори, билет уже куплен

Ну как - рест, но такой... "держим в уме что еще 15 минут будет зарезервирован". То есть в этим 15 минут происходит violation принципов REST.

+

15 минут, это же ахуеть вообще.

Нахуй такой клиент не нужен.

Ты решаешь проблемы пользователей, а не проблемы написать красиво код

это плохо просто потому, что например на сервере это время может быть уменьшено до 10 минут, а клиент все еще будет надеятся на 15 минут

Я вот жаловался когда у нас бизнес процесс 5 минут шел, и добился ускорения до 2-х.

ну это стандартная процедура во всех кинотеатрах/жд/ и т.д.

А тут 15.

у клиента отсчет времени идет

Ты решаешь проблемы пользователей, а не проблемы написать красиво код

Я служу богу Машине.

через сколько этот билет у него могут украсть

ЧЕТВЕРТЬ ЧАСА, БЛДЖАД.

Для клиента должно быть столько, сколько ему нужно

[Времени]

Нет, клиент — тупой примат, нужно чтобы он кнопку нажал и сразу заебись все.

Как это опровергает мой тезис?

В идеале твоим ПО и шимпанзе должно уметь воспользоваться с первого раза.

А, вот оно что

А шимпанзе не умеет в часы.

Твои билеты зарезервированы на 13 мин. 42 сек., Чтобы никто не смог их купить. Если ты не успеешь провести оплату за это время, билеты вернутся в свободную продажу и тебе придется заново пройти процедуру выбора мест и оплаты. Перед оплатой билетов, пожалуйста, убедитесь, что ты не ошибся в выборе кинотеатра, фильма, даты и сеанса.

Нет, клиент — тупой примат, нужно чтобы он кнопку нажал и сразу заебись все.

на практике же нужно связаться с платежной системой, дождаться пока там завершиться транзакция. А клиентв метро, связь прерывается и т.п.

на практике же нужно связаться с платежной системой, дождаться пока там завершиться транзакция. А клиентв метро, связь прерывается и т.п.

У нас платежи в 2 минуты проходили, топ.

С карточки.

В идеале твоим ПО и шимпанзе должно уметь воспользоваться с первого раза.

Шимпанзе может свернуть приложение и продолжить пользоваться им через полчаса

к чуваку могли во время оплаты позвонить

Шимпанзе может свернуть приложение и продолжить пользоваться им через полчаса

И? Ты предлагаешь запомнить где он остановился?

Such REST, much API.