HTTP-ответ асинхронной операции микросервисов

Учитывая, что идентификаторы вновь созданного объекта project неизвестны во время запроса (т.е. он генерируется после вставки в базу данных), вы действительно не можете создать URL-адрес ресурса project.

Вместо этого вы можете присвоить команде идентификатор (например, 1234-abcd-5678-efgh) перед отправкой в ​​шину и отслеживать статус ее выполнения на самом API-шлюзе. Затем вы можете ответить клиенту с помощью конечной точки состояния выполнения команды, такой как /commands/1234-abcd-5678-efgh, где он может запрашивать путем опроса.

Альтернативой может быть использование другой службы, которая резервирует и доставляет уникальные идентификаторы, но вы должны сделать блокирующий вызов, а это вредит масштабируемости. Или вы можете разместить эту службу внутри самого шлюза API (на том же узле), чтобы свести к минимуму задержку. Кроме того, существует риск потери некоторых идентификаторов в случае сбоев при создании проекта, но это можно компенсировать, освобождая эти идентификаторы в таких ситуациях (таким образом увеличивая сложность архитектуры).

Третьим решением может быть использование суррогатного идентификатора project, такого как GUID, назначенного как свойство project, включенного в команду, с целью альтернативного идентификатора, который можно использовать только на этапе предварительного создания команды. процесс. Тогда ответ клиенту может быть таким: /projects/by-guid/1234-abcd-5678-efgh и после создания project GET на этот url будет постоянно перенаправляться на окончательный URL-адрес проекта.