Errores de diseño que perjudican tu API REST 

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í!

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

buenos consejos para alguien que esta comenzando en este mundo gracias

Que buen video y que bien explicado. Felicitaciones Dani!

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.

Gracias por los consejos, todos super útiles y además necesarios.

Excelentes consejos. Estoy muy de acuerdo con los puntos que tocaste.

que buen video, gracias por compartir tu conocimiento y experiencia

Excelente y conciso.

Muy bueno, me quedo con lo de meter el array dentro de un Json, no lo había pensado

Ahora si le encuentro sentido que muchas Apis envuelvan las listas en un atributo "data" Grande Crack!

Consejazos se avienta este sujeto . Gran canal, sigue así. * c suscribe *

Grande Dani, con tu estilo!

¡Buen vídeo!

Gracias!

Gracias por compartir tu experiencia

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!

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.

Muy bueno :)

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!

thanks, it actually let me through so i could download it.

Gracias

Sos un crack man

bien dicho!!

Muchas gracias por los consejos, estare atento a esas gemas de http que mensionas. Un buen dia.

Buen video

Excelente

Gracias algoritmo de youtube por presentarme este video. Suscripto.

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...

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.

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

👌

Hola! Tengo una duda, soy nuevo en esto, la arquitectura REST entonces es para crear las API's??

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.

El 1 y 2 son basicamente mi dia a dia 😅

me toco ver un proyecto donde todas las llamadas eran POST, en todas las apis para todo los request

¿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)?

Anímate que animas ...

Gracias!

Gracias!