В>>Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).
S>А можно попо дробнее с этого места?
S>Как именно вы предлагаете получать ID при сохранении? Да ещё и так, чтобы не было тормозов?
S>Я знаю три способа, из них два — неправильные:
S>1. Берём и делаем POST /mytransactions/<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>При получении таймаута, 10060, или 50x мы начинаем дорогостоящую процедуру восстановления синхронности клиента и сервера
S>2. Берём и делаем POST /mytransactions/<CRLF>X-Request-ID: 9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}.
S>Тут мы хотя бы имеем возможность корректно обработать фейлы. Но эта обработка достаточно неудобна: нам надо иметь какой-то временный ID нашей транзакции (а точнее — реквеста по её созданию), который потом заменять на "настоящий" ID, который вернёт сервис.
S>3. Ну, и нормальный способ — берём и делаем PUT /mytransactions/9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>ID транзакции известен в момент её порождения, он ничем не будет заменяться, ждать сервера для его получения не надо.

Я не уверен, что мы говорим об одном и том же.
Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?