Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Elegir una opción de Endpoints

Para que Cloud Endpoints administre tu API, tienes tres opciones según dónde esté alojada la API y el tipo de protocolo de comunicaciones que esta use:

En esta página, se describen las opciones de Endpoints a fin de ayudarte a decidir cuál es la más adecuada para ti.

Elige una opción de procesamiento

Endpoints admite diferentes opciones de procesamiento de Google Cloud que pueden alojar el código de backend de la API. Endpoints trabaja con el proxy de servicio extensible (ESP) o el proxy de servicio extensible V2 (ESPv2) a fin de proporcionar administración de API. En la siguiente tabla, se resumen las opciones de procesamiento admitidas:

ESP para OpenAPI ESP para gRPC ESPv2 para OpenAPI ESPv2 para gRPC Endpoints Frameworks
Generación 1
de entornos estándar de App Engine
Entornos de ejecución de Java 8 y Python 2.7
Generación 2
de entornos estándar de App Engine
Entorno flexible
de App Engine
Cloud Functions
Cloud Run
Cloud Run for Anthos
Compute Engine
GKE
Kubernetes
Otras opciones que no son de Google Cloud

Para ver una comparación de las características que proporcionan App Engine, GKE y Compute Engine, consulta Elegir una opción de procesamiento. Si estás pensando en usar App Engine, debes elegir el entorno estándar o flexible. Para obtener una comparación de los dos entornos, consulta Elige un entorno de App Engine.

Acerca de las limitaciones de las opciones de procesamiento

Endpoints para OpenAPI y Endpoints para gRPC pueden usar el ESP o el ESPv2 como un proxy. En plataformas con servidores, el ESP o el ESPv2 se implementa como un contenedor frente a la aplicación o como un archivo adicional con tu aplicación. En las plataformas sin servidores, como Cloud Run, Cloud Functions y App Engine, el ESPv2 se implementa como un servicio de Cloud Run como un proxy remoto para administrar las aplicaciones de la plataforma sin servidores.

Después de implementar el código de backend de la API, el ESP o el ESPv2 intercepta todas las solicitudes y realiza las verificaciones necesarias (como la autenticación) antes de reenviar la solicitud al backend de la API. Cuando el backend responde, el ESP informa y recopila la telemetría con Service Infrastructure.

Puedes ver las métricas de tu API y los vínculos a los registros y seguimientos de Google Cloud's operations suite en la página Servicios de Endpoints en Cloud Console.

Limitaciones del entorno de la generación 1 de entornos estándar de App Engine.

Endpoints para la generación 1 de entornos estándar de App Engine usó históricamente Endpoints Frameworks, que solo admite los entornos de ejecución Java 8 y Python 2.7.

Debido a que el entorno estándar de App Engine no admitía implementaciones de varios contenedores cuando Endpoints Frameworks estaba en desarrollo, Endpoints Frameworks no usa el ESP. En cambio, Endpoints Frameworks incluye una puerta de enlace de API integrada que proporciona funciones de administración de API que son comparables a las funciones que el ESP proporciona a Endpoints para OpenAPI y a Endpoints para gRPC.

Las API de gRPC no son compatibles con App Engine o Cloud Functions

gRPC es un marco de trabajo para llamada de procedimiento remoto (RPC) que puede ejecutarse en cualquier entorno. Con gRPC, una aplicación cliente puede llamar de forma directa a métodos en una aplicación de servidor en otra máquina como si fuera un objeto local. Una característica principal de gRPC es la transmisión bidireccional con el transporte basado en HTTP/2.

App Engine y Cloud Functions no son compatibles con HTTP/2.

La transmisión de gRPC no es compatible con Cloud Run

En la actualidad, Cloud Run no admite la transmisión de gRPC en solicitudes entrantes. Debido a esta limitación, ESPv2 en Cloud Run para gRPC solo admite API de gRPC unarias.

Lenguajes de programación compatibles

  • OpenAPI Specification es una especificación independiente del lenguaje. Puedes implementar tu API en cualquier lenguaje de programación.
  • gRPC proporciona el compilador de búfer de protocolo, protoc, para muchos de los principales lenguajes de programación: C++, C#, Objective-C (para iOS), Dart, Go, Java (incluido asistencia para Android), Node.js, Python y Ruby. Consulta las Preguntas frecuentes de gRPC para obtener la lista más actualizada.
  • Endpoints Frameworks solo admite Java 8 y Python 2.7.

Describir tu API

Las opciones de Endpoints proporcionan diferentes maneras de describir tu API.

Endpoints para OpenAPI

OpenAPI Initiative es un esfuerzo de toda la industria para estandarizar la descripción de las API de REST. Endpoints admite las API que se describen con el uso de la versión 2.0 de OpenAPI Specification (antes llamada Swagger Specification ). Describes la superficie de tu API en un archivo JSON o YAML (al que se hace referencia como un documento de OpenAPI). Puedes implementar tu API con el uso de un marco de trabajo REST que se encuentre disponible de forma pública, como Django o Jersey. Si no estás familiarizado con OpenAPI Specification, consulta Descripción general de OpenAPI.

Para obtener más información, consulta Endpoints para OpenAPI .

Endpoints para gRPC

Con gRPC, puedes definir la estructura de los datos que deseas serializar en un archivo proto: se trata de un archivo de texto común con una extensión .proto. También puedes definir la superficie de tu API en los archivos proto, con los parámetros de método de RPC y los tipos de datos que se muestran especificados como mensajes de búfer de protocolo. Si no está familiarizado con gRPC, consulta ¿Qué es gRPC? en la documentación de gRPC.

Para obtener más información, consulta Endpoints para gRPC.

Endpoints Frameworks

Endpoints Frameworks es un marco de trabajo web para los entornos de ejecución estándar de Python 2.7 y Java 8 de App Engine. Puedes agregar metadatos (con el uso de anotaciones en Java o decoradores en Python) a tu código fuente. Los metadatos describen la superficie de las API de REST para tu aplicación.

Para obtener más información, consulta Endpoints Frameworks.

¿Qué sigue?