Construyendo un proxy API simple

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Esta página se aplica a Apigee y Apigee híbrido .

Ver la documentación de Apigee Edge .

Apigee permite exponer rápidamente servicios backend como API. Para ello, se crea un proxy de API que proporciona una fachada para el servicio backend que se desea exponer. Solo se necesita proporcionar la dirección de red del servicio backend, junto con información que Apigee utiliza para crear el proxy de API que se expone a los desarrolladores.

El proxy de API desvincula la implementación de tu servicio backend de la API que consumen los desarrolladores. Esto los protege de futuros cambios en tus servicios backend. A medida que actualizas los servicios backend, los desarrolladores, al estar protegidos de dichos cambios, pueden seguir llamando a la API sin interrupciones.

Este tema proporciona información sobre los distintos tipos de proxies y su configuración. Para obtener instrucciones paso a paso sobre cómo crear proxies, consulte los siguientes temas:

• Tutorial: Crea tu primer proxy API
• Creación de un proxy API

Creación de un proxy API mediante la interfaz de usuario

La forma más sencilla de crear un proxy API es utilizar el asistente Crear proxy .

Para acceder al asistente Crear proxy mediante la interfaz de usuario de Apigee, realice los siguientes pasos:

1. Inicie sesión en la interfaz de usuario de Apigee .
2. En la barra de navegación, seleccione Desarrollar > Proxies de API .
3. Haga clic en Crear nuevo .
   

El asistente Crear proxy se muestra y lo guía a través de los pasos para generar y agregar funciones mínimas a un proxy API.

La primera página del asistente le permite crear un proxy API a partir de las siguientes fuentes:

Las siguientes secciones analizan los detalles de cada tipo de proxy.

Creación de un proxy inverso para un servicio HTTP

Apigee genera servidores proxy inversos basados ​​en la siguiente información:

• URL del servicio backend.
• Ruta URI que identifica de forma única la API que el proxy de API expondrá a las aplicaciones del consumidor.

La URL del servicio backend suele representar una aplicación habilitada para servicios propiedad de su organización. También puede apuntar a una API pública. La API o el servicio pueden estar bajo su control (por ejemplo, una aplicación interna de RR. HH. o una aplicación Rails en la nube) o ser una API o servicio de terceros (por ejemplo, Twitter o Instagram).

Los siguientes detalles de proxy están disponibles después de acceder al asistente Crear proxy y seleccionar un tipo de proxy :

Importar un proxy de API desde un paquete de proxy de API

Los proxies de API suelen definirse como una colección de archivos XML, junto con otros archivos de soporte. Al definirlos como un conjunto de archivos externos a Apigee, se pueden mantener en un sistema de control de versiones y luego importarlos a Apigee para pruebas e implementación.

Para importar servidores proxy de API desde un paquete de servidores proxy de API, realice los siguientes pasos:

1. Acceda al asistente Crear proxy como se describe en Crear un proxy de API mediante la interfaz de usuario anteriormente en esta sección.
2. Haga clic en Cargar paquete de proxy .

3. En la página Cargar paquete de proxy del asistente de proxy, ingrese la siguiente información:

   Campo	Descripción
   Paquete ZIP	Archivo ZIP con la configuración del proxy de la API. Arrastre y suelte o haga clic para acceder al archivo.
   Nombre	Nombre mostrado para tu API. El valor predeterminado es el nombre del archivo ZIP sin la extensión.

4. Haga clic en Siguiente .

5. En la página Resumen , seleccione los entornos de implementación, si lo desea, y haga clic en Crear e implementar

   Se muestra un acuse de recibo confirmando que su nuevo proxy API se creó correctamente.

6. Haga clic en Editar proxy para mostrar la página de detalles del proxy API.

Creación de servidores proxy de API de gRPC

En este momento, los servidores proxy de API gRPC de Apigee:

• Admite solicitudes gRPC unarias.
• No se pueden utilizar políticas que afecten la carga útil.
• Se puede usar en productos API no asociados con proxies GraphQL o REST. Las cuotas específicas del producto API y otras configuraciones de operación se aplican a todos los proxies del producto.
• No son compatibles con Apigee híbrido.
• Utilice dos variables de flujo específicas de gRPC: request.grpc.rpc.name y request.grpc.service.name .
• Se puede monitorear con estas variables de Apigee Analytics específicas de gRPC: x_apigee_grpc_rpc_name , x_apigee_grpc_service_name y x_apigee_grpc_status .
• Devolver códigos de estado de gRPC .

También debe configurar su balanceador de carga para que sea compatible con gRPC. Consulte "Usar gRPC con sus aplicaciones" y "Usar comandos de la CLI de gcloud para crear enrutamiento para gRPC" .

Para crear un proxy de API gRPC, primero defina un servidor de destino gRPC (consulte Creación de servidores de destino ) y luego especifique ese servidor de destino al crear el nuevo proxy.

Uso de comandos CLI de gcloud para crear enrutamiento para gRPC

Esta sección muestra comandos de ejemplo para crear enrutamiento para proxies gRPC mediante la CLI de gcloud . Las instrucciones incluyen la configuración de balanceadores de carga, un servidor de destino y una MIG.

Esta sección no constituye una guía completa para la creación del enrutamiento. Estos ejemplos podrían no ser adecuados para todos los casos de uso. Además, estas instrucciones presuponen familiaridad con el enrutamiento externo (MIG) y la configuración de gRPC del balanceador de carga en la nube .

Establecer variables de entorno

Estas variables de entorno se utilizan en los comandos de las subsecciones.

PROJECT_ID=YOUR_PROJECT_ID
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=default
VPC_SUBNET=default
REGION=REGION_NAME
APIGEE_ENDPOINT=ENDPOINT
CERTIFICATE_NAME=CERTIFICATE_NAME
DOMAIN_HOSTNAME=DOMAIN_HOSTNAME

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 50 \
--target-cpu-utilization 0.75 --cool-down-period 90

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

gcloud compute addresses create lb-ipv4-vip-1 \
--project $PROJECT_ID \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global

  gcloud compute addresses describe lb-ipv4-vip-1 \
--project $PROJECT_ID --format="get(address)" --global

  gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \
--project $PROJECT_ID --address lb-ipv4-vip-1 --global \
--target-https-proxy apigee-envoy-https-proxy --ports 443

gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

# Create backend service for http2
    gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

gcloud compute url-maps list -project $PROJECT_ID

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2
weight: 100

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

Añadiendo seguridad

En la página Políticas comunes del asistente para crear proxy , seleccione el tipo de autorización de seguridad que desea agregar. La siguiente tabla resume las opciones disponibles:

Añadiendo soporte para CORS

El intercambio de recursos entre orígenes (CORS) es un mecanismo estándar que permite a un navegador web realizar solicitudes directas a otro dominio. El estándar CORS define un conjunto de encabezados HTTP que los navegadores y servidores web utilizan para implementar la comunicación entre dominios.

Puede agregar soporte para CORS realizando una de las siguientes acciones:

• Agregar la política CORS al PreFlow de solicitud de ProxyEndpoint
• Seleccionar Agregar encabezados CORS en la página Políticas comunes del asistente Crear proxy

Para obtener información más detallada sobre la compatibilidad con CORS, incluida la incorporación de compatibilidad previa al vuelo de CORS a un proxy, consulte Cómo incorporar compatibilidad con CORS a un proxy de API .

Agregar cuotas

Las cuotas protegen su servicio backend del tráfico elevado bajo Cuota . Consulte Cuotas . (No disponible si se selecciona la autorización de paso).

Uso de especificaciones OpenAPI para generar proxies

En esta sección se analiza la opción Usar OpenAPI, que está disponible para generar a partir de una especificación OpenAPI los siguientes tipos de servidores proxy de API: inversos o sin destino.

¿Qué es una especificación OpenAPI?

La Iniciativa Open API (OAI) se centra en la creación, el desarrollo y la promoción de un formato de descripción de API independiente del proveedor, basado en la Especificación Swagger. Para más información, consulte la Iniciativa OpenAPI .

Una especificación OpenAPI utiliza un formato estándar para describir una API RESTful. Escrita en formato JSON o YAML, es legible por máquinas, pero también fácil de leer y comprender para humanos. La especificación describe elementos de la API como su ruta base, rutas y verbos, encabezados, parámetros de consulta, operaciones, tipos de contenido, descripciones de respuestas, etc. Además, una especificación OpenAPI se utiliza comúnmente para generar documentación de la API.

El siguiente fragmento de una especificación de OpenAPI describe el servicio de destino simulado de Apigee: http://mocktarget.apigee.net . Para más información, consulte la especificación de OpenAPI para el ejemplo helloworld .

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

Mediante el asistente para crear proxy , puede importar una especificación de OpenAPI y usarla para generar un proxy de API. Una vez generado, puede usar la interfaz de usuario de Apigee para seguir desarrollándolo, añadiendo políticas, implementando código personalizado, etc., como cualquier proxy de Apigee.

Creación de un proxy API a partir de una especificación OpenAPI

Crea tus proxies de API a partir de una especificación OpenAPI. Con solo unos clics, tendrás un proxy de API con rutas, parámetros, flujos condicionales y endpoints de destino generados automáticamente. Después, puedes añadir funciones como seguridad OAuth, limitación de velocidad y almacenamiento en caché.

En el asistente para crear proxy , haga clic en "Usar especificación OpenAPI" y siga las instrucciones para crear un proxy inverso o sin destino a partir de una especificación OpenAPI. Para obtener más información, consulte "Crear un proxy de API a partir de una especificación OpenAPI" .

Creación de una nueva revisión de un proxy API

Cree una nueva revisión de un proxy API, como se describe a continuación.

Para crear una nueva revisión de un proxy API, realice los siguientes pasos:

1. Inicie sesión en la interfaz de usuario de Apigee .
2. En la barra de navegación, seleccione Desarrollar > Proxies de API .
3. Haga clic en el proxy API de la lista que desea copiar.

4. Haga clic en la pestaña Desarrollar .

5. Seleccione el botón Guardar y seleccione Guardar como nueva revisión .

Realizar una copia de seguridad de un proxy API

Puede crear una copia de seguridad de un proxy de API existente como un conjunto de archivos XML en un paquete de proxy de API. Una vez exportado a un paquete, puede importar el proxy de API a un nuevo proxy, como se describe en "Importar un proxy de API desde un paquete de proxy de API" en esta misma sección. Para obtener más información, consulte "Descargar proxies de API" .

Creación de un proxy API mediante la API

Para crear un proxy de API utilizando la API, consulte Creación de un proxy de API .

Acerca de los proxies sin objetivo

Los proxies sin destino en Apigee son útiles cuando se desea procesar solicitudes dentro de Apigee sin reenviarlas a un servicio backend. Es importante comprender cuándo es adecuado este enfoque.

Casos de uso comunes

• Interacción con datos gestionados por Apigee : Un proxy sin destino es útil cuando solo se necesita interactuar con datos gestionados por Apigee, como los almacenados en un mapa clave-valor (KVM) o la caché de Apigee . Por ejemplo, se puede usar un proxy sin destino para recuperar datos, como datos de sesión de usuario o datos de configuración, del KVM. En este caso, no es necesario llamar a un servicio de backend. Basta con una política KeyValueMapOperations en el flujo del proxy. Por ejemplo, se podría querer que el emisor solicite el vaciado de la caché. Esto se puede hacer invocando la política InvalidateCache , sin necesidad de conectarse a un destino.
• Uso de API simuladas : Puedes crear API simuladas para simular el comportamiento de la API antes de completar la implementación del backend, lo que permite que el desarrollo del frontend avance de forma independiente. Para obtener más información sobre la creación de API simuladas, consulta OpenAPI Mock API Proxy en Github.
• Gestión de tokens : Apigee puede emitir tokens OAuthV2, y eso generalmente se hace a través de un proxy sin destino.
• Prueba del comportamiento de la política : un proxy sin objetivo puede ser útil cuando desea probar las políticas de Apigee para comprobar su comportamiento.