Análisis de contrato · Bloque 1
EX-B1-06
Seguro, idempotente o ninguna de las dos
Tras varios timeouts, un cliente reintenta todas sus peticiones por igual. Debes revisar si la semántica declarada por cada operación permite hacerlo.
Cómo abordarla
Decide sin fingir que el análisis es implementación
Responde primero con la evidencia disponible. Consulta la teoría solo para comprobar el supuesto que no puedas justificar.
Abrir análisis técnico
1. Abre la evidencia
- Tabla de operacionesMatriz vacía para semántica, repetición, riesgo y política de reintento.
2. Analiza y decide
- Clasifica cada operación como segura o no segura.
- Clasifica cada operación como idempotente o no idempotente según la descripción.
- Predice el estado observable después de repetir dos veces una petición idéntica.
- Propón una decisión de reintento tras timeout: automático, condicionado o manual.
- Identifica el dato adicional que podría cambiar la clasificación de la operación de webhooks.
3. Entrega una decisión revisable
- Tabla completa de las siete operaciones.
- Justificación breve de los dos casos que consideres más propensos a confusión.
Registra tu decisión antes de contrastarla con el material.
Pregunta central
Si la primera respuesta se pierde y el cliente repite exactamente la petición, ¿qué operaciones son seguras, idempotentes o arriesgadas de reintentar?
Información que necesitas
1. GET /reservations/{reservation_id} — consulta una reserva y registra métricas de lectura.
2. HEAD /rooms/{room_id}/availability — devuelve únicamente cabeceras.
3. POST /charges — crea un cargo nuevo por cada petición aceptada.
4. PUT /users/{user_id}/preferences — sustituye todas las preferencias por el body.
5. DELETE /subscriptions/{subscription_id} — elimina la suscripción si existe.
6. PATCH /orders/{order_id} — incrementa `delivery_attempts` en 1.
7. POST /webhooks/deliveries — registra la entrega; `delivery_key` evita duplicados.Para ordenar tu razonamiento
- Clasifica las siete operaciones en segura/no segura e idempotente/no idempotente.
- Compara el estado tras una ejecución con el estado tras dos peticiones iguales.
- Elige el caso más engañoso y explica la confusión habitual.
Selecciona tus respuestas
Cada elección se guarda automáticamente en este navegador.
Sin respuesta guardada.
Pistas opcionales
Pista única · Compara el estado final
- Para idempotencia, compara el estado relevante tras una ejecución con el estado tras varias peticiones idénticas.
Profundización opcional
Clasificar operaciones HTTP por seguridad e idempotencia y predecir el riesgo de repetirlas cuando la primera respuesta se pierde.
Contexto adicional
- Clasifica la operación por su comportamiento prometido, no solo por el nombre del método.
- Diferencia que una operación sea idempotente de que siempre tenga éxito o carezca de efectos secundarios.
Cómo revisar tu respuesta
- Seguro e idempotente se evalúan como propiedades distintas.
- Registrar métricas no invalida automáticamente la intención segura de una lectura.
- La idempotencia no se confunde con obtener la misma representación o el mismo código en cada intento.
- Los reintentos consideran el efecto de una primera ejecución cuya respuesta se perdió.
Evidencia, revisión y reinicio
- Clasificaciones guardadas localmente en el navegador.
- Justificación del efecto de repetición si se completa la tabla opcional.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Borrar las selecciones desde la tarjeta y volver a descargar la tabla de operaciones original.