Ahí faltaría el atributo TraceId para tener un seguimiento exacto de las peticiones pero es buena la idea
@NetMentor5 ай бұрын
Es el campo instancia
@davidriscanevo51455 ай бұрын
Algo muy necesario, lo voy a probar en mis proyectos. ¡Buen vídeo!
@tonym58575 ай бұрын
Excelente muy agradecido, tomado en cuenta para el prox proyecto. Saludos
@mbv4019201504 ай бұрын
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.
@JonathanSantos-pu8bf4 ай бұрын
Excelente video, a facilitarnos mas la vida cracks!
@joelrcc4 ай бұрын
Yo usaba el de Microsoft Api Guiedlines, pero me gustó más este estandar. Lo probare.
@OscarGarcia-up3ph5 ай бұрын
No tenia idea de ese modelo existia, yo hice un DTO muy similar que el ProblemDetails para estandarizar mis respuestas, odio reinventar la rueda 😂
@samuelsaravia76215 ай бұрын
Genial!!
@washingtonacero83755 ай бұрын
Yo lo uso desde net 3.1, en todos los proyectos que pueda
@NetMentor5 ай бұрын
this is the way
@yokiroalain41075 ай бұрын
Hola, seria muy intersante si pudieras hacer un video explicando el funcionamiento de la libreria ErrorOr
@NetMentor5 ай бұрын
Imo, la Mia es mejor kzbin.info/www/bejne/lZ2Yp4icbLxjb6M
@jeffersonsandoval45485 ай бұрын
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
@NetMentor5 ай бұрын
así: kzbin.info/www/bejne/lZ2Yp4icbLxjb6M
@johannbogota58575 ай бұрын
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
@NetMentor5 ай бұрын
Ninguna, bueno copilot es la única
@caballeromaya5 ай бұрын
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.
@NetMentor5 ай бұрын
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
@caballeromaya5 ай бұрын
@@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.
@felixjimcal5 ай бұрын
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?
@NetMentor5 ай бұрын
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
@marcosgarces79625 ай бұрын
Se podria usar con fluent validation?
@NetMentor5 ай бұрын
Si claro, no veo por qué no , aunque necesitarás algún middleware o alguna forma de customizar el error, pero si
@eriknyk2k5 ай бұрын
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.
@NetMentor5 ай бұрын
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.
@eriknyk2k4 ай бұрын
@@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.
@NetMentor4 ай бұрын
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
@eriknyk2k4 ай бұрын
@@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.