¿Cuál es la mejor práctica de diseño?API REST: incluya detalles de objetos relacionados o simplemente ID
Si tengo el objeto A y contiene algunos objetos relacionados, por ejemplo, tengo un objeto de automóvil y sus varios tipos.
¿Debo bajo petición api.example.org/cars/1
responden simplemente con identificaciones a esos recursos (por lo que si alguien necesita detalles acerca de ellos se requiere otra llamada API en api.example.org/type/1
)
{
"id": 1,
"name": "Some Car",
"types": [
1,
2
]
}
o proporcionar detalles sobre esos recursos, así
{
"id": 1,
"name": "Some Car",
"types": [
{
"id": 1,
"name": "Some Type",
"something": "Blah"
},
{
"id": 2,
"name": "Some Type",
"something": "Blah"
}
]
}
O proporcione un parámetro opcional como "displayAll" y luego una matriz con los nombres de los parámetros que deben recuperarse en una llamada API (en este caso tipos).
pregunta sin embargo: si no separa la url raíz y el ID, si la URL raíz cambia (v1 a v2, o lo que sea), entonces todos los enlaces anteriores se romperán, ¿no? ¿No hay ningún caso de uso para querer centralizar la raíz para dirigir al cliente? –
Mantenga un número muy pequeño de URI "Cool" estables que nunca deberían cambiar, y haga que cada URI subyacente a ellos sea accesible a través de la navegación hipervinculada. Las aplicaciones cliente deben estar codificadas para comenzar en el URI de punto de entrada Cool y encontrar los recursos que necesitan a través de la navegación de esas relaciones. Esa es una parte central de HATEOAS: la mayoría de la estructura de su URI debe ser flexible y variable a medida que cambian sus necesidades, pero sin afectar las aplicaciones existentes. –