Совсем идеальный вариант: клиент генерирует GUID и для него создаёт свою локальную запись. Далее сразу или по нажатию кнопки "сохранить", происходит синхронизация с сервером. Если на сервере нет записи с таким GUID, то она создаётся. Если есть, то проверяются права доступа и если всё ок, то изменения применяются.
Чем это хорошо:
1. Все запросы идемпотентные (их можно безопасно повторять при затыках сети).
2. Даже у не сохранённой на сервере записи есть уникальный идентификатор, что сильно упрощает клиентскую логику.
3. Не захламляется база данных временными записями.
4. Логика работы клиента не зависит от протокола взаимодействия. Вам не нужно предварительно создавать запись, прежде чем её редактировать, не нужно иметь две различные логики работы для записей с локальными идентификаторами и с серверными. Просто создаёте записи и работаете с ними, а взаимодействие с сервером обеспечит отдельный заменяемый адаптер.
5. GUID можно генерировать сразу человекопонятным. Например, для блога это может быть "vintage/2017-03-08T12:47:33". Обратите внимание, что тут мы не позволяем создавать более одного поста в секунду. Записи, созданные в одну и ту же секунду будут одной и той же записью.
6. Вы сами решаете когда и как сохранять данные на сервер и это не навязывается вам протоколом.
7. На запись, которая ещё не сохранена, уже можно дать ссылку. Фактически создана она будет лишь после первого редактирования. Актуально для вики проектов, где вы сначала создаёте ссылку, потом по ней переходите, и только тогда уже заполняете.
Чем это плохо:
1. сквозная нумерация не представляется возможной. Но она и редко когда необходима.
2. Идентификаторы получаются относительно длинными. С другой - они могут содержать некоторую метаинформацию. Например - когда, кем и где создана.
3. В базе для GUID должна быть дополнительная текстовая колонка с уникальным индексом. Но скорее всего всё-равно у вас такая будет, когда начнёте внедрять [slug](
https://ru.wikipedia.org/wiki/Семантический_URL#Slug) для человекопонятности.
