Estou projetando um serviço web RESTful utilizando ROA (arquitetura orientada a recursos).

Estou tentando descobrir uma maneira eficiente de garantir a idempotência para solicitações PUT que criam novos recursos nos casos em que o servidor designa a chave do recurso.

Pelo meu entendimento, a abordagem tradicional é criar um tipo de recurso de transação como / CREATE_PERSON. A interação cliente-servidor para criar um novo recurso de pessoa estaria em duas partes:

Etapa 1: obtenha um ID de transação exclusivo para criar o novo recurso PERSON :::

**Client request:**
POST /CREATE_PERSON

**Server response:**
200 OK
transaction-id:"as8yfasiob"

Etapa 2: Crie o novo recurso de pessoa em uma solicitação garantida como única usando o ID da transação :::

**Client request**
PUT /CREATE_PERSON/{transaction_id}
first_name="Big bubba"

**Server response**
201 Created             // (If the request is a duplicate, it would send this
PersonKey="398u4nsdf"   // same response without creating a new resource.  It
                        // would perhaps send an error response if the was used
                        // on a transaction id non-duplicate request, but I have
                        // control over the client, so I can guarantee that this
                        // won't happen)

O problema que vejo com essa abordagem é que ela requer o envio de duas solicitações ao servidor para realizar uma operação única de criação de um novo recurso PERSON. Isso cria problemas de desempenho, aumentando a chance de o usuário aguardar o cliente concluir sua solicitação.

Eu tenho tentado separar idéias para eliminar a primeira etapa, como pré-enviar IDs de transação a cada solicitação, mas a maioria das minhas idéias tem outros problemas ou envolve sacrificar a apatridia do aplicativo.

Existe uma maneira de fazer isso?

Editar::::::

A solução com a qual acabamos indo foi para o cliente adquirir um UUID e enviá-lo junto com a solicitação. Um UUID é um número muito grande que ocupa o espaço de 16 bytes (2 ^ 128). Ao contrário do que alguém com uma mente de programação possa pensar intuitivamente, é uma prática aceita gerar aleatoriamente um UUID e assumir que esse é um valor único. Isso ocorre porque o número de valores possíveis é tão grande que as chances de gerar dois do mesmo número aleatoriamente são baixas o suficiente para serem praticamente impossíveis.

Uma ressalva é que nossos clientes solicitam um UUID do servidor (GET uuid/) Isso ocorre porque não podemos garantir o ambiente em que nosso cliente está sendo executado. Se houver um problema, como propagação do gerador de números aleatórios no cliente, é muito provável que haja uma colisão de UUID.