Errores de diseño que perjudican tu API REST

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

[Chemaclass]

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

[EnchantWolf]

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.

[ftwtf]

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!

[mddx]

buenos consejos para alguien que esta comenzando en este mundo gracias

[haroldpepete]

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

[Frest]

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

[claveralvaro]

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

[michaelandresdiazcastillo]

para añadir se a empezado a popularizar el estandar rfc9457 para la devolucion de errores, para que lo tengan en cuenta

[compartelo]

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

[victorbarahona]

que buen video, gracias por compartir tu conocimiento y experiencia

[edualdansarmientog.]

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

[manuelvega.]

Que buen video y que bien explicado. Felicitaciones Dani!

[marcelodf]

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.

[miguel.sanjurjo]

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!

[wineloy]

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

[RichardAPalaciosG]

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

[yeirodriv]

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

[jymbo]

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.

[manusoftar]

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.

[aaronvigil]

Gracias algoritmo de youtube por presentarme este video. Suscripto.