зачем нужно использовать куки (сохранять их с сервера) в REST API?

Давайте зайдем с другой стороны, какие принципы REST это, по вашему, нарушает?

Если никакие, то что хочешь, то и юзай - что токены, что куки, что апи ключи каждому пользователю выписывать.

Всякую инфу полезную там хранить

Кейс не очень типичный но иногда бывает

Всякую инфу полезную там хранить

Какую? (В контексте rest api)

https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api вот тут описан пример. Когда требуется обработать какую то сложную форму за несколько запросов, тогда в куках можно хранить состояние на _клиенте_ При этом серверное api остается в рамках restful

Но в общем конечно такого стоит избегать по возможности, так как это вносит путаницу.

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

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

1) почему гемморой, 2) почему не должно быть самоцелью 3) зачем куки?

Здаров, кто-то пробовал парное тестирование внедрять в конторе?

1) почему гемморой, 2) почему не должно быть самоцелью 3) зачем куки?

2) Технология в разработке как самоцель? Кек)

Здаров, кто-то пробовал парное тестирование внедрять в конторе?

а какую цель приследуете внедрением парного тестирования?

3) это отличный способ хранить стейт. Зачем хранить стейт? Чтобы не оверкостылить пункт (1)

у нас много проектов и конкретный басфактор

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

возможно, у нас не слишком много проектов(14 сервисов), на 6 человек в qa команде. Мы используем подход, берешь в тестирование задачу которую меньше всего знаешь

Это частично решает проблему шаринга знания внутри qa команды. Потому что приходится много общаться

3) это отличный способ хранить стейт. Зачем хранить стейт? Чтобы не оверкостылить пункт (1)

Отсутствие состояния Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится. (Stateless protocol) Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например в службу базы данных) для поддержания устойчивого состояния, например с целью, и на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние. Во время обработки клиентских запросов считается, что клиент находится в переходном состоянии. Каждое отдельное состояние приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.

если сервер хранит сессию или куки (для работы между клиентом и сервером) - это нарушает принцип REST архитектуры.

сервер не умеет хранить куки, их хранит только клиент всегда

Куки это как раз про хранение состояние на клиенте, если чо.

Про сессию - верно, но мы не про нее говорим.

Сессия же в любом случае требует двухсторонней обработки, иначе нет никакой аутентификации.

Даже если вы выдаете токен, вы выдаете его сервером и валидируете его на сервере, аналогично кукам.

Даже если вы выдаете токен, вы выдаете его сервером и валидируете его на сервере, аналогично кукам.

верно, но когда говорят "сохранить куки с сервера" как было выше

это как бы не то.

Ну сервер отдал куки и все, никакого состояния он не хранит

Ну сервер отдал куки и все, никакого состояния он не хранит

а зачем куки клиентосу?

См. выше ссылку - там приведен пример когда куки клиенту нужны.

Затем что с точки зрения клиента кука - это сохранение состояния клиента, которое может определять флоу внутри приложения.

На рестфульность апи это, опять же, никак не влияет.

Если у вас на сервере нет признаков состояния клиента, которые не хранятся на клиенте - рест не нарушается. Если вы с клиента передаете при запросе куки, которые выписаны на сервере и валидируются на сервере - вы все ещё передаете полный стейт клиента, как рест и завещал.

REST это аутентификация по токенам, а не по куки, вот о чем я говорю. Если человек получил токен и положил в куки, а потом достал токен из кук и вставил в запрос и отправил это одно, а другое дело аутентификация по куки

Типичная авторизация по куки - это когда в ней хранится id серверной сессии. Но в данном случае может храниться токен, и тогда это все равно будет REST

РЕСТ никак не относится к авторизации.

Покажите мне, пожалуйста, принцип REST, который говорит "Извините, но авторизация только по токену, иначе не RESTFul." Правда интересно.

ладно, давайте закончим спор ради спора

> Если человек получил токен и положил в куки, а потом достал токен из кук и вставил в запрос и отправил это одно, а другое дело аутентификация по куки Ну да правильно - в первом случае все ок. А во втором случае непонятно что ты имеешь в виду под "авторизация по куки"

*аутентификация

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

и потом по нему ходишь

что противоречит

https://restfulapi.net

Да, это не REST. И это мы не обсуждаем.

> Session state is therefore kept entirely on the client. Всьо.

Как его хранить - в виде куки, токена или jpg картинки в метадате к запросу - не важно вообще.

Здаров, кто-то пробовал парное тестирование внедрять в конторе?

У нас есть. Но там кейсы особые.

если сервер хранит сессию или куки (для работы между клиентом и сервером) - это нарушает принцип REST архитектуры.

Спасибо, что напомнили очевидные вещи. Реальность такова, что никто не создаёт REST pure, все делает RESTish / RESTful сервисы

Почему так ? Да потому что рест невыразителен, трудно дебажить (смотреть в кучу разных мест) и некоторые http глаголы ещё и по подноса себя ведут с браузере

Отчасти необходимость в куках как способе хранить стейт остаётся актуальной

У нас есть. Но там кейсы особые.

в каком смысле?

в каком смысле?

В прямом. В системе происходит взамиодействие пользователей в реальном времени. Вот два тестировщика и взаимодействуют.

Это частично решает проблему шаринга знания внутри qa команды. Потому что приходится много общаться

на этапе начального внедрения для тестеров которые ничего не знают о специфике gds или АПИ или мобильного тестирования не выйдет так "Эй Дима, тести что не знаешь" - поэтому пока что это не рационально

у нас тестеры не занимались вообще другими проектами, они тупо в своих командах сидят

В этом и смысл, что человек то что не знает, берет того кто знает, и получает недостающих знаний ?

если гугл не помогает ?

Но вообще да, вначале заходило "больно" сейчас уже все адаптировались

поэтому надо их выводить из зоны комфорта и чтоб делалились знаниями. Ваша идея в целом хороша, но я хочу начать пока с парного тестирвоания, а потом можно сказать чтоб брали неизвестные для них задачи. Но с другой стороны, если этого человека нет который подскажет, нет смысла заниматься задачей которую не можешь выполнить - профита от этого мало. ПОэтому спецу лучше выполнить в первую очередь самое простое, что он знает. И в целом по таймменеджемнту лучше выполня ть сразу простые задачи чем сложные, это даже более гармонично осознаётся спецу

Но вообще да, вначале заходило "больно" сейчас уже все адаптировались

Да это хорошо, но предпочту деликатно к изменениям подойти

В прямом. В системе происходит взамиодействие пользователей в реальном времени. Вот два тестировщика и взаимодействуют.

теперь ещё менее понятно)

теперь ещё менее понятно)

два пользователя взамодествуют посредством видеосвязи и кучи функций к ней добавленной

Но вообще да, вначале заходило "больно" сейчас уже все адаптировались

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

Если нет qa который знает, всегда есть разработчик

Это так же поможет налаживать общение dev-qa

ааа ну так это не про парное тестирование) Это в целом ваша тактика тестирования

но это еще зависит от того кому у вас пренадлжит qa команда, владельцу продукта, или разработке

Команда куа - свободные люди, мы никому не принадлежим (с)

разработке, у нас продукт свой, tickets.ru

xD

Я больше про то, qa является саппортом разработки, или самостоятельной еденицей которая контролирует процессы разработки, и занимается приемкой задач(в том числе решениями, о возможности выливки в прод)

Это так же поможет налаживать общение dev-qa

согласен

Я больше про то, qa является саппортом разработки, или самостоятельной еденицей которая контролирует процессы разработки, и занимается приемкой задач(в том числе решениями, о возможности выливки в прод)

ДА!

Ребят, очередной холивар щя задвину) Пока нахожусь в поиске работы, хочу попробовать себя в фрилансе. Суть вопроса - где лучше всего стартовать как фрилансер? Опыт тестирования у меня специфичный, и вряд ли на фрилансе есть тестирование контролерров или робототехники. Английский не боюсь, сайты тоже тестировать умею. Мануальщик.

Лучше стартовать на всех платформах сразу, потому что в том, что касается ручного тестирования придется претерпевать конкуренцию из миллиона индусов и вот всего этого.

Плюс адекватных заказов на ручное тестирование в целом-то не сильно много.

Я больше про то, qa является саппортом разработки, или самостоятельной еденицей которая контролирует процессы разработки, и занимается приемкой задач(в том числе решениями, о возможности выливки в прод)

тестировщики нафиг не нужны, когда разработчики эффективно используют TDD, парное программирование и работает по XP

Все зависит от проекта

тестировщики нафиг не нужны, когда разработчики эффективно используют TDD, парное программирование и работает по XP

Как вы пришли к такому выводу?

не думаю что тестирование для фриланса это хорошо

всмысле том что платить нормально никто не будет

фриланс это фронтенд разработка дизайн там норм на фрилансе

на сколько я знаю обычно со временем уходят от TDD разработки

не вникал в эту тему, но есть такие данные

Разработчики ещё не сильно стремятся к улучшению своих практик и их лиды тоже не оч стремятся, Поэтому захожу из далека, как раз со стороны тестирования, чтобы руководство видело, что практики которые я внедряю работают и повышают эффективность. Попробую парное тестирование, затем парное тестирование тестирование с разработчиками, паралельно чтоб разработчики начали выполнять код ревью активность, затем чтобы разработчикам преподнести парное программирование, на этом этапе попробую внедрить юнит тестирование. К сожалению, когда пробовал агресивно ввести распространённые практики, очень сильное отторжение у всех лидов было.. "Пришёл тут воробчик, трещит про то что всё у нас плохо работает и надо всё менять" - поэтому приходится деликатно вводить практики повышения качества

Как вы пришли к такому выводу?

Работал в такой команде, а потом уволили) И знаю лично разработчиков которые так работают, ну к примеру компанию codeborne

зависит от проекта, коненчо

Работал в такой команде, а потом уволили) И знаю лично разработчиков которые так работают, ну к примеру компанию codeborne

Хорошо. У вас есть TDD, XP и Парное программирование. Нет выделенных QA. Кто формирует критерии качества продукта, следит за соответствием релизов оным и прочее? Кто пишет E2E тесты на выпускаемый функционал? (Забегая наперед напомню, что TDD - это про юниты, если чо). Кто занимается исследовательским тестированием, или оно исключается из воркфлоу вообще, надеясь что все необходимые проверки автоматизированы? Кто отвечается за соблюдение code & product quality practices? Кто занимается ревью требований, дизайна и имплементаций? Я вот могу с уверенностью сказать, что ни в одном из упомянутых в первом предложении баззвордов не решается ни одна из этих проблем.

Т.е. отказаться от выделение QA-активностей в отдельного человека, безусловно, можно. Это нормально работающая история. Только вот TDD, XP и парное программирование не решает и трети проблем, которые должен решать QA.

всмысле том что платить нормально никто не будет

нормально платят, если работать )