API de repouso e DDD

No meu projeto usando a metodologia DDD.

O projeto possui a transação agregada (entidade). Esse agregado possui muitos casos de uso.

Para esse agregado, preciso criar uma API de descanso.

Com padrão: crie e exclua sem problemas.

1)CreateDealUseCase(nome, preço e muitos outros parâmetros);

POST /rest/{version}/deals/
{ 
   'name': 'deal123',
   'price': 1234;
   'etc': 'etc'
}

2)DeleteDealUseCase(Eu iria)

DELETE /rest/{version}/deals/{id}

Mas o que fazer com o restante dos casos de uso?

HoldDealUseCase (id, motivo);UnholdDealUseCase (id);CompleteDealUseCase (id e muitos outros parâmetros);CancelDealUseCase (id, alteração, motivo);ChangePriceUseCase (id, newPrice, motivo);ChangeCompletionDateUseCase (id, newDate, amercement, whyChanged);etc (total de 20 casos de uso) ...

Quais são as soluções?

1)Use verbos:

PUT /rest/{version}/deals/{id}/hold
{ 
   'reason': 'test'
}

Mas! Os verbos não podem ser usados no URL (na teoria REST).

2)Use o estado concluído(que será após o caso de uso):

PUT /rest/{version}/deals/{id}/holded
{ 
   'reason': 'test'
}

Pessoalmente, para mim parece feio. Talvez eu esteja errado?

3)Use 1 solicitação PUT para todas as operações:

PUT /rest/{version}/deals/{id}
{ 
   'action': 'HoldDeal',
   'params': {'reason': 'test'}
}

PUT /rest/{version}/deals/{id}
{ 
   'action': 'UnholdDeal',
   'params': {}
}

É difícil de manusear no back-end. Além disso, é difícil documentar. Como 1 ação tem muitas variantes diferentes de solicitações, das quais já depende de respostas específicas.

Todas as soluções têm desvantagens significativas.

Eu li muitos artigos sobre o REST na internet. Em todos os lugares apenas uma teoria, como estar aqui com o meu problema específico?

questionAnswers(4)

yourAnswerToTheQuestion