Molan mucho estos vídeos donde tratas un tema concreto y das pinceladas de realidad, especialmente para los que están empezando en el sector. Sigue así!
Increible amigo, son de los mejores consejos, principalmente la paginacion, eso es algo que veo a diario en m itrabajo, como otros programadores lo ignoran por completo y terminan luego enviando 2k de registros en poco tiempo, y entonces alli se preguntan, Como lo pagino? y hay que rehacer muchas cosas cuando es asi, tanto del lado back como del lado front.
Buen video! esta info debería ser más reconocida, yo el año pasado caí en un proyecto de una API desde cero para una administración pública y menuda fiesta. En mi empresa hacen esto que comentas en 3:17 (http code 200 para todo). La razón exacta por la que lo quieren así no la sé, pero es una aplicación que consume un montón de APIs externas y ya monitoriza internamente esas subllamadas. Deduzco que es por organización de trazas de logs... Otra empresa en la que estuve recuerdo que para obtener documentos sensibles no usaban GET, ya que necesitaban mandar varios parámetros sensibles en el body del POST. es un escenario a tener en cuenta. Me gustaría también mencionar otro error poco común. Y es el de no trocear las subida de ficheros! (ficheros grandes evidentemente) Un saludo master!
otro dato importante es comprobar que la cantidad de registros que estan solicitando no exceda el limite maximo de registros por peticion, porque algunas apis no controlan ese limite y clientes maliciosos dentro de su peticion pueden sobreescribir ese parametro en el querystring y sobrecargar tu servidor con consultas que devuelvan demasiados registros
Negro sobre blanco. Cualquiera que haya trabajado con APIs REST se habrá encontrado tarde o temprano con contratiempos por haber consumido servicios con alguno de los problemas que mencionas (o necesitar modificar un API propia con estos mismos problemas). Buenos consejos!
Me hubiera gustado ver algo de código en el video, para que quede más claro lo que intentas explicar, ya que como soy nuevo en esto, no lo tengo tan fácil de visualizar en código.
Yo en mi trabajo he tenido algunos desacuerdos con mis compañeros porque suelen utilizar el código de respuesta 404 cuando un servicio GET no tiene datos para retornar. Yo considero más apropiado utilizar un código 204 (no content) porque un 404 (not found) podría significar que el frontend no puedo localizar o comunicarse con el endpoint y no necesariamente que el endpoint no trajo resultados.
Ojo, nunca lo había visto así y me resulta super interesante. Yo hasta ahora sólo uso el 204 en un DELETE y realmente lo hago porque es lo que he visto que recomiendan en muchas APIs. Me gusta la idea.
@@kevinmendoza9606 yo uso 200 en esos casos y retorno la cantidad de registros afectados o bien un mensaje reforzando que todo se ejecutó correctamente...
es erróneo lo que comentas de los códigos 400. dado que toda la lógica se ejecuta correctamente, y digamos por ejemplo un usuario ya se encuentra y no puede ser creado, no corresponde que devuelva algún 400 para indicar un error, ya que los 400 están orientados más a permisos o errores de servidor, sin embargo al hacer mi ejemplo sí se ejecuta todo correctamente, el que exista o no un dato que me satisfaga no está relacionado con el http status.
He entendido cero unidades de información pero te informo que los errores de servidor son los 500, no los 400 como dices, developer.mozilla.org/en-US/docs/Web/HTTP/Status
Esque ya de por si si no usas las formas que dijiste ya no es una api rest, solo seria una simple api , también esta el api rest full si manejas hateoas
Uso de put para insertar datos en base de datos. No uso del lenguaje de las cabeceras sino creación de uno propio estilo: HEADER_LANGUAGE. Uso de json para devolver los errores, en lugar de devolver en el response un 404 o algo así se devolvia un codigo puntual dentro de un json, pero todas las respuestas eran 200.
Molan mucho estos vídeos donde tratas un tema concreto y das pinceladas de realidad, especialmente para los que están empezando en el sector. Sigue así!
Se trata de compartir todas mis cagadas, que no son pocas, para que no sigan mi ejemplo ;)
buenos consejos para alguien que esta comenzando en este mundo gracias
Muy bueno, me quedo con lo de meter el array dentro de un Json, no lo había pensado
Increible amigo, son de los mejores consejos, principalmente la paginacion, eso es algo que veo a diario en m itrabajo, como otros programadores lo ignoran por completo y terminan luego enviando 2k de registros en poco tiempo, y entonces alli se preguntan, Como lo pagino? y hay que rehacer muchas cosas cuando es asi, tanto del lado back como del lado front.
Buen video! esta info debería ser más reconocida, yo el año pasado caí en un proyecto de una API desde cero para una administración pública y menuda fiesta.
En mi empresa hacen esto que comentas en 3:17 (http code 200 para todo). La razón exacta por la que lo quieren así no la sé, pero es una aplicación que consume un montón de APIs externas y ya monitoriza internamente esas subllamadas. Deduzco que es por organización de trazas de logs...
Otra empresa en la que estuve recuerdo que para obtener documentos sensibles no usaban GET, ya que necesitaban mandar varios parámetros sensibles en el body del POST. es un escenario a tener en cuenta.
Me gustaría también mencionar otro error poco común. Y es el de no trocear las subida de ficheros! (ficheros grandes evidentemente)
Un saludo master!
Consejazos se avienta este sujeto . Gran canal, sigue así. * c suscribe *
Gracias por los consejos, todos super útiles y además necesarios.
Grande Dani, con tu estilo!
Ahora si le encuentro sentido que muchas Apis envuelvan las listas en un atributo "data"
Grande Crack!
Excelentes consejos. Estoy muy de acuerdo con los puntos que tocaste.
que buen video, gracias por compartir tu conocimiento y experiencia
Que buen video y que bien explicado. Felicitaciones Dani!
Gracias!
Gracias algoritmo de youtube por presentarme este video. Suscripto.
Eso es que estoy dándole al algoritmo lo que quiere. Welcome! 🚀
@@makigas dale de comer a ese maldito, jajajaja. Buen video.
Excelente y conciso.
thanks, it actually let me through so i could download it.
Muchas gracias por los consejos, estare atento a esas gemas de http que mensionas. Un buen dia.
otro dato importante es comprobar que la cantidad de registros que estan solicitando no exceda el limite maximo de registros por peticion, porque algunas apis no controlan ese limite y clientes maliciosos dentro de su peticion pueden sobreescribir ese parametro en el querystring y sobrecargar tu servidor con consultas que devuelvan demasiados registros
Negro sobre blanco. Cualquiera que haya trabajado con APIs REST se habrá encontrado tarde o temprano con contratiempos por haber consumido servicios con alguno de los problemas que mencionas (o necesitar modificar un API propia con estos mismos problemas). Buenos consejos!
Gracias
bien dicho!!
Sos un crack man
Sobre el punto de encapsular un array en un objeto. Para enviar metadata como la paginación, una opción es enviársela en el response header.
Me hubiera gustado ver algo de código en el video, para que quede más claro lo que intentas explicar, ya que como soy nuevo en esto, no lo tengo tan fácil de visualizar en código.
¡Buen vídeo!
Gracias por compartir tu experiencia
Buen video
Excelente
11:55 auténticas Jemmas
Yo en mi trabajo he tenido algunos desacuerdos con mis compañeros porque suelen utilizar el código de respuesta 404 cuando un servicio GET no tiene datos para retornar. Yo considero más apropiado utilizar un código 204 (no content) porque un 404 (not found) podría significar que el frontend no puedo localizar o comunicarse con el endpoint y no necesariamente que el endpoint no trajo resultados.
Ojo, nunca lo había visto así y me resulta super interesante. Yo hasta ahora sólo uso el 204 en un DELETE y realmente lo hago porque es lo que he visto que recomiendan en muchas APIs. Me gusta la idea.
Solo uso el 204 cuando uso algún post put o delete y no devuelvo datos
@@kevinmendoza9606 yo uso 200 en esos casos y retorno la cantidad de registros afectados o bien un mensaje reforzando que todo se ejecutó correctamente...
Lo de la paginación es un dato clave...
El error de no devolver una lista, no lo sabía. ¿Se podría devolver un map luego de modelarlo con los pares clave:valor qué se necesitan?
En el error de los códigos equivocados estaría bien una explicación de qué consecuencias negativas puede tener. Por lo demás, muy buen vídeo.
Hola! Tengo una duda, soy nuevo en esto, la arquitectura REST entonces es para crear las API's??
Sí
El 1 y 2 son basicamente mi dia a dia 😅
Mauriiiiiii
me toco ver un proyecto donde todas las llamadas eran POST, en todas las apis para todo los request
es erróneo lo que comentas de los códigos 400. dado que toda la lógica se ejecuta correctamente, y digamos por ejemplo un usuario ya se encuentra y no puede ser creado, no corresponde que devuelva algún 400 para indicar un error, ya que los 400 están orientados más a permisos o errores de servidor, sin embargo al hacer mi ejemplo sí se ejecuta todo correctamente, el que exista o no un dato que me satisfaga no está relacionado con el http status.
He entendido cero unidades de información pero te informo que los errores de servidor son los 500, no los 400 como dices, developer.mozilla.org/en-US/docs/Web/HTTP/Status
Esque ya de por si si no usas las formas que dijiste ya no es una api rest, solo seria una simple api , también esta el api rest full si manejas hateoas
👌
¿Cuál es el error de diseño que has visto alguna vez en una API que te ha hecho decir 'agg' (y que puedas contar, claro)?
aun no! estoy aprendiendo frontend, pero tengo miedo de mandarme un moco grande si trabajo en backend jaja
gracias por los videos!
Uso de put para insertar datos en base de datos. No uso del lenguaje de las cabeceras sino creación de uno propio estilo: HEADER_LANGUAGE. Uso de json para devolver los errores, en lugar de devolver en el response un 404 o algo así se devolvia un codigo puntual dentro de un json, pero todas las respuestas eran 200.
Cuando trabajas con gente que viene de SOAP y te regresan el status de la petición en un campo xd
APIs sin documentación
Anímate que animas ...
Muy bueno :)
Gracias!