Errores de diseño que perjudican tu API REST
HTML-код
- Опубликовано: 30 июл 2024
- Hay muchas formas de cometer errores al crear APIs REST, pero no todas son igual de sutiles. En este vídeo te cuento cinco malas prácticas de las que debe estar pendiente si quieres tener una API de mejor calidad.
0:00 Introducción a las APIs REST
2:01 (Común) 1. Usa bien el código de retorno
4:03 (Común) 2. Usa bien el verbo de la petición
6:48 (✨ Raro) 3. No devuelvas arrays
8:28 (✨ Raro) 4. Recuerda paginar
10:45 (✨ Raro) 5. No reinventes cabeceras HTTP
12:06 Cierre
🔔 ¡Suscríbete ya! ruclips.net/user/makigas?sub_confi...
➕ Más tutoriales en: www.makigas.es
⭐ Programa de miembros: youtube.com/@makigas/join
📝 Foros de la comunidad: foro.makigas.es
💬 Servidor de Discord: discord.makigas.es
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 ;)
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
Que buen video y que bien explicado. Felicitaciones Dani!
Ahora si le encuentro sentido que muchas Apis envuelvan las listas en un atributo "data"
Grande Crack!
Excelente y conciso.
Gracias por los consejos, todos super útiles y además necesarios.
Excelentes consejos. Estoy muy de acuerdo con los puntos que tocaste.
Gracias por compartir tu experiencia
que buen video, gracias por compartir tu conocimiento y experiencia
¡Buen vídeo!
Muy bueno, me quedo con lo de meter el array dentro de un Json, no lo había pensado
Grande Dani, con tu estilo!
buenos consejos para alguien que esta comenzando en este mundo gracias
Gracias!
Consejazos se avienta este sujeto . Gran canal, sigue así. * c suscribe *
Muy bueno :)
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!
Sos un crack man
Buen video
bien dicho!!
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.
Gracias
thanks, it actually let me through so i could download it.
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!
Excelente
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.
Muchas gracias por los consejos, estare atento a esas gemas de http que mensionas. Un buen dia.
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 cuando al punto 4 (paginar), algo curioso es que spotify no página el listado de canciones de las listas de reproducción, es curioso...
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.
11:55 auténticas Jemmas
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.
Lo de la paginación es un dato clave...
👌
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
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
me toco ver un proyecto donde todas las llamadas eran POST, en todas las apis para todo los request
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...
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
¿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 ...
Gracias!
Gracias!