Proceso distribuido de aprobación de peticiones

[bcuestav]

Hola,

Comento por aquí un caso que nos está pasando por si se tratara de una deficiencia en la api de taple.

Supongamos dos miembros (A y B) de una red de taple, con una gobernanza que indica que las modificaciones de los sujetos creados por A, deben ser aprobadas por B.

Cuando A envia una solicitud de modificación de sujeto, se crea una petición tal y como la siguiente:

El sujeto no se modifica hasta que se reciba la aprobación de B, para lo cual, en este caso, B puede enviar una petición a PUT /api/approvals/JPxYp38HHvwuW1wNtsitR56p80hcmfKoHy-thmeLzc1k usando el request_id de la petición anterior.

La pregunta es: ¿Cómo sabe B cual es el request_id que debe usar?

Por un lado, el request_id lo conoce A de la respuesta de la primera operación. Por otro lado, la api para consultar todas las peticiones pendientes de aprobación (GET /api/approvals) curiosamente no devuelve los request_id, como se puede ver en la siguiente captura.

Muchas gracias de antemano por las aclaraciones que podáis hacernos al respecto.

Un saludo.

[FlorentinPG]

Entiendo la confusión ya que tal y como dices el campo RequestID no aparece en el resultado de la petición GET. Esto es así porque no existe el campo RequestID como tal sino que en la práctica en un sinónimo de "Event Content Hash", el campo que aparece en el contenido de la firma.

Así que el nodo B podría extraer el identificador de dicho campo para luego poder emitir el voto correspondiente.

Saludos.

[bcuestav]

Estupendo. Muchas gracias por la aclaración!!!