Негативные сценарии и идемпотентность: 401, 403, 409, 422 и Idempotency-Key

Оля · DevOps, #qa-antrakt

Итоги репетиции «Ночи продаж» на стадионе в Казани. Мобильная сеть под трибуной проседала, приложение не дожидалось ответа за 10 секунд и повторяло POST /orders. 312 зрителей получили по два заказа и два списания. Поддержка возвращала деньги до часу ночи.

Тимур · бэкенд, #qa-antrakt

Уже добавил Idempotency-Key: приложение шлёт ключ, повтор с тем же ключом отдаёт тот же заказ. Работает, проверил руками в Swagger два раза.

Вера Ланская · лид QA, #qa-antrakt

«Проверил руками два раза» это одна позитивная проверка. Пусть тесты проверят ключ со всех сторон. И заодно все отказы API: на репетиции половина жалоб была на ответы, которые API должен был дать и не дал.

В уроке 50 ты разделил сценарии на позитивные и негативные и проверил границу лимита билетов. В прошлом уроке научился проверять форму удачного ответа. Сегодня займёмся неудачными ответами всерьёз: какой код что значит, как выглядит правильный отказ, где в API искать границы и как проверить, что повтор запроса не покупает билеты второй раз.

Кнопка лифта и охранник

Нажми кнопку вызова лифта пять раз. Лифт приедет один раз: каждое следующее нажатие ничего не меняет. Это идемпотентность, повтор безопасен. А теперь представь кнопку «оплатить», которая на каждое нажатие списывает деньги. Повтор уже не безопасен, и если связь оборвалась на середине, пользователь не знает, нажимать ли ещё раз.

С отказами похоже на охранника на входе в зал. Если у зрителя нет билета, охранник должен сделать три вещи: не пустить, объяснить, почему, и ничего при этом не испортить. Охранник, который не пускает, но рвёт билет, отказывает неправильно. Охранник, который от вопроса без билета падает в обморок, тоже.