Como identificar los recursos en una API REST ?

B

Buscando y leyendo en diferentes sitios no me queda claro cómo debería identificar los recursos de mi api.

Ya me olía de que usar la clave primaria de la entidad no es buena idea y efectivamente no lo es tal como dice este tio: http://toddfredrich.com/ids-in-rest-api.html

Él propone usar UUID como identificador. Es lo que soléis usar también? Mi siguiente pregunta sería, como?

class Foo {
	
String id;  //id generado por el backend y que no comparto con el cliente
UUID uid = UUID.randomUUID();  //id que sí comparto con el cliente
}

Sería así?

B

Lo único que te dice que no utilices el campo "id" porque en algunos lenguajes como MongoDB genera unas strings random y que utilices en su lugar otro campo que sea independiente del id autogenerado de cada sistema gestor de base de datos. Sería un campo UNIQUE que recomiendo utilizar UUID, pero claro, con cuidado de que no haya colisiones. Es un buen método.

1
dabolbi

#1 Si haces eso te generará un id por cada respuesta que de tu servicio. ¿Es lo que necesitas?
Yo entiendo que lo que quieres es que si yo hago una petición a tu API de, por ejemplo, un objeto X, siempre que pregunte por ese objeto me devuelva el mismo id. En ese caso, pues quizá un campo public_id, que no sea PK en la tabla, pero sí sea unique, y que cuando te traigas el objeto, si no existe pues lo generas con el randomUUID() y ya lo guardas.

EDIT: no había entendido el código bien, si el UUID sólo lo generas una vez por cada objeto pues es ok

1
B

Así pues recomendáis que la entidad tenga 2 id's? No es un tanto redundante? Ya que cuando vaya a hacer un get, lo haré por uuid y al final el id original no lo uso para nada :psyduck:

Mi backend es mongodb. Y he leído por ahi que ObjectId (la primary key por defecto que genera mongo) es más eficiente que UUID.

dabolbi

Digamos que tendrás 2 ids, si, uno interno para tu SGBBDD y otro "universal" para la API REST. Es lo que dice el tío del link que has puesto: tienes el id PK para que lo gestione MySql (por ejemplo, que lo genera de una forma concreta), y si cambias a MongoDB (que lo genera de otra), cambiará esa PK, pero tu API REST seguirá funcionando porque usa el otro id que es universal, e independiente del SGBBDD.

S

Uno seria el id publico, el que ven los consumidores de la api. El otro es el id interno de tu db, que afecta al funcionamiento de tu sistema y puedes querer actualizar en el futuro.

B

Sí es verdad. Sobre mi anterior comentario, supongo que el precio a pagar es algo menos de eficiencia si quiero un sistema seguro y coherente.

B

Veo que lo que hace la gente cuando quiere pasar el uuid como parametro por url, lo codifican en Base64.

Entonces pregunto, en vez de hacer codificaciones y descodificaciones al vuelo, no sería lo mismo que persistir el uuid ya codificado ? Además del plus de que la id ocupará menos bytes en la bbdd.

as base64: b8tRS7h4TJ2Vt43Dp85v2A
as uuid  : 6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8

edit: vale, no he dicho nada xD. De poder puedo, pero perdería las propiedades del uuid, como el timestamp por ejemplo que sí me interesa tener a mano.

Wasd

En 2017 veo absurdo preocuparse de los bytes que te puedas ahorrar. Incluso hablando de millones de registros no debería suponer ningún problema.

En cuanto al tema del UUID, es buena idea tener la ID que te auto-genera la BD y a parte el UUID, siendo por supuesto ambos UNIQUE, siendo la ID tu PK, y teniendo también el UUID como otro index en la tabla/collection.

Entre otras ventajas, te permite mantener la ID siempre dentro de tu propio ecosistema, y más tratándose de una API, a tus clientes les ofrecerás el UUID, pero las PK's son tuyas y solo tuyas.

1 respuesta
eXtreM3

#9 eso de 2017 es relativo, depende de la aplicación. Hace poco en mi empresa hemos montado un sistema de comunicación vía GPRS donde Movistar es la que cobra por hacer los envíos y recepciones y créeme, cada byte cuenta.

Usuarios habituales