Backend: API REST que devuelve ids en vez de objetos (Hateoas mal)

#1 Bueno, si es una API rest pura y dura entiendo que es lo correcto. Lo que pasa es que no hay porque cerrarse a solo REST con endpoints simples de CRUD. Puedes hacer un Read mas complejo que evite esas requests inecesarias pidiendo otros parametros en la query, pero claro, entonces deja de ser solo CRUD y por ende REST. Pero es que al final lo de que sea REST o no es solo un "principio", no es una ley. A lo que me refiero es que definir una API como REST solo estandariza la forma de crear esa API, pero no implica que tu no puedas crear otras vistas o metodos si los organizas y documentas bien, aunque sean metodos que no hagan un Read estandar.

Por ejemplo crear otro metodo de busqueda que implique carga en el servidor y no en el cliente. Pero eso va muy determinado por la plataforma y por los recursos que tu quieras dedicar a ello.

Hay 1000 maneras de controlar y gestionar los recursos que tu asignas a un endpoint en un Backend, que es la unica excusa que se me ocurriria para negar o no aceptar hacer otro metodo que evite complejidad en el Frontend.

No soy programador de Frontend, entonces no entiendo al 100% que es lo mas correcto en Frontend, pero vamos, por la parte de Backend yo no veo pegas a facilitar recursos al Frontend, si al final es mas sencillo hacerlo en el backend. Para mi no hacerlos es poner piedras en el camino porque si.

Cuando es una API con cientos de miles de clientes, debes aportar la mayor flexibilidad posible, y es ahí donde HATEOAS tiene sentido; permite a los clientes poder navegar por las distintas entidades de la API y establecer las relaciones entre ellas según sus necesidades; reduces el acoplamiento y las concreciones al máximo y expones un comportamiento donde cualquier cliente, sea cual sea su necesidad, puede cubrirlo porque la API expone unos endpoints lo suficientemente abstractos.

Pero en una aplicación dedicada, dónde el front solo va a consumir X endpoints ya determinados de antemano, diseñar el backend siguiendo HATEOAS es una estupidez supina. Ahorras tiempo y restas complejidad añadiendo endpoints específicos como el que pides, a costa de aumentar el acoplamiento. Aún así, es un coste admisible si, vuelvo a repetir, es una app donde el front sólo necesita consumir X endpoints específicos.

Y como colofón, si el ejemplo que pones en #1 es una respuesta de la API, te voy a dar una mala noticia: eso no es una respuesta de una API REST con HATEOAS, así que enhorabuena, tu equipo de backend está compuesto de mongoloides cuya formación académica seguramente esté basada en 90% en leer posts en medium.

Puede ser algo usual en arquitecturas con microservicios con un API Gateway que redirige las peticiones al microservicio concreto del recurso (microservicio de usuarios, microservicio de vídeos, etc)

Puedes proponer que para evitar el exceso de peticiones se puedan obtener varios ids a la vez separados por puntos y comas estilo la API de Stackexchange :

categorias/3;15;230;99
usuarios/132214;3553

Aunque como todo también tiene sus limitaciones.

#13 Tienes el GET /videos para sacar el listado, y el GET /videos/1234 para sacar el detalle de un vídeo concreto.

Si necesitas sacar múltiples videos, tienes el listado, si necesitas sacar uno en concreto, tienes el detalle.

¿En qué situaciones se necesita buscar por múltiples ids a la vez? Cuando se dan esos casos, suele ser por un subconjunto de datos que guardan algo en común, por lo que quizá puedas reutilizar un servicio existente o tal vez sea necesario plantear el uso de subrecursos.

Por ejemplo, si quiero buscar los vídeos de un autor concreto, podría inicialmente plantearse así:

GET /authors/1234

{
	"id": 1234
	"videos": [
		1, 32, 56 
	]
}

Y luego buscar por identificadores:

GET /videos?id=1,32,56

Pero en realidad estamos tratando con un subconjunto de datos, que son los vídeos de un determinado autor, así que, ¿por qué no filtrar por dicho autor en el listado, o añadir un subrecurso al endpoint de autores?

Por lo que se podría hacer esto otro:

/videos?authorId=1234 

O bien con subrecursos:

/authors/1234/videos

Y luego, lo que dice #14 de embeber una representación parcial, es lo ideal (es lo que hace spotify). Siendo así, probablemente no tengas que hacer búsquedas de detalle, las búsquedas de detalle son ya para cuando seleccionas un item del listado y abres en tu aplicación para ver todos sus datos.

#17 Si tienes todo metido en el mismo sacó por película, imagínate que luego quieres buscar un actor y todas sus películas.

No tienen ni puta idea. Yo tambien lo he sufrido. En lugar de cargar una vista entera que eran 5kb y 1 request hacian que el usuario tuviese que ir haciendo clicks.. al final diez veces mas request y tardabas diez veces mas porque si... XD Yo hago endpoints específicos para casi todo, que suele ser web y mobil que tambien desarrollo yo... y adew.

No tengo nada que a;adir a lo que ya te han dicho los expertos.

Tan solo quiero decir que el mayor problema no es el dise;o, el problema es que tengas un equipo y algun "tech lead" o similar que justifique esa mierda y no sepa que eso esta mal. Red flag.

Quedate con el patron de dise;o que te comentan porque es el bueno y en la proxima entrevista de trabajo ya sabes que tema sacar.

A mi personalmente me parece una aberración solucionar este problema de esta forma, por mucho REST que sea y su madre. Si no te queda mas remedio, te haces un endpoint en back donde mapee lo que necesites.

¿Supongo que esto vendrá así porque es una base de datos no relacional?

#23 Eso huele a dos cosas: la primera que la descripción tiene valores null en algunos vídeos y la segunda es que usan alguna librería / framework para mapear automáticamente las entities a los dto que es la que está excluyendo los atributos nulos.

Realmente no te afecta a la hora de mapear la respuesta de la API, en Angular, por ejemplo, si tu clase / interfaz tiene un atributo que no tenga la respuesta de la API, te lo deja a null.