Estou desenvolvendo um novo serviço em um ambiente de microsserviços. Este é um serviço REST. Para simplificar, digamos que o caminho seja: / historyBooks
E o método POST para esse caminho cria um novo livro de história.
Vamos supor que um livro de história cubra uma ou mais épocas da história.
Por uma questão de brevidade, vamos supor que temos apenas as seguintes épocas da história humana:
- Antigo
- Pós Clássico
- Moderno
No meu código, eu gostaria de representá-los em um enum
.
O corpo do método (a carga útil) está no formato JSON e deve incluir um nome de campo eras
. Este campo é uma lista de era
valores que este livro aborda.
O corpo pode parecer com:
{
"name": "From the cave to Einstein - a brief history review",
"author": "Foo Bar",
"eras": ["Ancient", "Post Classical", "Modern"]
}
Nesse serviço específico, a lógica de negócios é:
Se nenhuma Eras foi fornecida na entrada, este livro é considerado para cobrir todas as Eras.
Na revisão da API, foi feita uma sugestão:
inclua outro valor ALL
, para a enum das eras, para indicar explicitamente que todas as eras estão cobertas.
Eu acho que tem alguns prós e contras.
Prós:
Entrada explícita
Contras:
Se dois itens da lista forem fornecidos, diga ALL
e Ancient
- o que será retirado do aplicativo? Eu acho que isso ALL
deve substituir os outros valores, mas essa é uma nova lógica de negócios.
Se eu executar uma consulta, para livros que cobrem épocas específicas, como eu representaria um livro que cubra todas as épocas? Se ALL
também for usado para a saída (usando a mesma lógica), é responsabilidade do consumidor interpretar ALL
como ["Ancient", "Post Classical", "Modern"]
.
Minha pergunta
Eu acho que ter o novo ALL
causa mais confusão do que não tê-lo.
O que você acha? Você adicionaria esse ALL
valor ou manteria sua API sem ele?