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?