Padronização de erros em APIs com Problem Details

O tema padronização em APIs sempre é muito importante, ainda mais quando falamos de retorno para os usuários. Nesse vídeo, veremos a padronização do retorno de erros das APIs utilizando Problem Details descrito na RFC 7807.
Assista a live na íntegra: www.youtube.co...
---------------------------------
Comunidade no Discord: bit.ly/andresec...
Siga-me também nas plataformas:
Site/Blog: andresecco.com.br
Twitch: / andresecco
Facebook: / andresecco.fanpage
Twitter: / andre_secco
Instagram: / secco.andre
GitHub: github.com/and...
#ProblemDetails #API #Erros #Errors #Padronização #RFC7807

[@alexanlp]

André, caberia um logar os detalhes ai nesse seu método de extensão para produção, né?

Sim, ainda não abordei a parte de logs nessa aplicação, mas sim...no caso dessas exceções é importante registrar em logs

[@dandantasgameplays]

Por que o status code deveria ser colocado no body se já está presente no header? Não seria redundante?

Então, a ideia é padronizar, agrupando o máximo de informações necessárias sobre um erro sem ter que recorrer a outras fontes de informação. Sem contar que o status code original gerado pelo sistema (que recebemos via status code convencional do HTTP) pode ser modificado ao longo do caminho por algum proxy ou cache no caminho. Dessa forma, ter o status code também no corpo da resposta pode garantir o status code originalmente gerado pelo sistema, sem a alteração de outros fatores. Isso pode ser consultado no capítulo 5 da RFC 7807 que citei no vídeo: www.rfc-editor.org/rfc/rfc7807