La forma correcta de devolver errores de una API
Vložit
- čas přidán 24. 07. 2024
- Guía sobre ProblemDetails para unificar respuestas de error en APIs HTTP utilizando La forma correcta de devolver errores de una API
Si te gusta el contenido, puedes apoyar al canal invitandome a un café www.buymeacoffee.com/netmentor
Miembros premium del la coumunidad: www.netmentor.es/miembro-premium
00:00 Introducción al estándar Poblem Details para APIs HTTP
00:36 Explicación estandard RF-9457 - Qué es Problem Details?
07:15 Implementación de Problem Details en C# - Věda a technologie
blog: www.netmentor.es/entrada/problemdetails-api
twitter/x: twitter.com/NetMentorTW
Ahí faltaría el atributo TraceId para tener un seguimiento exacto de las peticiones pero es buena la idea
Es el campo instancia
Muy buen video! - Una cosa que he visto en mi dia a dia es que en el front con Blazor, se implementa Polly, y a veces el codigo quiero que falle, que devuelva un 400; pero que Polly no reintente el request (Puesto que no es problema de red, servidor, etc) y si el policy esta seteado en 3 intentos, cada vez que de problema siempre tendra el mismo resultado.
Me parece genial poder implementar el standard para el error. Pero una idea para otro video, seria genial incluir la forma de como trabajar esas excepciones.
Excelente muy agradecido, tomado en cuenta para el prox proyecto. Saludos
Algo muy necesario, lo voy a probar en mis proyectos.
¡Buen vídeo!
Excelente video, a facilitarnos mas la vida cracks!
Genial!!
Yo usaba el de Microsoft Api Guiedlines, pero me gustó más este estandar. Lo probare.
No tenia idea de ese modelo existia, yo hice un DTO muy similar que el ProblemDetails para estandarizar mis respuestas, odio reinventar la rueda 😂
Yo lo uso desde net 3.1, en todos los proyectos que pueda
this is the way
Hola, seria muy intersante si pudieras hacer un video explicando el funcionamiento de la libreria ErrorOr
Imo, la Mia es mejor czcams.com/video/_l5vUf7W09A/video.html
Muy buen video, tengo una duda como harias para propagar los errores a ProblemDetail capturando los errores en cada capa? de antemano muchas gracias estoy aprendiendo mucho con tus videos
así: czcams.com/video/_l5vUf7W09A/video.html
Muy buen video!. quería hacerte una pregunta, me podrías decir que extensiones tu usas para programar, me parece muy interesante las extensiones que tienes y la agilidad que da a la hora de programar, pero no he podido encontrar cuales son esas extensiones jeje
Ninguna, bueno copilot es la única
Muy buen video, felicidades por el canal. Aun utilizas ROP? te pregunto por que yo lo implemente, ya que me gusto bastante. Pero hay algunos puntos concretos que no logro resolver. Me gustaria saver, si es posible como lo resolviste. Cuando tengo un proceso que utiliza varios objetos / variables para trabajar y este a su vez va generando diferentes resultados que necesitan ser guardados me forza a inyectar las variables en los métodos Map por ejemplo para preservar el resultado y poder continuar. Me gustaria mandarte una imagen pero parece no ser posible por este medio. Espero se haya entendido.
Si uso rop, en ese caso no hay mucho que hacer más que propagar la información, puedes hacer una cadena dentro de una cadena pero queda algo feo :/
Normalmente lo que hago es crear una clase que contiene lo que voy a necesitar y voy asignando valores, no es lo ideal, pero tampoco es un escenario muy común para mí, así que lo dejo pasar
@@NetMentor había pensado crear todas las variables antes de iniciar y crear un récord con ellas al final y así propagarlo, pero pierde algo de vista al forzar q todos los métodos utilicen ese record.
Se podria usar con fluent validation?
Si claro, no veo por qué no , aunque necesitarás algún middleware o alguna forma de customizar el error, pero si
Hola buenas! Cuando empiezas a picar en el controller el ProblemDetails, no es lo mismo usar FluentValidations? De hecho en las RuleFor puedes indicar mensajes personalizados o la misma validation te devuelve un mensaje por regla. Luego, bajo mi punto de vista, con la validation lo tienes todo más organizado ya que puedes meterlo en una carpeta "validations" (así lo hago yo) y poner ahí todas las validaciones por controller o DTO que tengas, por ejemplo Validations> ValidacionesPedidos > ValidationsEndpoint... o ValidationsDTO..., ... > ValidacionesTiendas> ValidationsEndpoint..., qué opinas?
no es lo mismo no, si quieres usar fluentvalidations por que te gusta está bien, pero no es lo mismo, ni es un estándar
Todo esta muy bien, en si pero a la especificacion creo que le falta un errorCode , por la sencilla razon de la internacionalizacion, el el frontend directamente no puede mostrar esos mensajes de error en ingles, que tal si quieres desplegar el error en español o italiano? actualmente el el frontend se atrapa el ""codigo de error"" y se lo convierte a su respectivo error en el idioma del usuario final, la espec que muestras solo esta el mensage y un pointer, lo que esta bien pero desde mi perspectiva yo le adicionaria el errorcode. saldos.
La especificación tiene un error code en el type. Como traduzcas Los errores a esta me da igual, puedes mandar el error code en Los errores extensibles o puedes traducir directamente en la api y devolver el error traducido.
Pero como digo, eso es opcional, así que en los extensibles.
@@NetMentor Se nota que nunca hiciste plataformas multilenguaje, yo trabajo en plataformas que se traducen a mas de 5 lenguajes, y la internacionalizacion es un problema, si el api retorna el error en un lenguaje base ejem. ingles no es nada util para el usuario final, y el api no debe preocuparse por traducer cada mensaje de error que pueden ser miles a diferentes idiomas, entonces lo mas practico es que el api devuelva un errorCode, ejem "PROJECT_EXISTS" entonces ese code ya se puede traducir en el lado del cliente, ten en cuenta que ya no solo es la web, estan las apps IOS, Android e incluso Microservicios, que consumen el mismo api.
Supongo que te da igual por que talvez nunca has necesitado al parecer.
Eso será, que no he trabajado en plataformas de más de un lenguaje ..
La librería de la que hablo en el video (la de result) permite incluir tradiciones.
El error code lo devuelve, es el type, si no quieres incluir un mensaje de error entendible por humanos, no lo incluyas. Nada tiene que ver una cosa con la otra.
Tu backend no debería depender del front end para ser funcional, pero eso es otra historia
@@NetMentor No bro el backend no depende del front-end en mi caso de uso, el backend principalmente solo bota error_code(s) que son universal entre tipos de clientes android, ios, web microservicios, y ya cada fron-end o lo que sea se encargue de traducir como mejor le parezca. por eso digo que mi caso de uso es mas importante un error code que un mensaje de error.
Yo justificando mis malas inversiones.