Proxies

Cuando una petición, entra en una API, se recibe un message, que modeliza la request recibida (body, headers, etc).

Mediante la directiva Http, puedes hacer que el message recibido (la request), sea reenviada tal cual a otro Host, quedando modificado el message una vez recibida la response, y convirtiendo la API en un proxy.

    post /user:
        CheckKey:
            directive: CheckKey
            expected: $.map.main.viewKey
            current: $.message.queryParam.api-key
        ModifyMessage:
            directive: ModifyMessage
            path: /ms/user
        Connection:
            directive: Http
            host: $.map.urls.usermshost
            timeout: 10
            connectTimeout: 3

En el ejemplo anterior, se ha declarado un endpoint para crear usuarios, que valida un apiKey recibido en una cabecera, hace una modificación del path del message (de /user a /ms/user) y mediante la directiva Http redirige la petición recibida (con el path alterado) a un ms externo, cuya url se ha declarado en un map. La response recibida será reenviada tal cual al cliente de la API, aunque podríamos añadir otras directivas después de Http para modificar el message recibido.

    all /requests:
        Http:
            directive: Http
            host: $.map.main.urlExternal

En el ejemplo anterior, se usa el endpoint especial all /requests, para interceptar todas las peticiones que lleguen al API, y redirigirlas a un servicio externo, de esta forma convertimos nuestro API en un proxy. Podríamos añadir directivas antes o después de Http para dotar al proxy de cualquier funcionalidad que deseemos.

La directiva Http, tiene las siguientes opciones:

• host: obligatoria, indica el dominio al que queremos hacer la petición.
• timeout: opcional, por defecto es 10. Una vez establecida la conexión, indica los segundos que esperará Hefesto antes de cortar la petición.
• connectTimeout: opcional, por defecto es 10. Indica los segundos máximos para establecer la conexión.

Pull

La directiva Pull, permite hacer conexiones http de lectura, de forma que el objeto recibido, se valida y almacena en memory automáticamente.

    get /user:
        CheckKey:
            directive: CheckKey
            expected: $.map.main.viewKey
            current: $.message.queryParam.api-key
        ReadUser:
            directive: Pull
            host: https://mymicroservice.com
            path: /ms/user
            target: user

En el ejemplo anterior, se está haciendo una validación de un apiKey, y luego se hace una conexión GET contra https://mymicroservice.com/ms/user con la directiva Pull, el json recibido, es validado y almacenado en memory con la key "user". La validación se realiza usando json-schema, por lo que en Maps, deberá existir un fichero user.json con el json-schema del objeto que se espera recibir.

La directiva Pull, tiene las siguientes opciones:

• host: obligatoria, indica el dominio al que queremos hacer la petición.
• path: obligatoria, indica el path al que queremos hacer la petición.
• body: opcional, un array o un string con el body que queremos enviar (si usamos un array, será transformado automáticamente a JSON). Si no usamos body, Pull usa el verbo GET, si usamos body, usa el verbo POST.
• headers: opcional, un array con las cabeceras que queremos enviar.
• queryParams: opcional, un array con los queryParams que queremos enviar.
• cache: opcional, los segundos que queremos que quede cacheada esa petición en redis. Por defecto las peticiones no se cachean.
• verifyStatus: opcional, un booleano, que por defecto es true, y que indica si queremos revisar que la response ha sido un 2xx, para que en caso de que no lo sea se eleve una excepción.
• verify: opcional, un booleano, que por defecto es true, y que indica si queremos revisar que la response ha sido un 2xx, y revisar también que el objeto recibido cumple el json-schema recibido en el target.
• target: opcional, aunque si no usamos verify, o verify es true, se convierte en obligatorio, indica la key en memory donde se va a almacenar el aray con el objeto recibido, y el Map, del mismo nombre que la key, con la definición del json-schema.
• serverSideError: opcional, es un booleano para indicar el código de error (status) que se elevará en la excepción, en caso de que la validación del json-schema no resulte satisfactorio. Por defecto se usa un 502, pero si dejamos el parámetro a false, se usa un 400.
• timeout: opcional, por defecto es 10. Una vez establecida la conexión, indica los segundos que esperará Hefesto antes de cortar la petición.
• connectTimeout: opcional, por defecto es 10. Indica los segundos máximos para establecer la conexión.

Push

La directiva Push es similar a Pull, pero orientada a hacer escrituras en lugar de lecturas, por lo que no hace la validación del objeto que se recibe en la response.

La directiva Push, tiene las siguientes opciones:

• host: obligatoria, indica el dominio al que queremos hacer la petición.
• verb: opcional, indica el verbo que queremos utilizar, por defecto es POST, a no ser que usemos el parámetro id, en ese caso por defecto sería PUT.
• path: opcional, indica el path al que queremos hacer la petición. Si no existe se usa el del message.
• id: opcional, si existe, se concatena al final del path, añadiendo un /. Es decir el path terminaría siendo: /path/id
• body: opcional, un array o un string con el body que queremos enviar (si usamos un array, será transformado automáticamente a JSON).
• headers: opcional, un array con las cabeceras que queremos enviar.
• queryParams: opcional, un array con los queryParams que queremos enviar.
• verify: opcional, un booleano, que por defecto es true, y que indica si queremos revisar que la response ha sido un 2xx, para que en caso de que no lo sea se eleve una excepción.
• timeout: opcional, por defecto es 10. Una vez establecida la conexión, indica los segundos que esperará Hefesto antes de cortar la petición.
• connectTimeout: opcional, por defecto es 10. Indica los segundos máximos para establecer la conexión.

Conexiones locales

Si te quieres conectar a otra API desplegada en el mismo virtual-host, usando cualquiera de las directivas anteriores, Pull, Push o Http, sólo tienes que usar como host, la clave en memory hefesto-localhost. Da igual que la API a la que llamas sea pública o privada, las llamadas locales siempre están permitidas.

Ir a la home