Preguntas de API REST para entrevistas: métodos, errores, paginación e idempotencia
Quick Overview
API REST de pedidos con 24 comprobaciones HTTP/SQLite ejecutadas. Compara un 201 repetido y un 409 por contenido cambiado; verifica Location y Problem Details. Un cursor (10, 2) evita repetir el id 2 tras insertar (9, 0), sin prometer un snapshot. Las solicitudes se atienden secuencialmente; la base está en memoria, sin autenticación ni cursor firmado. Incluye código y una transcripción original para defender contratos.
El cliente envía un pedido, pierde la respuesta y vuelve a enviarlo. Recibe un 201, pero eso no demuestra que solo exista un pedido. Mientras tanto, otra solicitud inserta un registro al principio de la lista y la segunda página repite una fila. Para responder preguntas de API REST en una entrevista, empieza por esos fallos del ejemplo feliz.
Para preparar una respuesta, conecta método, estado, error y reintento con un contrato concreto. Aquí usarás una API original de pedidos y una transcripción HTTP ejecutada en localhost. El ejercicio descargable permite repetir los casos; las preguntas para Backend Engineer de PracHub ayudan a cambiar de escenario sin depender de este mismo código.
Hechos oficiales: los estándares y las guías enlazadas definen mecanismos y convenciones. Informes de candidatos: las preguntas de práctica son registros de PracHub, no un pronóstico de tu entrevista. Decisiones propias: rutas, límites y respuestas del laboratorio forman un contrato original. Las 24 comprobaciones ejecutan HTTP y SQLite, con solicitudes secuenciales. No demuestran autenticación, varios servidores, persistencia tras reinicio ni seguridad del cursor.
Explica el efecto antes de elegir el método
Antes de responder «GET o POST», pregunta qué intenta hacer el consumidor. Consultar una lista y crear un pedido tienen efectos diferentes. Nuestro GET /orders lee; POST /orders acepta una representación y crea un recurso. El laboratorio devuelve su ubicación, que puede consultarse después con GET.
Hecho oficial: RFC 9110 define seguridad e idempotencia de métodos. Un método seguro no solicita modificar el estado; un efecto idempotente se conserva al repetir la misma operación. Eso no exige respuestas idénticas en cada repetición. POST no es idempotente por definición: nuestro contrato añade una clave y un registro del resultado.
PUT suele encajar cuando se conoce la URI y se envía el estado de reemplazo. Una actualización parcial necesita un contrato adicional; decir PATCH no explica qué significa omitir un campo. En este ejemplo no implementamos ninguna actualización: PATCH devuelve 405 y un encabezado Allow con los métodos del ejercicio.
No conviertas el método en una garantía de base de datos. Un endpoint llamado PUT puede estar mal implementado y producir efectos duplicados. En la entrevista, distingue lo que promete el protocolo de la evidencia necesaria para sostener esa promesa. El código ejecutado y el estado final deben acompañar la explicación.
Lee una transcripción con el estado que cambia
El caso parte de tres pedidos: los identificadores 1 y 2 tienen la clave de orden 10; el 3 tiene 11. Son enteros sintéticos para reproducir empates, no timestamps de producción. El cliente solicita dos elementos y recibe los pedidos 1 y 2 junto con un cursor.
Después se inserta el pedido 0, con clave 9. La segunda página por posición repite el 2: la nueva fila ha desplazado el límite. La segunda página por cursor continúa después de (10, 2) y devuelve solo el 3. La diferencia puede observarse en la misma base SQLite, sin asumir una carga real.
| Solicitud original | Resultado ejecutado | Explicación que debes defender |
|---|---|---|
| GET de dos pedidos iniciales | 200, identificadores 1 y 2 | Orden total por clave e identificador |
| Siguiente página tras insertar 0 | Cursor devuelve 3 | La posición de 2 ya no determina el corte |
| POST con clave k1 y cantidad 2 | 201 y Location | El recurso se creó y tiene una ruta de consulta |
| Mismo k1, JSON con campos reordenados | Mismo recurso y 201 | El contrato compara contenido normalizado |
| Mismo k1, cantidad 3 | 409 | La clave ya identifica otra solicitud |
| PATCH no implementado | 405 y Allow | El cliente conoce los métodos admitidos |
El archivo de resultados conserva cada solicitud, estado, respuesta y encabezados seleccionados. También comprueba que la URI de Location devuelve el recurso creado. Así evitas presentar una ubicación decorativa que no pueda leerse, o contar solo respuestas sin contrastarlas con el almacenamiento.
Da al error una decisión para el cliente
El laboratorio distingue JSON malformado, tipo de contenido no admitido, campos inválidos y reutilización conflictiva de la clave. No son fallos equivalentes: repetir exactamente una cantidad booleana no la convierte en válida. Reenviar una clave con otro contenido tampoco corrige el conflicto.
Nuestra política devuelve 400 para JSON o consulta malformados, 415 para contenido incompatible, 422 para una cantidad inválida y 409 para la clave ya vinculada a otros datos. Son decisiones del contrato apoyadas en la semántica de HTTP; no una tabla que toda empresa deba copiar sin revisar sus operaciones.
Hecho oficial: RFC 9457 define Problem Details para describir problemas HTTP. El ejemplo usa application/problem+json, type, title y status, más un campo propio code. El consumidor puede basarse en ese código estable sin analizar una frase traducida.
{"type":"about:blank","title":"key_payload_conflict",
"status":409,"code":"key_payload_conflict"}
Un contrato más completo puede añadir detalles de campo e identificadores de diagnóstico, sin filtrar secretos. La política de reintento necesita documentarse aparte. «Es un error 4xx» no indica por sí solo qué debe corregir el consumidor ni qué respuesta puede recuperar al consultar una solicitud conocida.
Haz que la clave represente la misma operación
El cliente utiliza Idempotency-Key: k1 con {"sku":"A","qty":2}. El servidor normaliza el objeto JSON para que cambiar el orden de los campos no cambie la huella. Guarda esa huella y el resultado junto con la creación del pedido dentro de una transacción SQLite.
Al repetir k1 con los mismos datos, devuelve el mismo identificador. Si cambia la cantidad a 3, rechaza la solicitud. Las comprobaciones verifican tanto la representación recuperada como la única fila de la tabla de intentos. No basta con devolver un mensaje «ya procesado»: el cliente necesita recuperar el mismo pedido para continuar.
La normalización también es una decisión. Aquí no tratamos 2 y 2.0 como cantidades equivalentes porque el contrato acepta un entero, y excluimos los booleanos aunque Python permita tratarlos como enteros en otros contextos. Tampoco eliminamos espacios internos ni aceptamos campos adicionales de manera silenciosa.
En producción, define el alcance de la clave por consumidor y operación, su retención y el comportamiento de una solicitud en curso. Un mismo texto enviado por dos clientes no debería unir sus operaciones por accidente. Nuestro servidor local no autentica clientes y mantiene una única tabla sin ese alcance: esa limitación debe aparecer antes de atribuirle aislamiento entre usuarios.
Delimita lo que prueba la transacción
El modelo utiliza una clave primaria en la tabla de intentos y una transacción para el pedido y su resultado. Sin embargo, el servidor HTTP atiende una solicitud cada vez. Los casos secuenciales no muestran qué ocurriría si dos procesos intentaran reclamar k1 simultáneamente.
Para una versión concurrente, prueba la adquisición atómica de la clave, el resultado mientras la primera solicitud trabaja y la recuperación después de un aborto. Evita una secuencia desprotegida de «si no existe, crear». Explica cómo la restricción, la transacción y la gestión del error se relacionan en el motor elegido.
También separa los efectos externos. Si crear el pedido llama a un proveedor de pagos, las dos escrituras no pasan a compartir una transacción local por añadir una clave. Necesitas conservar la identidad del intento, conciliar estados inciertos y definir una recuperación. El ejercicio no llama a servicios externos ni implementa una bandeja de salida.
La base del laboratorio está en memoria. Al finalizar el programa se pierde, incluido el registro de los intentos. «Un reintento secuencial recupera el pedido durante esta ejecución» es una observación válida. «Nunca habrá dos pedidos después de cualquier reinicio» exigiría otra implementación y otras pruebas.
Construye un cursor con un orden completo
El empate entre los pedidos 1 y 2 hace insuficiente continuar solo por la clave 10. El cursor conserva (created, id) y la consulta ordena por ambos valores en sentido ascendente. La condición de la siguiente página usa la misma comparación; cambiar el orden sin cambiar el cursor rompería el contrato.
El servidor lee un elemento extra para determinar si hay continuación. Devuelve como cursor la última pareja realmente incluida, no la fila extra. Al llegar al final, next_cursor es nulo. Ese comportamiento debe funcionar también si una página contiene menos elementos que el máximo permitido.
Guía oficial: Google AIP-158 explica el papel de los tokens de página y la continuidad de los parámetros. Para nuestro caso, cambiar filtros, orden o tamaño necesita una política explícita. El ejercicio solo ofrece tamaño y cursor; no implementa filtros de usuario, caducidad ni versionado de token.
La representación Base64 del laboratorio es visible y modificable: no es una firma. Para una API expuesta, decide cómo proteger la integridad del token y volver a aplicar la autorización en cada consulta. Un token opaco tampoco sustituye esa autorización. La práctica actual verifica estructura y tipos; no verifica integridad criptográfica.
No confundas continuidad con una fotografía de los datos
La consulta por cursor evita repetir el límite cuando se inserta una fila anterior, pero no garantiza ver todas las filas que existieron durante el recorrido. Una inserción posterior al límite puede aparecer en otra página; una anterior puede quedar fuera. Una eliminación puede reducir lo que el cliente recibe.
Define si el consumidor necesita un recorrido vivo o una fotografía coherente. Un historial que se actualiza y una exportación contable pueden tener necesidades diferentes. La segunda podría requerir un identificador de snapshot o un corte temporal compatible con sus consultas, además de un cursor.
Nuestra prueba añade una fila anterior y demuestra una diferencia concreta frente a OFFSET. No prueba actualizaciones del campo de orden, borrados, snapshots ni rendimiento con millones de filas. Esas pruebas tienen que corresponder a la promesa elegida; no se deducen de que el cursor tenga dos valores.
En la entrevista, expresa el compromiso: «Continuamos por una pareja estable; aceptamos que la colección cambie. Si el cliente necesita una exportación reproducible, añadiría una frontera de lectura y probaría su consistencia». La alternativa debe responder a esa necesidad, no a una preferencia automática por cursores.
Revisa el límite antes de declarar el contrato completo
El laboratorio limita las páginas a entre uno y tres elementos y el cuerpo a 1.024 bytes. Esos números mantienen pequeño el ejercicio; no son recomendaciones de capacidad. Comprueba consultas repetidas, cursor malformado, cantidad booleana, contenido incorrecto, recurso ausente y método no admitido.
Guía oficial: las recomendaciones de diseño de API de Microsoft sirven para revisar la relación entre recursos y consumidores. Nuestro siguiente paso sería acordar autorización, versiones y límites operativos según el uso real. No presentamos el script de biblioteca estándar como un servidor listo para Internet.
Ejecuta python3 api_contract.py y revisa las 24 comprobaciones y la transcripción. Después cambia un contrato, por ejemplo la equivalencia de cantidades, y anticipa qué prueba debe variar. Conserva las diferencias entre el efecto observado, la propuesta y lo que todavía no has ejecutado.
Estas cinco preguntas verificadas ayudan a transferir la explicación a otras API. Los títulos originales identifican registros de práctica; ninguna pregunta promete el contenido de una evaluación próxima.
| Pregunta PracHub verificada | Qué debes justificar |
|---|---|
| Implement a robust REST API method | Relacionar entrada inválida, estado y respuesta del consumidor. |
| Design a REST API Abstraction Layer | Mantener un contrato público sin filtrar cada detalle interno. |
| Design load balancing, caching, and idempotent APIs | Revisar qué garantía sobrevive a varios procesos y reintentos. |
| Implement idempotent request handling with idempotency keys | Distinguir misma clave, contenido cambiado y ejecución pendiente. |
| Evolve Cursor Pagination Without Breaking Clients | Explicar orden, token y compatibilidad cuando cambia la colección. |
Continúa con las preguntas para Backend Engineer. Elige una solicitud, escribe su respuesta y provoca una repetición o una mutación de datos. Tu respuesta estará mejor sustentada cuando puedas explicar por qué el estado final coincide con lo que prometiste al cliente.
Comments (0)