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