Echolot
Tutoriales

Encadenar solicitudes

Inicia sesión una vez, guarda el token y envíalo desde todas las solicitudes que lo necesitan, con valores dinámicos y una Idempotency-Key.

La mayoría de las API quieren un token que se obtiene al iniciar sesión. En este tutorial guardas el token de la tienda de demostración en una variable a partir de la respuesta de inicio de sesión, lo envías desde toda una carpeta mediante su autenticación, lees un valor de una respuesta en la siguiente solicitud y haces un pedido con seguridad usando una Idempotency-Key.

  • Tiempo: 15 minutos.
  • Necesitas: el espacio de trabajo de Tu primer espacio de trabajo, con el entorno Demo elegido y la solicitud Auth › Sign in. Alpenglow ya tiene todo esto montado; ábrelo para comparar.
  • Aprendes: capturas de respuesta, autenticación heredada, valores dinámicos y valores de respuesta.

1. Guarda el token de la respuesta de inicio de sesión

  1. Abre Auth › Sign in y envíala (⌘R).
  2. En la pestaña Cuerpo de la respuesta, cambia la vista a Árbol JSON.
  3. Deja el puntero sobre la fila access_token. Después del valor aparecen unos botones pequeños. Elige el que tiene la ayuda Guardar en una variable….
  4. En la ventana emergente Guardar en una variable:
    • Cambia el nombre a token.
    • En el ámbito, elige Entorno “Demo”: cada servidor tiene sus propios tokens.
    • Asegúrate de que Secreto · guardado en el llavero, nunca en archivos está marcado. Echolot lo marca solo para nombres como token.
    • Deja marcado Actualizar en cada envío · se guarda con esta solicitud.
  5. Elige Guardar.

Abre la pestaña Variables de la solicitud. Bajo De la respuesta hay una fila: token, de JSON, ruta $.access_token, guardado en Demo, secreto. A partir de ahora, cada envío correcto de Sign in escribe el nuevo token en {{token}}. Una respuesta de 400 o más, o una sin el valor, deja la variable como estaba. Detalles en capturas de respuesta.

La ventana emergente Guardar en una variable sobre el valor access_token en el Árbol JSON, con su ámbito y la casilla de secreto marcada

2. Envía el token desde toda una carpeta

En lugar de definir la autenticación Bearer en cada solicitud, defínela una vez en una carpeta.

  1. Crea una carpeta Orders (⇧⌘N).
  2. Haz clic derecho en Orders y elige Ajustes de la carpeta….
  3. En la pestaña Autenticación, pon Tipo en Token Bearer y Token en {{token}}. Pulsa OK.
  4. Haz clic derecho en Orders, elige Nueva solicitud y llámala List orders. Pon su URL en {{baseURL}}/orders.
  5. Abre su pestaña Autenticación. Tipo es Heredar, y la fila Usa dice que toma el Token Bearer de la carpeta.
  6. Envíala.

Obtienes los tres pedidos de Heidi: ord_7Hk2Lw (enviado), ord_8Jm4Qx (pagado) y ord_5Fd9Ra (entregado). Cada solicitud nueva de Orders envía el token del mismo modo. Las solicitudes empiezan en Heredar, que toma la autenticación de la carpeta más cercana y después la del espacio de trabajo. Consulta autenticación para los demás tipos.

Si más adelante recibes 401 Unauthorized, el token ha caducado: dura una hora. Envía Sign in otra vez y el token se actualiza.

3. Lee un valor de otra respuesta

La siguiente solicitud lee el id del primer pedido de la respuesta a List orders, así que nunca lo copias a mano.

  1. En Orders, crea una solicitud Get order.
  2. En su campo de URL, escribe {{baseURL}}/orders/ y después {{$response. La lista muestra los valores dinámicos del grupo Respuestas. Elige Respuesta filtrada con JSONPath.
  3. En el formulario que se abre, pon Solicitud en la solicitud List orders (orders/list-orders) y JSONPath en $.items[0].id. Deja Enviarla antes en Cuando aún no tiene respuesta. Pulsa OK.

Ahora la URL contiene un token que representa {{$responseJSONPath('orders/list-orders', '$.items[0].id')}}. Deja el puntero encima para ver el valor que tiene ahora: ord_7Hk2Lw. Envía Get order y obtienes ese pedido con sus líneas y su envío. Si List orders nunca se hubiera enviado, Echolot la enviaría primero.

4. Haz un pedido con valores dinámicos

Los valores dinámicos se generan de nuevo en cada envío. Usa dos de ellos en un pedido nuevo.

  1. En Orders, crea una solicitud Create order con el método POST y la URL {{baseURL}}/orders.

  2. En la pestaña Cuerpo, elige JSON y escribe el cuerpo. Usa la lista de {{ para insertar Marca de tiempo ISO 8601:

    {
      "lines": [
        { "sku": "TNT-MH-2P", "quantity": 1 },
        { "sku": "PCK-TIT-30", "quantity": 2 }
      ],
      "note": "Placed from Echolot at {{$isoTimestamp}}"
    }
  3. En la pestaña Cabeceras, añade una cabecera Idempotency-Key. Como valor, escribe {{ y elige UUID ({{$uuid}}).

  4. Envíala.

La respuesta es 201 Created con una cabecera Location como /v1/orders/ord_…, y la tienda te devuelve tu Idempotency-Key. La nota lleva la hora del envío. La demo no guarda nada, así que el pedido nuevo no se puede consultar después. Todos los valores dinámicos están en la referencia.

Create order respondida con 201 Created, con las cabeceras de respuesta Location e Idempotency-Key

5. Mira qué hace la Idempotency-Key

Una Idempotency-Key le dice al servidor que los envíos con la misma clave son el mismo pedido, así que enviar de nuevo nunca lo hace dos veces.

  1. Envía Create order otra vez. El id de Location cambia: {{$uuid}} creó una clave nueva.
  2. En la pestaña Cabeceras, sustituye {{$uuid}} por un valor fijo como tutorial-order-1.
  3. Envíala dos veces. Las dos respuestas traen el mismo id de pedido.

Las API reales usan la clave para descartar una solicitud repetida que sí llegó la primera vez. Echolot también la usa: cuando una conexión mantenida abierta se cierra antes de cualquier respuesta, vuelve a enviar una solicitud por una conexión nueva solo si enviarla dos veces es inocuo. Eso se cumple para GET, PUT, DELETE y los demás métodos seguros o idempotentes, y para cualquier solicitud con una cabecera Idempotency-Key. Un POST sin ella falla en vez de reintentarse, así que un pedido nunca se hace dos veces a tus espaldas. Vuelve a poner {{$uuid}} cuando termines.

Dos cosas más que comprueba la tienda:

  • Cambia una cantidad a 0 y envía: 422 Unprocessable Content lista lo que está mal en cada línea.
  • Orders with OAuth 2 en Alpenglow obtiene su token por credenciales de cliente. Ese token puede leer pedidos pero no hacerlos: POST /v1/orders con él responde 403 Forbidden.

Siguientes pasos

En esta página