Enunciado y alcance
Diseña un servicio de almacenamiento de datos externo interoperable para múltiples aplicaciones. Los clientes deben descubrir el almacenamiento, solicitar acceso de lectura/escritura, crear recursos y suscribirse a cambios. Explica el modelado de recursos, la semántica HTTP, la autenticación, la concurrencia, las notificaciones y la reversión.
El W3C Linked Web Storage Protocol 1.0 es actualmente un Borrador de Trabajo (Working Draft). Su objetivo es dar a las aplicaciones un acceso seguro, con permisos e interoperable a datos almacenados externamente. La especificación utiliza relaciones Link para descubrir el almacenamiento y los recursos padre, gestiona metadatos mediante linksets y requiere atomicidad entre las actualizaciones de metadatos y las operaciones sobre recursos. La pregunta evalúa los límites del protocolo y el manejo de fallos sin asumir que el borrador es un estándar estable.
Qué evalúa el entrevistador
El entrevistador busca separaciones claras entre recursos, permisos, identidad, metadatos y notificaciones, además del manejo correcto de reintentos de POST, PATCH concurrente, respuestas 405/415, almacenamiento en caché y revocación. Una respuesta sólida reconoce la incertidumbre del Borrador de Trabajo y elige entre suites de identidad de OpenID Connect, SAML y autofirmadas en función de las necesidades del despliegue.
Preguntas de clarificación antes de responder
- ¿Quién opera al propietario de los datos, la aplicación y el servicio de almacenamiento, y dónde están los límites de confianza?
- ¿Qué operaciones se requieren: lectura, creación, actualización, eliminación, uso compartido o suscripciones de solo lectura?
- ¿Se otorgan los permisos por usuario, agente, ruta de recurso, acción o ventana de tiempo?
- ¿Se requieren acceso entre regiones, uso sin conexión, auditoría, revocación y notificación eventual?
- ¿Pueden los clientes manejar el descubrimiento de Link, ETags, respuestas 405/415 y deduplicación de reintentos?
Estructura de respuesta en 30 segundos
“Modelaría el almacenamiento, los contenedores, los recursos de datos, los linksets, la identidad y las concesiones por separado. Un cliente descubre el almacenamiento y su padre a través de relaciones Link, se autentica con una suite declarada y envía una solicitud que contiene acción, sujeto, destino y restricciones. La creación utiliza POST, pero una clave de idempotencia o deduplicación evita duplicados por reintentos; el PATCH de metadatos requiere una condición de concurrencia y se confirma atómicamente con la operación del recurso. El servicio utiliza ETags, encabezados de capacidades y errores estructurados para conflictos, mientras que una cola con reintentos entrega notificaciones eventualmente consistentes. Cada despliegue canary mantiene revocación, versiones anteriores de permisos y reversión de auditoría.”
Respuesta detallada paso a paso
1. Establecer el modelo de recursos y descubrimiento
Separa almacenamiento, contenedor, recurso de datos y linkset. Las respuestas GET o HEAD exponen la raíz de almacenamiento, el padre, el tipo y el linkset a través de relaciones Link; los clientes no deben tratar la disposición de las URL como el contrato del protocolo. Una descripción del almacenamiento debe anunciar las capacidades del servidor y los tipos de medios para que los clientes negocien antes de enviar PUT o un PATCH específico.
2. Modelar permisos como concesiones auditables
Una concesión debe incluir asignatario, acción, destino, restricciones, emisor, validez y estado de revocación. El servicio de almacenamiento verifica la identidad del emisor y la versión de la concesión, y luego aplica privilegios mínimos para leer, crear, actualizar o eliminar. OpenID Connect, SAML o la identidad autofirmada pueden demostrar la identidad, pero la autenticación y la autorización del recurso permanecen separadas; un inicio de sesión exitoso no implica acceso a todos los recursos.
3. Definir la semántica de creación, actualización y concurrencia
La especificación crea un recurso con POST y un URI final asignado por el servidor, devolviendo 201 y Location. POST no es idempotente, por lo que los reintentos necesitan un identificador de solicitud único o un registro de deduplicación. PATCH de linkset es la actualización de metadatos principal; usa ETag, If-Match o una verificación de versión equivalente para evitar actualizaciones perdidas. Devuelve 405 para un método no admitido y 415 para un tipo de medios no admitido.
POST /alice/notes/ HTTP/2
Idempotency-Key: 7b3c...
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Content-Type: text/plain
meeting notes4. Mantener consistentes el recurso y los metadatos
La creación, la pertenencia a contenedores y los metadatos requeridos del servidor deben confirmarse atómicamente; un fallo no debe dejar un recurso visible sin una relación con el padre o sin linkset. Entre fragmentos (shards), usa un registro de transacciones o outbox para asentar el estado. Las API de lectura pueden exponer estados pendientes, confirmados o fallidos en lugar de inferir el éxito de la confirmación a partir del orden de notificación.
5. Diseñar notificaciones y negociación de capacidades
Escribe los eventos de cambio en un outbox con reintentos y luego entrégalos a los inboxes de los suscriptores. Incluye almacenamiento, recurso, acción y versión; los consumidores deduplican por ID de evento y usan GET para verificar el estado actual. Recupera notificaciones perdidas con retransmisión o conciliación periódica, y mantén el procesamiento de duplicados de forma idempotente. La negociación con Prefer, Link y tipos de medios permite a los clientes adoptar capacidades de forma incremental en lugar de asumir que cada servidor admite un solo PATCH o modelo de suscripción.
6. Manejar autenticación, revocación y reversión
Incluye rotación de claves, audiencia del token, desviación de reloj (clock skew) y rutas de revocación en el diseño de autenticación. Escribe los cambios de permisos en registros de auditoría versionados y haz efectiva la revocación tras las comprobaciones de autorización y la invalidación de caché. Realiza pruebas canary primero en inquilinos de bajo riesgo, observando 401/403, 405/415, tasa de conflictos, creación duplicada, latencia de notificación y completitud de auditoría; detén el proceso ante una escalada de privilegios o datos huérfanos y restaura la directiva de autorización anterior.
Respuesta de ejemplo de alta calidad
Separaría almacenamiento, contenedores, recursos de datos, linksets, identidad y concesiones. Los clientes descubren la raíz del almacenamiento, el padre, el tipo y el linkset mediante relaciones Link con GET/HEAD, y luego negocian capacidades antes de las escrituras. Una concesión contiene sujeto, acción, destino, restricciones, validez y revocación; OpenID Connect, SAML o identidad autofirmada prueban la identidad pero no otorgan acceso a los recursos. POST devuelve 201 y Location; debido a que no es idempotente, los clientes usan un ID de solicitud único o deduplicación. Linkset PATCH usa ETag/If-Match para evitar actualizaciones concurrentes perdidas, y los métodos o tipos de medios no admitidos devuelven 405/415. La creación, la pertenencia y los metadatos del servidor se confirman atómicamente. Los eventos del outbox van a inboxes con reintento, y los consumidores deduplican por ID de evento y concilian con GET. El despliegue canary observa 401/403, conflictos, duplicados, latencia de notificación y completitud de auditoría; una escalada de privilegios, recursos huérfanos o una reversión fallida detienen el despliegue. Dado que el protocolo es un Borrador de Trabajo, el protocolo final y la matriz de pruebas deben estar versionados.
Errores comunes
- Tratar las rutas URL como el contrato completo del protocolo → el descubrimiento y la negociación de capacidades se rompen → depende de las relaciones Link, tipos de medios y encabezados de capacidades.
- Reintentar POST incondicionalmente → se pueden crear recursos duplicados → utiliza claves de idempotencia, registros de deduplicación y lecturas de estado final.
- Verificar el inicio de sesión pero no la autorización → la identidad no implica acceso al destino → evalúa sujeto, acción, destino y restricciones.
- Confirmar metadatos por separado del recurso → aparecen recursos huérfanos o linksets incorrectos → utiliza una transacción atómica o un outbox recuperable.
- Asumir que todos los servidores admiten PUT/PATCH → los clientes se vuelven frágiles → descubre capacidades y maneja 405/415.
Preguntas de seguimiento y respuestas
¿Por qué los reintentos de POST no pueden depender únicamente de TCP o HTTP?
La conexión puede fallar después de que el servidor confirme la operación, dejando al cliente sin conocer el resultado. Un ID de solicitud único y una consulta de estado asocian el reintento con la confirmación original.
¿Cómo se evita el desfase de revocación por las cachés de permisos?
Usa concesiones versionadas con TTL cortos, invalida activamente las cachés afectadas tras la escritura de auditoría y vuelve a verificar la versión de autorización para escrituras críticas.
¿Cómo recuperarse de notificaciones perdidas?
Persiste eventos en un outbox, reintenta la entrega, retén los cursores de los consumidores, concilia por versión de recurso y retransmite el registro de eventos cuando sea necesario.
¿Por qué las actualizaciones de linksets deben ser atómicas?
Si el recurso se crea correctamente pero los metadatos de pertenencia o tipo no, el descubrimiento, la autorización y las cachés observan un estado inconsistente. La confirmación atómica evita que un recurso creado a medias sea visible.
¿Cómo controlar la inversión durante un Borrador de Trabajo?
Usa un adaptador aislado y una matriz de pruebas versionada, prueba solo con tráfico de bajo riesgo, mantén el protocolo anterior y la ruta de migración, y amplía el alcance después de que la especificación y el informe de implementación se estabilicen.