Здравствуйте, Shmj, Вы писали:

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

POST не обязан быть идемпотентным, но никто не мешает сделать его идемпотентным.

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


S>

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

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

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

Я бы так и сделал.

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

Ну вот я недавно думал над этим и решил, что ключи должны быть только UUID. Минусов у UUID почти нет, а плюсов много.

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

Ну в идеале — согласен. На практике не всегда получается это выполнять. Ограничения архитектуры или старого кода могут играть роль. К примеру в браузере нельзя послать PUT на другой домен без разрешений CORS, а POST с определёнными ограничениям — можно. Ну это просто пример.