Na API da Web, é uma boa prática agrupar os resultados com o meu modelo? [fechadas]

5

Eu tenho uma API da Web, e estou pensando se é uma boa ideia sempre agrupar o resultado com um modelo de resultado próprio que sempre conterá uma estrutura específica como:

{
 Data:(of type T generic),
 Messages:[ 
   {Key:"Key1",Messages:["Msg1","Msg2","Msg3"]},
   {Key:"Key2",Messages:["Msg1","Msg2","Msg3"]},
  ],
 MetaData:[ 
   {Key:"",Value:"" },
   {Key:"",Value:"" }
  ]
}

Então, vejo que este modelo é adequado para todas as situações, por exemplo:

  1. Quero devolver o sucesso 20x apenas com dados, preencha apenas Dados propriedade e deixar os outros vazios.
  2. Se eu quiser retornar o status de falha com algumas mensagens (do estado do modelo ou qualquer outro), preencha apenas Mensagens .

Então eu sempre devolvo meu modelo.
Isso é considerado uma boa prática ou devo retornar um modelo diferente dependendo de cada status (sucesso ou falha).

Obrigado

Atualização 1:
Os códigos de status ainda serão usados para determinar se as mensagens dentro do modelo são mensagens de erro ou apenas aviso ou talvez informações, o que eu ' m pedindo aqui para abandonar o uso de Códigos de status , mas:

is it a best practice to use unified model in all my responses, maybe some times I need to response as BadRequest with data returned with the messages.

    
por Dabbas 13.10.2015 / 14:05
fonte

2 respostas

3

Eu acredito em web api Você deve manter as convenções e usar códigos de erro http para indicar falhas.

Pense em como você trataria sua mensagem no lado do recebimento:

  • Você teria que escrever algum tipo de lógica para realmente detectar se você teve um erro ou sucesso.

  • Você teria que explicar a convenção para outros desenvolvedores usando o código.

Eu diria que isso é um pouco de reinventar a roda. Na minha equipe, simplesmente usamos códigos de status HTTP com mensagens para relatar erros e parece estar funcionando bem. Também é mais simples lidar com certas bibliotecas relacionadas à Web que estamos usando no lado do cliente.

Editar após a atualização da pergunta: Na minha opinião, isso se resume a um caso de uso específico. Se você pensar em usar esse padrão sempre a partir de agora, eu não entraria nele.

Se você pretende introduzi-lo em um determinado serviço ou produto e é realmente verdadeiro (o que significa que há um caso de uso ou requisito), você terá que retornar alguns dados com um erro código tudo bem. Neste caso, não vejo nenhuma solução melhor.

    
por 13.10.2015 / 14:54
fonte
0

Considere o retorno de mensagens de erro de algum tipo, caso algo dê errado. Retornar um modelo mesmo que um erro tenha ocorrido provavelmente não é a melhor prática.

Por exemplo, quando nenhum dado foi encontrado, retornar null em vez disso é melhor prática.

    
por 13.10.2015 / 14:49
fonte

Tags