Что такое идемпотентность?

А, идемпотентность! Ну это, блядь, классика, про которую каждый второй архитектор на собеседовании спрашивает, а потом в коде проёбывает. Слушай сюда, сейчас разжую.

Представь себе, что ты в баре. Ты подходишь к бармену и говоришь: «Дай мне стакан воды». Он даёт. Ты, ёпта, через пять минут опять: «Дай мне стакан воды». Он даёт такой же стакан. Это идемпотентность. А теперь представь, что ты говоришь: «Налей мне ещё стакан воды». Он наливает. Ты опять: «Налей мне ещё стакан воды». Он наливает второй. А ты уже не хочешь, у тебя уже два стакана, а он третий льёт. Вот это пиздец, это уже не идемпотентность. Понимаешь разницу? В первом случае результат — один стакан в твоей руке, сколько раз ни проси. Во втором — овердохуища стаканов, и ты уже тонешь.

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

Смотри, табличка, которую надо выучить, как «Отче наш», а то будешь выглядеть как манда с ушами на ретро:

• GET — идемпотентный. Это как спросить «который час?». Спрашивай хоть сто раз — время-то одно и то же (пока стрелки не сдвинутся, но это уже другая операция). Проверяй, что кэш не ебёт мозги.
• POST — НЕ идемпотентный, мать его. Это как сказать «роди мне ребёнка». Скажешь два раза — получишь близнецов, скажешь пять — получишь баскетбольную команду. Самый частый источник говна в тестах — дубли из-за повторных POST. Доверия к нему — ноль ебать.
• PUT — идемпотентный. Это как команда «поставь чашку на стол». Поставил — стоит. Ещё раз сказал «поставь чашку на стол» — она так и стоит на том же месте, не взлетает. Проверяй, что последняя команда победила, а не создала вторую чашку из воздуха.
• DELETE — идемпотентный, но хитрый. Первый раз говоришь «выбрось чашку» — она летит в урну. Второй раз говоришь — а её уже нет. Результат разный (сначала 200 OK, потом 404), но состояние системы после первого вызова не меняется: чашки нет. Это ок.
• PATCH — обычно НЕ идемпотентный. Это как сказать «долей в чашку воды». Скажешь раз — долил, скажешь два — перелил, скажешь три — потоп устроил. Подозрение ебать чувствую к этому методу.

Вот тебе пример, как проверить, что PUT не обманывает. Смотри код, его не трогаю, он святой.

@Test
public void testPutMethodIsIdempotent() {
    // Готовим нашего подопытного пользователя
    String userJson = "{"name": "TestUser", "email": "test@example.com"}";

    // Первый залп. Создаём/апдейтим юзера с id 123.
    given()
        .contentType("application/json")
        .body(userJson)
    .when()
        .put("/api/users/123")
    .then()
        .statusCode(200)
        .body("name", equalTo("TestUser"));

    // А теперь, внимание, хуй с горы! Шлём ТОЧНО ТАКОЙ ЖЕ запрос ещё раз.
    given()
        .contentType("application/json")
        .body(userJson)
    .when()
        .put("/api/users/123")
    .then()
        .statusCode(200) // Должен быть 200, а не 201 Created второй раз! Иначе пизда рулю.
        .body("name", equalTo("TestUser")); // Имя должно остаться TestUser, а не превратиться в TestUserUser.

    // Финальный аккорд. Дёргаем GET и убеждаемся, что всё на месте, как и должно быть.
    when()
        .get("/api/users/123")
    .then()
        .body("name", equalTo("TestUser"));
}

А что делать с этим ебанько POST, который плодит сущности как сука? Тут надо хитрить.

1. Уникальность. Пихай в каждый тестовый запрос что-то уникальное: timestamp, случайный UUID. Типа "email": "test_" + System.currentTimeMillis() + "@example.com". Чтобы второй запрос просто не прошёл по уникальности.
2. Уборка за собой. Перед тестом создал — после теста прибил. Или перед следующим прогоном всю базу тестовую в ноль. Чистота — залог ахуенных и стабильных тестов.
3. Проверка на адекватность. Если всё-таки шлёшь два одинаковых POST, сервер должен тебе вежливо, но жёстко сказать: «Чувак, ты чё, такое уже есть» — и вернуть ошибку 409 Conflict. Если он вместо этого создаёт дубликат — это повод написать баг-репорт размером с небольшую повесть.

Короче, запомни: идемпотентность — это когда от твоего запроса не должно быть мультиков, как от неконтролируемого POST. Один раз — и готово. Как горох об стенку.