См. статью от великого Яндекса: https://habr.com/ru/company/yandex/blog/442762/

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

Вот решение "стажера" по идемпотентности:

POST /v1/orders

{
  "from": "Москва, ул. Садовническая набережная 82с2",
  "to": "Аэропорт Внуково",
  "idempotency_key": "786706b8-ed80-443a-80f6-ea1fa8cc1b51"
}

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

Не логичнее ли вместо idempotency_key использовать ID и сделать этот ID типа UUID v4? Ведь по сути именно это хотел изобразить стажер:

PUT /v1/orders/786706b8-ed80-443a-80f6-ea1fa8cc1b51

{
  "id": "786706b8-ed80-443a-80f6-ea1fa8cc1b51",
  "from": "Москва, ул. Садовническая набережная 82с2",
  "to": "Аэропорт Внуково"
}

Какие минусы в этом?

Минус очевидный — это диктует тип ключей — только UUID. А если хочется чтобы ключи генерила СУБД и там спец. система для распределенной генерации ключей? Т.е. такой PUT как бы обязывает применять новую схему создания ключей.

И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.