Ehhhh

Contents
Documentación de Azure API Management

Información general
Acerca de API Management
Disponibilidad de características de API Management
Guías de inicio rápido
Creación de una instancia: Portal
Creación de una instancia: PowerShell
Tutoriales
1 - Importación de la primera API
2 - Creación y publicación de un producto
3 - Simulación de respuestas de API
4 - Protección de una API
5 - Supervisión de API publicadas
6 - Depuración de API
7 - Incorporación de revisiones
8 - Incorporación de varias versiones
9 - Personalización del portal para desarrolladores
Ejemplos
Directivas
Azure PowerShell
Conceptos
Terminología
Directivas
Índice de referencia de directiva
Suscripciones
Administrar mediante automatización
Control de errores
Restricciones a la importación de API
Atributos comunes de seguridad de Azure
Guías de procedimientos
Definición de API
Adición manual de una API
Importación de una especificación OpenAPI
Importación de una API de SOAP
Importación de API de SOAP y conversión en REST
Importación de una aplicación de API
Importación de una instancia de Function App
Importación de una aplicación lógica
Importación de una aplicación de Service Fabric
Edición de una API
Aprovisionamiento y escalado
Métrica de capacidad
Actualización y escalado
Configuración de escalado automático
Configuración de un dominio personalizado
Memoria caché
Agregar almacenamiento en caché para mejorar el rendimiento
Uso de una caché externa
Protección de las API
Creación de suscripciones
Protección de API mediante la autenticación de certificado de cliente
Proteger el back-end
Protección de una API con Azure AD
Conexión a una red virtual
Conexión a una red virtual interna
Integración de Application Gateway en una red virtual interna
Autenticación mutua de certificados
Administración de certificados de entidad de certificación
Administración de protocolos y cifrados
Personalizar la experiencia para desarrolladores
Acceso al nuevo portal para desarrolladores y personalización de este
Modificación del diseño y contenido de una página
Personalización de páginas del sistema mediante plantillas
Autenticación con Azure AD
Autenticación con Azure AD B2C
Autenticación delegada
Plantillas y notificaciones de correo electrónico
Habilitar OAuth en la consola
Definición de directivas
Establecimiento o edición de directivas
Expresiones de directiva
Almacenamiento en caché personalizado
Supervisión avanzada
Limitación de solicitudes avanzada
Usar servicios externos
Administrar secretos mediante propiedades
Directivas de restricción de acceso
Directivas avanzadas
Directivas de autenticación
Directivas de almacenamiento en caché
Directivas entre dominios
Directivas de transformación
Referencia de plantilla
Plantillas
API existentes
Productos
APLICACIONES
Issues
Perfil de usuario
Páginas
Recursos de plantilla
Referencia de modelo de datos
Controles de página
Administración en producción
Administrar grupos
Implementación en varias regiones de Azure
Registro de eventos en Azure Event Hubs
Registro de solicitudes con Azure Application Insights
Configuración de DR mediante copia de seguridad y restauración
Administrar cuentas de usuario
Configurar mediante Git
Uso del control de acceso basado en rol
Uso de identidades administradas para recursos de Azure
Integración con Service Fabric
Tutorial
Referencia
Azure PowerShell
REST
REST (original)
Plantilla de Resource Manager
Recursos
Preguntas más frecuentes
Precios
Disponibilidad regional
Roadmap
Solicitudes de características
Vídeos
Foro de MSDN
Stack Overflow
Guía de diseño de una API
Guía de implementación de API
Solución de problemas al actualizar nombres de host
Acerca de API Management
25/05/2018 • 14 minutes to read • Edit Online
API Management (APIM ) es una manera de crear puertas de enlace de API coherentes y modernas para servicios
de back-end existentes.
API Management ayuda a las organizaciones a publicar API para desarrolladores externos, asociados e internos
para liberar el potencial de sus datos y servicios. Todas y cada una de las empresas pretenden extender sus
operaciones como una plataforma digital creando nuevos canales, buscando nuevos clientes y estrechando la
relación con los existentes. API Management proporciona las competencias esenciales para garantizar un
programa de API de éxito mediante compromisos con desarrolladores, información detallada empresarial,
análisis, seguridad y protección. Puede usar Azure API Management para tomar cualquier back-end e iniciar un
programa de API completo basado en él.
Este artículo proporciona información general de escenarios comunes que implican a APIM. También ofrece una
breve descripción de los componentes principales del sistema de APIM. El artículo, a continuación, proporciona
una descripción más detallada de cada uno.
Para usar API Management, los administradores crean API. Cada API consta de una o varias operaciones y se
puede agregar a uno o varios productos. Para usar una API, los desarrolladores se suscriben a un producto que
contiene esa API y después pueden llamar a la operación de la API cumpliendo cualquier directiva de uso que
pueda estar en vigor. Entre los escenarios habituales se incluyen los siguientes:
Protección de la infraestructura móvil mediante el control de acceso con claves de API, la prevención de
ataques de denegación de servicio mediante la limitación o el uso de directivas de seguridad avanzadas como
la validación de tokens JWT.
Habilitación de los ecosistemas de asociados de fabricantes de software independiente mediante la
oferta de una incorporación rápida de asociados a través del portal para desarrolladores y la creación de una
fachada de API para desacoplar desde implementaciones internas que no son adecuada para el consumo de
los asociados.
Ejecución de un programa de API interno mediante la oferta de una ubicación centralizada para la
organización a fin de comunicar acerca de la disponibilidad y los últimos cambios en las API y el control de
acceso en función de cuentas de organizaciones, todo ello basado en un canal seguro entre la puerta de enlace
de la API y el back-end.
El sistema consta de los siguientes componentes:
La puerta de enlace de la API es el extremo que:
Acepta llamadas de API y las enruta a los back-end.
Comprueba las claves de API, los tokens JWT, los certificados y otras credenciales.
Aplica cuotas de uso y límites de frecuencia.
Transforma la API sobre la marcha sin modificaciones de código.
Almacena en caché las respuestas de back-end donde se instalaron.
Registra los metadatos de llamada para fines de análisis.
Azure Portal es la interfaz administrativa donde se configura el programa de API. Utilícelo para:
definir o importar el esquema de API
empaquetar las API en productos
establecer directivas, como cuotas o transformaciones, en las API
obtener información del análisis
administrar usuarios
El portal para desarrolladores actúa como la presencia web principal para desarrolladores, donde estos
pueden:
leer documentación de la API
probar una API a través de la consola interactiva
crear una cuenta y suscribirse para obtener claves de API
obtener acceso a análisis sobre su propio uso
Para más información, consulte las notas del producto en formato PDF Cloud-based API Management:
Harnessing the Power of APIs (API Management basado en la nube: aprovechamiento de la versatilidad de las
API. Estas notas del producto introductorias sobre la administración de API por CITO Research cubren:
Desafíos y requisitos comunes de API
Desacoplamiento de API y presentación de fachadas
Puesta en marcha de los desarrolladores rápidamente
Protección de acceso
Análisis y métricas
Obtención de control e información con una plataforma de API Management
Uso de soluciones de nube frente a locales
Azure API Management
API y operaciones
Las API son el fundamento de una instancia del servicio Administración de API. Cada API representa un conjunto
de operaciones disponibles para los desarrolladores. Cada API contiene una referencia a un servicio back-end que
implementa la API y sus operaciones se asignan a las operaciones implementadas por dicho servicio. Las
operaciones de API Management son altamente configurables, con control sobre asignación de direcciones URL,
parámetros de consulta y ruta de acceso, contenidos de solicitudes y respuestas y almacenamiento en caché de
respuestas de operaciones. En la API o en el ámbito de operación individual, también se pueden implementar
directivas de límite de tasa, cuotas y restricción de direcciones IP.
Para más información, consulte Creación de API e Incorporación de operaciones a una API.
Productos
Los productos son la forma de presentar las API a los desarrolladores. Los productos en Administración de API
tienen una o varias API y se configuran con un título, una descripción y términos de uso. Los productos pueden
ser de tipo Abierto o Protegido. Para poder usar los productos protegidos es necesario suscribirse antes a ellos,
mientras que los productos abiertos pueden usarse sin suscripción. Cuando un producto está preparado para que
lo usen los desarrolladores, se puede publicar. Una vez publicado, los desarrolladores pueden verlo (y, en el caso
de los productos protegidos, suscribirse a él). La aprobación de la suscripción se configura en el ámbito de
producto y puede requerir la aprobación del administrador o aprobarse automáticamente.
Los grupos se usan para administrar la visibilidad de productos a los desarrolladores. Los productos conceden
visibilidad a los grupos y los desarrolladores pueden ver los productos visibles a los grupos a los que pertenecen y
suscribirse a ellos.
Grupos
Los grupos se usan para administrar la visibilidad de productos a los desarrolladores. API Management tiene los
siguientes grupos invariables del sistema:
Administradores : los administradores de la suscripción de Azure son miembros de este grupo. Los
administradores controlan las instancias del servicio Administración de API y crean las API, las operaciones y
los productos que usan los desarrolladores.
Desarrolladores : los usuarios del portal para desarrolladores autenticados se incluyen en este grupo. Los
desarrolladores son los clientes que compilan aplicaciones con sus API. Los desarrolladores, después de que se
les concede acceso al portal para desarrolladores, crean aplicaciones que llaman a las operaciones de una API.
Invitados : a este grupo pertenecen los usuarios del portal para desarrolladores no autenticados como, por
ejemplo, clientes potenciales que visitan el portal para desarrolladores de una instancia de API Management.
Se les concede determinado acceso de solo lectura, como por ejemplo la posibilidad de ver API pero no
llamarlas.
Además de estos grupos del sistema, los administradores pueden crear grupos personalizados o aprovechar los
grupos externos en inquilinos de Azure Active Directory asociados. Los grupos personalizados y externos pueden
usarse junto con grupos del sistema en la concesión a los desarrolladores de visibilidad y acceso a productos de la
API. Por ejemplo, podría crear un grupo personalizado para los desarrolladores afiliados a una organización
asociada específica y permitirles el acceso a las API a partir de un producto que contenga solo las API relevantes.
Un usuario puede ser miembro de más de un grupo.
Para más información, consulte Creación y uso de grupos.
Desarrolladores
Los desarrolladores representan las cuentas de usuario de una instancia del servicio API Management. Los
desarrolladores pueden ser creados por administradores o invitados por estos y también pueden suscribirse
desde el Portal para desarrolladores. Cada desarrollador es miembro de uno o varios grupos y se puede suscribir
a los productos que conceden visibilidad a esos grupos.
Cuando los desarrolladores se suscriben a un producto, se les concede la clave principal y secundaria para dicho
producto. Esta clave se usa cuando se realizan llamadas en las API del producto.
Para más información, consulte Creación o invitación de desarrolladores y Asociación de grupos a
desarrolladores.
Directivas
Las directivas son una eficaz funcionalidad de API Management que permite a Azure Portal cambiar el
comportamiento de la API a través de la configuración. Las directivas son una colección de declaraciones que se
ejecutan secuencialmente en la solicitud o respuesta de una API. Entre las declaraciones más usadas se
encuentran la conversión de formato de XML a JSON y la limitación de tasa de llamadas para restringir el número
de llamadas entrantes de un desarrollador, pero también hay muchas otras directivas disponibles.
Las expresiones de directiva pueden utilizarse como valores de atributos o valores de texto en cualquiera de las
directivas de API Management, a menos que la directiva especifique lo contrario. Algunas directivas como Flujo
de control y Establecer variable se basan en expresiones de directiva. Para más información, consulte Directivas
avanzadas y Expresiones de directiva.
Para obtener una lista completa de las directivas de API Management, consulte Referencia de la directiva. Para
más información acerca del uso y la configuración de directivas, consulte Directivas de API Management. Para ver
un tutorial sobre la creación de un producto con directivas de cuota y límite de tasas, consulte Creación y
definición de configuraciones de productos avanzadas.
Portal para desarrolladores

El portal para desarrolladores es el lugar en el que los desarrolladores pueden aprender acerca de sus API, ver
operaciones y llamarlas y suscribirse a productos. Los clientes potenciales pueden visitar el portal para
desarrolladores, ver API y operaciones y suscribirse. La dirección URL del portal para desarrolladores se
encuentra en Azure Portal para la instancia del servicio API Management.
Puede personalizar el aspecto y apariencia del portal para desarrolladores agregando contenido personalizado,
personalizando estilos e incorporando su toque diferenciador.
API Management y la economía de la API

Para más información acerca de API Management, vea la siguiente presentación de la conferencia Microsoft Ignite
2017.
Pasos siguientes
Complete la guía de inicio rápido siguiente y empiece a usar Azure API Management:
Creación de una instancia de Azure API Management
Comparación de características de los planes de tarifa
de Azure API Management
Cada plan de tarifa de API Management ofrece un conjunto diferente de características y capacidad por unidad. En
la tabla siguiente se resumen las características clave disponibles en cada uno de los planes. Algunas características
podrían funcionar de manera diferente o tener funcionalidades diferentes según el plan. En tales casos, se indican
las diferencias en los artículos de documentación que describen estas características individuales.
CARACTERÍSTICA CONSUMO DEVELOPER BÁSICA ESTÁNDAR PREMIUM
Integración de Sin Sí Sin Sí Sí

Azure AD1
Compatibilidad Sin Sí No No Sí
con redes
virtuales (VNet)
Implementación Sin No No No Sí
en varias
regiones
Múltiples Sin No No No Sí
nombres de
dominio
personalizados
Portal para Sin Sí Sí Sí Sí

desarrolladores2
Memoria caché Sin Sí Sí Sí Sí

integrada
Análisis integrado Sin Sí Sí Sí Sí
Configuración de Sí Sí Sí Sí Sí
SSL
Caché externa Sí Sí Sí Sí Sí
Autenticación de Sí Sí Sí Sí Sí
certificados de
clientes
Copia de Sin Sí Sí Sí Sí
seguridad y
restauración
Administración a Sin Sí Sí Sí Sí
través de Git
CARACTERÍSTICA CONSUMO DEVELOPER BÁSICA ESTÁNDAR PREMIUM
API de Sin Sí Sí Sí Sí
administración
directa
Métricas y Sin Sí Sí Sí Sí
registros de
Azure Monitor
IP estática Sin Sí Sí Sí Sí
1 Habilita el uso de Azure AD (y Azure AD B2C ) como proveedor de identidades para el inicio de sesión del usuario
en el portal para desarrolladores.
2 Incluye funciones relacionadas, por ejemplo, plantillas y notificaciones de usuarios, grupos, problemas,
aplicaciones y correo electrónico.

Creación de una nueva instancia del servicio
Azure API Management (APIM ) ayuda a las organizaciones a publicar API para desarrolladores
externos, asociados e internos a fin de desbloquear el potencial de sus datos y servicios. API
Management proporciona las competencias esenciales para garantizar un programa de API de éxito
mediante compromisos con desarrolladores, información detallada empresarial, análisis, seguridad y
protección. APIM le permite crear y administrar modernas puertas de enlace de API para los servicios
back-end existentes hospedados en cualquier lugar. Para más información, consulte el tema de
introducción.
Esta guía de inicio rápido describe los pasos que deben seguirse para crear una nueva instancia de API
Management mediante Azure Portal.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Inicio de sesión en Azure

Inicie sesión en Azure Portal en https://portal.azure.com.
Creación de un nuevo servicio

1. En Azure Portal, seleccione Crear un recurso > Enterprise Integration > API Management.
Si lo desea, también puede elegir nuevo, escribir API management en el cuadro de búsqueda y
presionar Intro. Haga clic en Create(Crear).
2. En la ventana servicio API Management, escriba los valores.
CONFIGURACIÓN VALOR SUGERIDO DESCRIPCIÓN
Nombre Un nombre único para el servicio Este nombre no se podrá

API Management modificar más adelante. El
nombre del servicio se usa para
generar un nombre de dominio
predeterminado con el formato
{nombre}.azure-api.net. Si desea
utilizar un nombre de dominio
personalizado, consulte Configure
a custom domain (Configuración
de un dominio personalizado).
El nombre del servicio se utiliza
para hacer referencia al servicio y
al recurso de Azure
correspondiente.
Suscripción Su suscripción La suscripción en que se creará

esta nueva instancia de servicio.
Seleccione una suscripción entre
las diferentes suscripciones de
Azure a las que tiene acceso.
Grupo de recursos apimResourceGroup Seleccione un nuevo recurso o

uno ya existente. Un grupo de
recursos es una colección de
recursos que comparten ciclos de
vida, permisos y directivas.
Obtenga más información aquí.
Ubicación Oeste de EE. UU. Seleccione la región geográfica

más próxima. En el cuadro de
lista desplegable, solo aparecerán
las regiones del servicio API
Management.
Nombre de la organización El nombre de su organización Este nombre se usa en varios

lugares, incluido el título del
portal para desarrolladores y el
remitente de correos electrónicos
de notificación.
Correo electrónico del [email protected] Especifique la dirección de correo

administrador electrónico a la que se enviarán
todas las notificaciones de API
Management.
Plan de tarifa Developer Especifique el nivel de

Desarrollador para evaluar el
servicio. Este nivel no puede
utilizarse en producción. Para
más información sobre el
escalado de los niveles de API
Management, consulte
Actualización y escalado.
3. Seleccione Create.
TIP
Normalmente, se tarda entre 20 y 30 minutos en crear el servicio API Management. Si selecciona Anclar
al panel, podrá encontrar el servicio que acaba de crear con más facilidad.
Vaya a la instancia de API Management.

1. Inicie sesión en el Azure Portal.
2. Seleccione Todos los servicios.
3. En el cuadro de búsqueda, escriba api management .
4. En los resultados de búsqueda, seleccione Servicios API Management.
5. Seleccione su instancia de servicio API Management.
TIP
Para agregar API Management a los favoritos en Azure Portal, seleccione la estrella.
El icono de API Management ( ) aparece ahora en el menú izquierdo del portal.
Limpieza de recursos
Cuando ya no los necesite, puede quitar el grupo de recursos y todos los recursos relacionados
siguiendo los pasos a continuación:
1. En Azure Portal, seleccione Todos los servicios.
2. Escriba resource groups en el cuadro de búsqueda y haga clic en el resultado.
3. Encuentre el grupo de recursos y haga clic en él.
4. Haga clic en Eliminar grupo de recursos.
5. Confirme la eliminación; para ello, escriba el nombre del grupo de recursos.

6. Hacer clic en Eliminar.
Pasos siguientes
Importación y publicación de la primera API
Creación de una nueva instancia del servicio Azure
API Management
Azure API Management (APIM ) ayuda a las organizaciones a publicar API para desarrolladores externos,
asociados e internos a fin de desbloquear el potencial de sus datos y servicios. API Management proporciona las
competencias esenciales para garantizar un programa de API de éxito mediante compromisos con desarrolladores,
información detallada empresarial, análisis, seguridad y protección. APIM le permite crear y administrar modernas
puertas de enlace de API para los servicios back-end existentes hospedados en cualquier lugar. Para obtener más
información, consulte el tema de introducción.
En este inicio rápido se describen los pasos que deben seguirse para crear una nueva instancia de API
Management mediante scripts de PowerShell. El inicio rápido muestra cómo utilizar el servicio Azure Cloud Shell
que puede ejecutar desde Azure Portal.
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Inicie sesión en Azure Portal en https://portal.azure.com.
Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Cloud Shell le permite usar bash o PowerShell para trabajar con servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:
OPCIÓN EJEMPLO O VÍNCULO
Seleccione Probarlo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Probar no se copia
automáticamente el código en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell con Ctrl+Mayús+V en Windows y Linux, o Cmd+Mayús+V en
macOS.
4. Presione ENTRAR para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, en este tutorial necesitará la versión 1.0 del módulo de Azure
PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para encontrar la versión. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.
Creación de un grupo de recursos

Cree un grupo de recursos de Azure con New -AzResourceGroup. Un grupo de recursos es un contenedor lógico
en el que se implementan y se administran los recursos de Azure.
New-AzResourceGroup -Name myResourceGroup -Location WestUS
Creación de un servicio de API Management

Se trata de una operación larga que puede tardar hasta 15 minutos.
New-AzApiManagement -ResourceGroupName "myResourceGroup" -Location "West US" -Name "apim-name" -Organization

"myOrganization" -AdminEmail "myEmail" -Sku "Developer"
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos y
todos los recursos relacionados.
Remove-AzResourceGroup -Name myResourceGroup
Pasos siguientes
En este tutorial se explica cómo importar una API de back-end de Especificación OpenAPI que reside en
https://conferenceapi.azurewebsites.net?format=json. Esta API de back-end la proporciona Microsoft y se
hospeda en Azure.
Una vez que la API de back-end se importa en Management API (APIM ), la API de APIM se convierte en una
fachada de la API de back-end. En el momento en que se importa la API de back-end, el origen de la API y la
API de APIM son idénticos. APIM permite personalizar la fachada según sus necesidades sin tocar la API de
back-end. Para obtener más información, consulte Transformación y protección de una API.
En este tutorial, aprenderá a:
Importación de la primera API
Prueba de la API en Azure Portal
Pruebe la API en el Portal para desarrolladores
Requisitos previos
Conocer la terminología de API Management de Azure.
Complete el siguiente inicio rápido: Creación de una instancia de Azure API Management.

TIP
Importación y publicación de una API de back-end

Esta sección explica cómo importar y publicar una API de back-end de Especificación OpenAPI.
1. Seleccione API en API MANAGEMENT.
2. Seleccione Especificación OpenAPI en la lista y haga clic en Completa en el elemento emergente.
Puede establecer los valores de API durante la creación o luego accediendo a la pestaña
Configuración. El asterisco rojo junto a un campo indica que el campo es obligatorio.
Utilice los valores de la tabla siguiente para crear su primera API.
CONFIGURACIÓN VALOR DESCRIPCIÓN
Especificación OpenAPI https://conferenceapi.azurewebsites. Hace referencia al servicio que

net?format=json implementa la API. API
Management envía las solicitudes a
esta dirección.
Nombre para mostrar API de conferencia de Si presiona la tecla Tab después de

demostración (API de conferencia escribir la dirección URL del servicio,
de demostración) APIM rellenará este campo en
función de lo que aparece en el
JSON.
El nombre se muestra en el Portal
para desarrolladores.
Nombre demo-conference-api Proporciona un nombre único para

la API.
Si presiona la tecla Tab después de
escribir la dirección URL del servicio,
APIM rellenará este campo en
JSON.
Descripción Proporcione una descripción Si presiona la tecla Tab después de

opcional de la API. escribir la dirección URL del servicio,
JSON.
Esquema URL HTTPS Determina los protocolos que se

pueden usar para acceder a la API.
Sufijo de dirección URL de API conference El sufijo se anexa a la dirección URL

base del servicio API Management.
API Management distingue las API
por su sufijo, por lo que el sufijo
debe ser único para cada API de un
publicador determinado.
Productos Sin límite Los productos son asociaciones de

una o varias API. Puede incluir
varias API en un producto y
ofrecerlas a los desarrolladores
mediante el portal para
desarrolladores.
Para publicar la API, hay que
asociarla a un producto (en este
ejemplo, Unlimited). Para agregar
esta nueva API a un producto,
escriba el nombre del producto
(también puede hacerlo más tarde
desde la página de configuración).
Este paso se puede repetir varias
veces para agregar la API a varios
productos.
Para acceder a la API, los
desarrolladores primero deben
suscribirse a un producto. Al
suscribirse, obtienen una clave de
suscripción que funciona con
cualquier API de ese producto.
Si creó la instancia de APIM, ya es
un administrador, así que está
suscrito a todos los productos.
De forma predeterminada, cada
instancia de API Management
incluye dos productos de ejemplo:
Starter y Unlimited.
Etiquetas Etiquetas para organizar las API.

Pueden usarse etiquetas para
buscar, agrupar o filtrar.
¿Definir versión de esta API? Para más información sobre las

versiones, consulte Publicación de
varias versiones de la API.
NOTE
Para publicar la API, debe asociarla a un producto. Puede hacerlo desde la página de configuración.
3. Seleccione Crear.
TIP
Si surgen problemas con la importación de su propia definición de API, consulte la lista de problemas y restricciones
conocidos.
Prueba de la nueva API APIM en Azure Portal
Se puede llamar a las operaciones directamente desde Azure Portal, lo que proporciona una forma cómoda de
ver y probar las operaciones de una API.
1. Seleccione la API que ha creado en los pasos anteriores (desde la pestaña API ).
2. Presione la pestaña Prueba.
3. Haga clic en GetSpeakers. En la página se muestran los campos de los parámetros de consulta, que, en
este caso, no tiene ninguno, y los encabezados. Uno de los encabezados es "Ocp-Apim-Suscripción-
Key", para la clave de suscripción del producto que está asociado a esta API. La clave se rellena
automáticamente.
4. Presione Enviar.
Back-end responde con 200 Aceptar y algunos datos.
Llamada a una operación desde el portal para desarrolladores

También se pueden llamar a las operaciones desde el portal para desarrolladores para probar las API.
1. Desplácese hasta el portal para desarrolladores.
2. Seleccione API, haga clic en Demo Conference API y, después, en GetSpeakers.
En la página se muestran los campos de los parámetros de consulta, que, en este caso, no tiene
ninguno, y los encabezados. Uno de los encabezados es "Ocp-Apim-Suscripción-Key", para la clave de
suscripción del producto que está asociado a esta API. Si ha creado la instancia APIM, ya es
administrador, por lo que la clave se rellena automáticamente.
3. Presione Try it (Probarlo).
4. Presione Enviar.
Después de invocar una operación, el portal para desarrolladores muestra las respuestas.
Pasos siguientes
En este tutorial aprendió lo siguiente:
Importación de la primera API
Avance hasta el siguiente tutorial:
Creación y publicación de un producto
Crear y publicar un producto
En Azure API Management, un producto contiene una o varias API, así como una cuota de uso y los términos de
uso. Una vez publicado un producto, los desarrolladores pueden suscribirse al producto y comenzar a usar las API
del producto.
Agregar una API al producto
Requisitos previos
Además, realice el siguiente tutorial: Importación y publicación de la primera API.

1. Haga clic en Productos en el menú de la izquierda para mostrar la página Productos.
2. Haga clic en + Agregar.
Al agregar un producto, se debe proporcionar la siguiente información:
NOMBRE DESCRIPCIÓN
Nombre para mostrar El nombre que desea que aparezca en el portal para
desarrolladores.
NOMBRE Un nombre descriptivo del producto.
DESCRIPCIÓN El campo Configuración le permite incluir información

detallada sobre el producto, por ejemplo, su finalidad, las
API a las que proporciona acceso y otra información útil.
Estado Presione Publicado si desea publicar el producto. Para

poder llamar a las API de un producto, este debe
publicarse. De forma predeterminada, los nuevos
productos no se publican y solo son visibles para el grupo
Administradores.
Requiere suscripción Seleccione Require subscription (Requerir suscripción) si

se requiere que se suscriba un usuario para usar el
producto.
NOMBRE DESCRIPCIÓN
Requiere aprobación Seleccione Require approval (Requerir aprobación) si

desea que un administrador revise y acepte o rechace los
intentos de suscripción a este producto. Si la casilla está
desactivada, los intentos de suscripción se aprueban
automáticamente.
Límite de recuento de suscripciones Para limitar el número de varias suscripciones simultáneas,

escriba el límite de suscripciones.
Términos legales Puede incluir los términos de uso del producto que deben
aceptar los suscriptores para usarlo.
API existentes Los productos son asociaciones de una o varias API.

Puede incluir varias API y ofrecerlas a los desarrolladores
mediante el portal para desarrolladores.
Puede agregar una API existente durante la creación del
producto. Puede agregar una API al producto más
adelante, bien desde la página Configuración de los
productos o durante la creación de dicha API.
3. Haga clic en Crear para crear el nuevo producto.

Adición de más configuraciones
Puede continuar con la configuración del producto después de guardarla si elige la pestaña Configuración.
Vea o agregue suscriptores al producto desde la pestaña Suscripciones.
La visibilidad de un producto que pueden tener los desarrolladores o invitados se puede establecer en la pestaña
Control de acceso.
Incorporación de API a un producto

Los productos son asociaciones de una o varias API. Puede incluir varias API y ofrecerlas a los desarrolladores
mediante el portal para desarrolladores. Puede agregar una API existente durante la creación del producto. Puede
agregar una API al producto más adelante, bien desde la página Configuración de los productos o durante la
creación de dicha API.
Los desarrolladores tienen que suscribirse primero a un producto para acceder a la API. Al suscribirse, obtienen
una clave de suscripción que funciona con cualquier API de ese producto. Si creó la instancia de APIM, ya es un
administrador, así que, de forma predeterminada, está suscrito a todos los productos.
Adición de una API a un producto existente
1. En la pestaña Productos, seleccione un producto.
2. Vaya a la pestaña API.
4. Elija una API y haga clic en Seleccionar.
TIP
Puede crear o actualizar la suscripción del usuario para un producto con claves de suscripción personalizadas mediante la API
REST o un comando de PowerShell.
Pasos siguientes
Agregar una API al producto
Create blank API and mock API responses (Creación de una API en blanco y simulación de respuestas de API)
Simulación de respuestas de API
Pueden importarse API de back-end en una API de APIM, o bien crearse o administrarse manualmente. Los
pasos descritos en este tutorial muestran cómo usar APIM para crear una API en blanco y administrarla de forma
manual. El tutorial muestra cómo establecer una directiva en una API para que devuelva una respuesta simulada.
Este método permite a los desarrolladores continuar con la implementación y las pruebas de la instancia de APIM
en caso de que el back-end no esté disponible para enviar respuestas reales. La funcionalidad de simular
respuestas puede resultar útil en una serie de escenarios:
Cuando la fachada de API se ha diseñado primero y la implementación de back-end se realiza más tarde. El
back-end se está desarrollando en paralelo.
Cuando el back-end no está temporalmente operativo o no se puede escalar.
Creación de una API de prueba
Adición de una operación a la API de prueba
Habilitación de la simulación de respuesta
Probar la API simulada
Requisitos previos
Comprender el concepto de directivas en API Management de Azure.

Los pasos de esta sección muestran cómo crear una API en blanco sin back-end. También se explica cómo agregar
una operación a la API. Al llamar a la operación después de completar los pasos de esta sección, se produce un
error. No se devolverá ningún error después de finalizar los pasos descritos en la sección "Habilitación de la
simulación de respuesta".
1. Seleccione API en el servicio API Management.

2. En el menú izquierdo, seleccione + Agregar API.
3. Seleccione API en blanco en la lista.
4. Escriba "API de prueba" en Nombre para mostrar.
5. Escriba "Sin límite" en Productos.

1. Seleccione la API que creó en los pasos anteriores.
2. Haga clic en + Agregar operación.
Nombre para mostrar Llamada de prueba El nombre se muestra en el Portal

URL (verbo HTTP) GET Puede elegir uno de los verbos HTTP
predefinidos.
URL /test Una ruta de acceso URL de la API.
Descripción Especifique una descripción de la

operación que se usa para
proporcionar documentación a los
desarrolladores que usen esta API en
el Portal para desarrolladores.
Pestaña Consulta Puede agregar parámetros de

consulta. Además de proporcionar
un nombre y una descripción, puede
especificar valores que se pueden
asignar a este parámetro. Uno de los
valores se puede marcar como
predeterminado (opcional).
Pestaña Solicitud Puede definir esquemas, ejemplos y

tipos de contenido de solicitud.
Pestaña Respuesta Consulte los pasos que figuran abajo Defina esquemas, ejemplos, tipos de
de esta tabla. contenido y códigos de estado de
respuesta.
3. Seleccione la pestaña Respuesta, que se encuentra bajo los campos URL, Nombre para mostrar y
Descripción.
4. Haga clic en + Agregar respuesta.
5. Seleccione 200 OK en la lista.
6. En el encabezado Representaciones de la derecha, seleccione + Agregar representación.
7. Escriba "application/json" en el cuadro de búsqueda y seleccione el tipo de contenido application/json.
8. En el cuadro de texto Ejemplo, escriba { 'sampleField' : 'test' } .

1. Seleccione la API que creó en el paso "Creación de una API de prueba".
2. Seleccione la operación de prueba que agregó.
3. En la ventana de la derecha, haga clic en Diseño.
4. En la ventana Procesamiento de entrada, haga clic en + Agregar directiva.
5. Seleccione el icono de respuestas simuladas en la galería.
6. En el cuadro de texto API Management response (Respuesta de API Management), escriba 200 OK,
application/json. Esta selección indica que la API debe devolver la respuesta de ejemplo que definió en la
sección anterior.
7. Haga clic en Save(Guardar).
1. Seleccione la API que creó en el paso "Creación de una API de prueba".

2. Abra la pestaña Prueba.
3. Asegúrese de que la API de Llamada de prueba está seleccionada.
TIP
Una barra amarilla con el texto La simulación de respuesta está habilitada indica que las respuestas devueltas
desde API Management envían una directiva de simulación y no una respuesta de back-end real.
4. Seleccione Enviar para realizar una llamada de prueba.

5. Respuesta HTTP muestra el JSON especificado como un ejemplo en la primera sección del tutorial.
Vídeo
Pasos siguientes
Transformación y protección de una API publicada
Transformación y protección de una API
El tutorial muestra cómo puede transformar una API para que no revele información privada del back-end. Por
ejemplo, recomendamos ocultar la información sobre la pila de tecnología que se ejecuta en el back-end, así
como las URL originales que aparecen en el cuerpo de la respuesta HTTP de la API y, en su lugar, redirigirlas a
la puerta de enlace de APIM.
Este tutorial muestra lo fácil que es agregar protección para la API de back-end configurando el límite de
frecuencia con Azure API Management. Por ejemplo, puede que quiera limitar un número de llamadas a la API
para que los desarrolladores no la sobreutilicen. Para obtener más información, consulte Directivas de
administración de API.
Transformación una API para eliminar encabezados de respuesta
Reemplazo de URL originales en el cuerpo de la respuesta de API con las URL de puerta de enlace de
APIM
Protección de una API agregando la directiva de límite de frecuencia (limitación)
Prueba de las transformaciones
Requisitos previos
Comprender el concepto de directivas en API Management de Azure.

TIP

Esta sección muestra cómo ocultar los encabezados HTTP que no desea mostrar a los usuarios. En este
ejemplo, se eliminan los siguientes encabezados en la respuesta HTTP:
X-Powered-By
X-AspNet-Version
Prueba de la respuesta original
Para ver la respuesta original, siga estos pasos:
1. En la instancia de servicio APIM, seleccione API (bajo API MANAGEMENT).
2. Haga clic en Demo Conference API (API de conferencia de demostración) en la lista de API.
3. Haga clic en la casilla Prueba de la parte superior de la pantalla.
4. Seleccione la operación GetSpeakers.
5. Haga clic en el botón Enviar situado en la parte inferior de la pantalla.
La respuesta original debería tener este aspecto:
Establecimiento de la directiva de transformación
1. Seleccione Demo Conference API (API de conferencia de demostración).

2. En la parte superior de la pantalla, seleccione la pestaña Diseño.
3. Seleccione Todas las operaciones.
4. En la sección Procesamiento de salida, haga clic en el icono </>.
5. Coloque el cursor dentro del elemento <outbound>.
6. En la ventana de la derecha, en Transformation policies (Directivas de transformación), haga clic en
Set HTTP header (Establecer encabezado HTTP ) dos veces (para insertar dos fragmentos de directiva).
7. Modifique el código <outbound> para que se muestre lo siguiente:
<set-header name="X-Powered-By" exists-action="delete" />

<set-header name="X-AspNet-Version" exists-action="delete" />
8. Haga clic en el botón Save (Guardar).
Reemplazo de URL originales en el cuerpo de la respuesta de API

con las URL de puerta de enlace de APIM
En esta sección se explica cómo ocultar las URL originales que aparecen en el cuerpo de la respuesta HTTP de
la API y, en su lugar, redirigirlas a la puerta de enlace de APIM.
Prueba de la respuesta original
Para ver la respuesta original, siga estos pasos:
2. Haga clic en la casilla Prueba de la parte superior de la pantalla.
4. Haga clic en el botón Enviar situado en la parte inferior de la pantalla.
Como puede ver, la respuesta original tiene el siguiente aspecto:
Establecimiento de la directiva de transformación

4. En la sección Procesamiento de salida, haga clic en el icono </>.
5. Coloque el cursor dentro del elemento <outbound>.
6. En la ventana de la derecha, en Transformation policies (Directivas de transformación), haga clic en +
Find and replace string in body (+ Buscar y reemplazar cadena en el cuerpo).
7. Modifique el código find-and-replace (en el elemento <outbound>) para reemplazar la URL con el
fin de que coincida con la puerta de enlace de APIM. Por ejemplo:
<find-and-replace from="://conferenceapi.azurewebsites.net" to="://apiphany.azure-

api.net/conference"/>
Protección de una API agregando la directiva de límite de frecuencia

(limitación)
En esta sección se explica cómo agregar protección para la API de back-end configurando límites de
frecuencia. Por ejemplo, puede que quiera limitar un número de llamadas a la API para que los desarrolladores
no la sobreutilicen. En este ejemplo, el límite se establece en 3 llamadas cada 15 segundos para cada
identificador de suscripción. Después de 15 segundos, un desarrollador puede volver a tratar de llamar a la
API.
4. En la sección Procesamiento de entrada, haga clic en el icono </>.
5. Coloque el cursor dentro del elemento**<inbound>**.
6. En la ventana de la derecha, bajo Access restriction policies (Directivas de restricción de acceso), haga
clic en + Limit call rate per key (+ Limitar la tasa de llamadas por clave).
7. Modifique el código rate-limit-by-key (en el elemento <inbound>) por el código siguiente:
<rate-limit-by-key calls="3" renewal-period="15" counter-key="@(context.Subscription.Id)" />

En este punto, si observa el código en el editor de código, las directivas tienen este aspecto:
<policies>
<inbound>
<rate-limit-by-key calls="3" renewal-period="15" counter-key="@(context.Subscription.Id)" />
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<set-header name="X-Powered-By" exists-action="delete" />
<set-header name="X-AspNet-Version" exists-action="delete" />
<find-and-replace from="://conferenceapi.azurewebsites.net:443" to="://apiphany.azure-
<find-and-replace from="://conferenceapi.azurewebsites.net" to="://apiphany.azure-
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
En el resto de esta sección se prueban transformaciones de directiva que estableció en este artículo.
Prueba de los encabezados de respuesta eliminados
2. Seleccione la pestaña Prueba.
3. Haga clic en la operación GetSpeakers.
4. Presione Enviar.
Como puede ver, los encabezados se han eliminado:
Prueba de la URL reemplazada

4. Presione Enviar.
Como puede ver, la URL se ha reemplazado.
Prueba del límite de frecuencia (limitación)
4. Presione Enviar tres veces en una fila.
Después de enviar la solicitud 3 veces, obtendrá la respuesta 429 Demasiadas solicitudes.
5. Espere 15 segundos o menos y vuelva a pulsar Enviar. Esta vez debería obtener una respuesta 200 OK.
Vídeo
Pasos siguientes
Reemplazo de URL originales en el cuerpo de la respuesta de API con las URL de puerta de enlace de
APIM
Protección de una API agregando la directiva de límite de frecuencia (limitación)
Supervisión de una API
Supervisión de las API publicadas
Con Azure Monitor, puede visualizar, consultar, enrutar, archivar y realizar acciones en las métricas o los registros
procedentes de los recursos de Azure.
Visualización de registros de actividad
Visualización de los registros de diagnóstico
Visualización de las métricas de las API
Configurar una regla de alerta cuando la API recibe llamadas no autorizadas
En el vídeo siguiente se muestra cómo supervisar API Management con Azure Monitor.
Requisitos previos
Disponibilidad
IMPORTANT
Esta característica está disponible en los niveles Premium, Estándar, Básico y Desarrollador de API Management.

API Management emite métricas cada minuto, lo que le ofrece visibilidad casi en tiempo real sobre el estado y el
mantenimiento de las API. El siguiente es un resumen de algunas de las métricas disponibles:
Capacidad (versión preliminar): ayuda a tomar decisiones acerca de cómo actualizar o degradar los servicios de
APIM. La métrica se emite por minuto y refleja la capacidad de la puerta de enlace en el momento del informe.
La métrica oscila entre 0 y 100, y se calcula en función de los recursos de la puerta de enlace, como el uso de la
CPU y de la memoria.
Solicitudes de puerta de enlace en total: el número de solicitudes API en el período.
Solicitudes de puerta de enlace correctas: el número de solicitudes de API que recibieron códigos de respuesta
HTTP correctos, como 304, 307 y los menores de 301 (por ejemplo, 200).
Solicitudes de puerta de enlace con error: el número de solicitudes de API que recibieron códigos de respuesta
HTTP erróneos, como 400 y cualquiera mayor que 500.
Solicitudes de puerta de enlace no autorizadas: el número de solicitudes API que recibieron códigos de
respuesta HTTP, incluidos 401, 403 y 429.
Otras solicitudes de puerta de enlace: el número de solicitudes API que recibieron códigos de respuesta HTTP
que no pertenecen a ninguna de las categorías anteriores (por ejemplo, 418).
Para acceder a la métrica:
1. Seleccione Métricas en el menú situado cerca de la parte inferior de la página.
2. En la lista desplegable, seleccione las métricas que le interesen. Por ejemplo, Solicitudes de puerta de
enlace correctas. También puede agregar más métricas al gráfico.
3. El gráfico muestra el número total de llamadas API correctas.
Configuración de una regla de alerta para solicitudes no autorizadas

Puede configurar la recepción de alertas en función de métricas y registros de actividad. Azure Monitor permite
configurar una alerta que haga lo siguiente cuando se desencadena:
Enviar una notificación por correo electrónico
Llamar a un webhook
Invocar una aplicación lógica de Azure
Para configurar alertas:
1. Seleccione Alertas en la barra de menús cerca de la parte inferior de la página.
2. Haga clic en una Nueva regla de alerta para esta alerta.
3. Haga clic en Agregar condición.
4. Seleccione Métricas en el cuadro desplegable del tipo de señal.
5. Seleccione Unauthorized Gateway Requests (Solicitudes de puerta de enlace no autorizadas) como la
señal que se desea supervisar.
6. En la vista Configurar lógica de señal, especifique un umbral después del cual debe activarse la alerta y
haga clic en Hecho.
7. Seleccione un grupo de acciones existente o cree uno nuevo. En el ejemplo siguiente, se enviará un correo
electrónico a los administradores.
8. Escriba un nombre y la descripción para la regla de alertas y elija el nivel de gravedad.
9. Presione Crear regla de alertas.
10. Ahora, intente llamar a Conference API sin una clave de API. La alerta se desencadenará y se enviará un
correo electrónico a los administradores.
Registros de actividad
Los registros de actividad proporcionan información sobre las operaciones llevadas a cabo en los servicios API
Management. Con los registros de actividades, puede determinar los interrogantes “qué, quién y cuándo” de las
operaciones de escritura (PUT, POST, DELETE ) llevadas a cabo en los servicios API Management.
NOTE
Los registros de actividad no incluyen las operaciones de lectura (GET) ni las realizadas en Azure Portal o mediante las API de
administración originales.
Puede acceder a registros de actividad en el servicio API Management o a los registros de todos los recursos de
Azure en Azure Monitor.
Para ver los registros de actividad:
1. Seleccione la instancia del servicio APIM.
2. Haga clic en Registro de actividad.
3. Seleccione el ámbito de filtrado que desee y haga clic en Aplicar.
Registros de diagnóstico
Los registros de diagnóstico proporcionan información valiosa acerca de las operaciones y los errores que son
importantes para la auditoría, así como para solucionar problemas. Los registros de diagnóstico son diferentes de
los registros de actividad. Los registros de actividad proporcionan información sobre las operaciones llevadas a
cabo en los recursos de Azure. Los registros de diagnóstico proporcionan información detallada acerca de las
operaciones que el recurso ha realizado.
Para configurar registros de diagnóstico:
1. Seleccione la instancia del servicio APIM.
2. Haga clic en Configuración de diagnóstico.
3. Haga clic en Activar diagnóstico. Los registros de diagnóstico se pueden archivar junto con las métricas
en una cuenta de almacenamiento, transmitirlos en secuencias a un centro de eventos o enviarlos a los
registros de Azure Monitor.
Actualmente, API Management proporciona registros de diagnóstico (de los que se crean lotes cada hora) de una
solicitud de API individual con cada entrada que tenga el esquema siguiente:
{
"isRequestSuccess" : "",
"time": "",
"operationName": "",
"category": "",
"durationMs": ,
"callerIpAddress": "",
"correlationId": "",
"location": "",
"httpStatusCodeCategory": "",
"resourceId": "",
"properties": {
"method": "",
"url": "",
"clientProtocol": "",
"responseCode": ,
"backendMethod": "",
"backendUrl": "",
"backendResponseCode": ,
"backendProtocol": "",
"requestSize": ,
"responseSize": ,
"cache": "",
"cacheTime": "",
"backendTime": ,
"clientTime": ,
"apiId": "",
"operationId": "",
"productId": "",
"userId": "",
"apimSubscriptionId": "",
"backendId": "",
"lastError": {
"elapsed" : "",
"source" : "",
"scope" : "",
"section" : "" ,
"reason" : "",
"message" : ""
}
}
}
PROPIEDAD ESCRIBA DESCRIPCIÓN
isRequestSuccess boolean True si la solicitud HTTP se completó

con el código de estado de respuesta
dentro del intervalo 2xx o 3xx
time date-time Marca de tiempo de la recepción de la

solicitud HTTP por parte de la puerta de
enlace
operationName string Valor constante

"Microsoft.ApiManagement/GatewayLo
gs"
category string Valor constante "GatewayLogs"
durationMs integer Número de milisegundos transcurridos

desde el momento en que la puerta de
enlace recibió la solicitud hasta que se
envió toda la respuesta
callerIpAddress string Dirección IP del llamador inmediato de

la puerta de enlace (puede ser un
intermediario)
correlationId string Identificador único de la solicitud HTTP

asignado por API Management
location string Nombre de la región de Azure donde se

encontraba la puerta de enlace que
procesó la solicitud
httpStatusCodeCategory string Categoría del código de estado de

respuesta HTTP: Correcto (301 o
menos, 304 o 307), No autorizado (401,
403, 429), Erróneo (400, entre 500 y
600), Otro
resourceId string Identificador del recurso de API

Management
/SUBSCRIPTIONS/<subscription>/RESO
URCEGROUPS/<resource-
group>/PROVIDERS/MICROSOFT.APIM
ANAGEMENT/SERVICE/<name>
properties objeto Propiedades de la solicitud actual
method string Método HTTP de la solicitud entrante
url string Dirección URL de la solicitud entrante
clientProtocol string Versión del protocolo HTTP de la

solicitud entrante
responseCode integer Código de estado de la respuesta HTTP

enviada a un cliente
backendMethod string Método HTTP de la solicitud enviada a

un back-end
backendUrl string Dirección URL de la solicitud enviada a

un back-end
backendResponseCode integer Código de la respuesta HTTP recibida

de un back-end
backendProtocol string Versión del protocolo HTTP de la

solicitud enviada a un back-end
requestSize integer Número de bytes recibidos de un cliente

durante el procesamiento de solicitudes
responseSize integer Número de bytes enviados a un cliente

durante el procesamiento de solicitudes
cache string Estado de participación de la caché de

API Management en el procesamiento
de la solicitud (es decir, acierto, error,
ninguno)
cacheTime integer Número de milisegundos empleados en

la E/S de la caché global de API
Management (conexión, envío y
recepción de bytes)
backendTime integer Número de milisegundos empleados en

la E/S global de back-end (conexión,
envío y recepción de bytes)
clientTime integer Número de milisegundos empleados en

la E/S global del cliente (conexión, envío
y recepción de bytes)
apiId string Identificador de la entidad de la API de

la solicitud actual
operationId string Identificador de la entidad de la

operación de la solicitud actual
productId string Identificador de la entidad del producto

de la solicitud actual
userId string Identificador de la entidad del usuario

apimSubscriptionId string Identificador de la entidad de la

suscripción de la solicitud actual
backendId string Identificador de la entidad del back-end

lastError objeto Último error de procesamiento de la

solicitud
elapsed integer Número de milisegundos transcurridos

desde que la puerta de enlace recibió
una solicitud hasta el momento en que
se produjo el error
source string Nombre del controlador interno del

procesamiento o de la directiva que
produjo el error
scope string Ámbito del documento de directiva que

contiene la directiva que produjo el
error
section string Sección del documento de directiva que

contiene la directiva que produjo el
error
reason string Motivo del error
message string Mensaje de error
Pasos siguientes
Visualización de registros de actividad
Visualización de los registros de diagnóstico
Configurar una regla de alerta cuando la API recibe llamadas no autorizadas
Seguimiento de llamadas
Depuración de las API con el seguimiento de
solicitudes
Este tutorial describe cómo inspeccionar el procesamiento de solicitudes para ayudarle con la depuración y la
solución de problemas de una API.
Realizar el seguimiento de una llamada
Requisitos previos

1. Seleccione API.
3. Cambie a la pestaña Prueba.
5. Asegúrese de incluir un encabezado HTTP denominado Ocp-Apim -Trace con el valor establecido en true.
NOTE
Si Ocp-Apim-Subscription-Key no se rellena automáticamente, puede recuperar el valor del Portal para
desarrolladores y exponer las claves en la página de perfil.
6. Haga clic en "Enviar" para realizar una llamada API.

7. Espere a que se complete la llamada.
8. Vaya a la pestaña de seguimiento en el consola de la API. Puede hacer clic en cualquiera de los
siguientes vínculos para saltar a la información de seguimiento detallada: entrada, back-end, salida.
En la sección de entrada, verá la solicitud original que API Management recibió del autor de la llamada y
todas las directivas aplicadas a la solicitud, que incluyen directivas de límite de velocidad y de set-header
que se agregaron en el paso 2.
En la sección back-end, verá las solicitudes que API Management envió al back-end de la API y la
respuesta que recibió.
En la sección de salida, verá todas las directivas que se aplican a la respuesta antes de enviarla de vuelta al
autor de la llamada.
TIP
Cada paso muestra también el tiempo transcurrido desde que API Management recibe la solicitud.
Pasos siguientes
Uso de revisiones
Uso de revisiones para realizar cambios que no
producen interrupciones de forma segura
Cuando la API esté lista y los desarrolladores empiecen a usarla, tendrá que realizar cambios en dicha API y, al
mismo tiempo, no interrumpir a quienes la llaman. También resulta útil informar a los desarrolladores de los
cambios realizados. Esto se logra en Azure API Management con las revisiones. Para más información, consulte
Versions & revisions (Versiones y revisiones) y API Versioning with Azure API Management (Control de versiones
con Azure API Management).
Agregar una nueva revisión
Realizar cambios que no producen interrupciones en la revisión
Convertir la revisión en actual y agregar una entrada en el registro de cambios
Examinar el portal para desarrolladores para ver los cambios y registro de cambios
Requisitos previos

1. Seleccione la página API.
2. Seleccione Demo Conference API en la lista de API (u otra API a la que desee agregar revisiones).
3. Haga clic en la pestaña Revisiones en el menú junto a la parte superior de la página.
4. Seleccione + Agregar revisión.
TIP
También puede seleccionar Agregar revisión en el menú contextual ( ... ) de la API.
5. Incluya una descripción de la nueva revisión que ayude a saber para qué va a servir.
6. Seleccione Crear
7. Ya tenemos creada la revisión.
NOTE
La API original permanece en Revisión 1. Esta es la revisión que los usuarios siguen llamando hasta que decida
convertir otra en actual.

1. Seleccione Demo Conference API en la lista de API.
2. Seleccione la pestaña Diseño situada junto a la parte superior de la pantalla.
3. Fíjese en que el selector de revisiones (que está inmediatamente encima de la pestaña de diseño) muestra
que la revisión seleccionada es Revisión 2.
TIP
Use el selector de revisión para alternar entre las revisiones con las que vaya a trabajar.
4. Seleccione + Agregar operación.

5. Establezca que la nueva operación sea POST y especifique test como nombre, nombre para mostrar y
dirección URL de la operación.
6. Guarde la nueva operación.
7. Ya hemos hecho un cambio en Revisión 2. Use el selector de revisión junto a la parte superior de la
página para volver a Revisión 1.
8. Observe que la nueva operación no figura en Revisión 1.
Convertir la revisión en actual y agregar una entrada en el registro de

cambios
1. Seleccione la pestaña Revisiones en el menú junto a la parte superior de la página.
2. Abra el menú contextual ( ... ) de Revisión 2.
3. Seleccione Convertir en actual.
4. Active la casilla Post to Public Change log for this API (Publicar en el registro de cambios público de
esta API), si quiere publicar notas sobre este cambio. Especifique una descripción del cambio que puedan
ver los desarrolladores, por ejemplo: Revisiones de prueba. Se agregó una nueva operación de
"prueba".
5. Revisión 2 es ahora la revisión actual.
Examinar el portal para desarrolladores para ver los cambios y registro

de cambios
1. En Azure Portal, seleccione API.
2. Seleccione Portal para desarrolladores en el menú superior.
3. Seleccione API y, después, Demo Conference API.
4. Observe que la nueva operación prueba ahora aparece disponible.
5. Seleccione API Change History (Historial de cambios de la API) debajo del nombre de la API.
6. Vea que la entrada en el registro de cambios aparece en esta lista.
Pasos siguientes
Convertir la revisión en actual y agregar una entrada en el registro de cambios
Examinar el portal para desarrolladores para ver los cambios y registro de cambios
Publicación de varias versiones de la API
Publicación de varias versiones de la API
A veces resulta poco práctico que todos los que llaman a la API usen exactamente la misma versión. Si alguien
que llama a una API quiere actualizarla a una versión posterior, querrá hacerlo con un método que sea fácil de
comprender. Esto se puede hacer en Azure API Management con las versiones. Para más información, consulte
Versions & revisions (Versiones y revisiones).
Agregar una nueva versión a una API existente
Elegir un esquema de versión
Agregar la versión a un producto
Examinar el portal para desarrolladores para ver la versión
Requisitos previos
Agregar una nueva versión

1. Seleccione Demo Conference API en la lista de API.
2. Seleccione el menú contextual ( ... ) junto a ella.
3. Seleccione + Agregar versión.
TIP
Las versiones también se pueden habilitar al crear una API desde cero (para ello, seleccione ¿Definir versión de esta API?
en la pantalla Agregar API).
Elegir un esquema de control de versiones

Con Azure API Management, puede elegir la forma en la que quiere que quienes llamen a una API puedan
especificar qué versión de dicha API quieren. Especifique qué versión de la API va a usar, para lo que seleccionará
un esquema de control de versiones. Este esquema puede ser una ruta de acceso, un encabezado o una
cadena de consulta. En el ejemplo siguiente, la ruta de acceso se utiliza para seleccionar el esquema de control
de versiones.
1. Deje ruta de acceso seleccionada como esquema de control de versiones.

2. Escriba demo-conference-api-v1 en el campo Nombre.
NOTE
Una versión, de hecho, es una nueva API que se basa en la revisión de otra API. Nombre es el nuevo nombre de la
API y debe ser único en la instancia de API Management.
3. Escriba v1 en el campo Identificador de la versión.
TIP
Si selecciona encabezado o cadena de consulta como esquema de control de versiones, debe proporcionar un
valor más: el nombre del parámetro de encabezado o de cadena de consulta.
4. Seleccione Crear para configurar la nueva versión.

5. Debajo de la directiva Demo Conference API en la lista de API, ahora verá dos API distintas: Original y
v1.
NOTE
Si agrega una versión a una API sin control de versiones, se creará automáticamente un Original (que responde a la
dirección URL predeterminada). Esto garantiza que quienes estén llamando en ese momento no sufran ninguna
interrupción a causa del proceso de adición de la versión. Si crea una API con las versiones habilitadas desde el
principio, no se creará un original.
6. Ahora puede modificar y configurar v1 como una API independiente de Original. Los cambios en una
versión no afectan a otra.

Para que quienes realizan las llamadas vean la versión nueva, debe agregarse a un producto.
1. Seleccione Productos en la página del modelo de implementación clásica.
2. Seleccione Ilimitado.
3. Seleccione API.
4. Seleccione Agregar.
5. Seleccione Demo Conference API, versión v1.
6. Haga clic en Seleccionar.

1. Seleccione Portal para desarrolladores en el menú superior.
2. Seleccione API y observe que Demo Conference API muestra las versiones Original y v1.
3. Seleccione v1.
4. Fíjese en la Dirección URL de la solicitud de la primera operación de la lista. Refleja que la ruta de
acceso de la dirección URL de la API incluye v1.
Pasos siguientes
Agregar una nueva versión a una API existente
Elegir un esquema de versión
Personalización del estilo de las páginas del portal para desarrolladores
Personalización del estilo de las páginas del portal
para desarrolladores
Existen tres maneras comunes de personalizar el portal para desarrolladores en Azure API Management:
Editar el contenido de las páginas estáticas y los elementos de diseño de página
Actualizar los estilos usados en los elementos de página en el portal para desarrolladores (que se explica en
esta guía)
Modificar las plantillas usadas en las páginas generadas por el portal (por ejemplo, documentos de API,
productos, autenticación de usuario)
Personalizar el estilo de los elementos de las páginas del portal para desarrolladores
Ver el cambio
Requisitos previos
Disponibilidad
IMPORTANT
Personalización del portal para desarrolladores

1. Seleccione Información general.
2. Haga clic en el botón Portal para desarrolladores en la parte superior de la ventana Información
general. También puede hacer clic en el vínculo de la dirección URL del portal para desarrolladores.
3. En el lado superior izquierdo de la pantalla, verá un icono formado por dos pinceles. Mantenga el puntero
sobre este icono para abrir el menú de personalización del portal.
4. Seleccione Estilos en el menú para abrir el panel de personalización del estilo.

En la página aparecen todos los elementos que se pueden personalizar con Estilos.
5. Escriba "headings-color" en el campo Change variable values to customize developer portal
appearance: (Cambiar valores de variables para personalizar la apariencia del portal para
desarrolladores).
El elemento @headings-color aparece en la página. Esta variable controla el color del texto.
6. Haga clic en el campo correspondiente a la variable @headings-color.

Se abre la lista desplegable del selector de colores.
7. En esta lista, seleccione un nuevo color.
TIP
Existe una versión preliminar en tiempo real disponible de todos los cambios. Un indicador de progreso aparece en
la parte superior del panel de personalización. Al cabo de unos segundos, el color del texto del encabezado cambia al
que se acaba de seleccionar.
8. Seleccione Publicar en la parte inferior izquierda del menú del panel de personalización.
9. Seleccione Publish customizations (Publicar personalizaciones) para que los cambios estén disponibles
públicamente.
Ver el cambio
1. Desplácese hasta el portal para desarrolladores.
2. Puede ver el cambio que ha realizado.
Pasos siguientes
Personalizar el estilo de los elementos de las páginas del portal para desarrolladores
Ver el cambio
También podría estar interesado en aprender cómo personalizar el portal para desarrolladores para Azure API
Management mediante plantillas.
Ejemplos de directivas de API Management
Las directivas constituyen una funcionalidad del sistema eficaz que permite al editor cambiar el comportamiento
de la API mediante la configuración. Las directivas son una colección de declaraciones que se ejecutan
secuencialmente en la solicitud o respuesta de una API. En la tabla siguiente se incluyen vínculos a ejemplos y
una breve descripción de cada ejemplo.
Directivas de entrada
Incorporación de un encabezado de reenviado para permitir Muestra cómo agregar un encabezado de reenviado a la
que la API de back-end cree direcciones URL correctas solicitud de entrada para permitir que la API de back-end
cree direcciones URL correctas.
Incorporación de un encabezado con un identificador de Muestra cómo agregar un encabezado con un identificador
correlación de correlación para la solicitud de entrada.
Incorporación de funcionalidades a un servicio back-end y Muestra cómo agregar funcionalidades a un servicio back-
almacenamiento de la respuesta en caché end. Por ejemplo, aceptar el nombre de un lugar en vez de su
latitud y longitud en una API de pronóstico meteorológico.
Autorización de acceso con notificaciones JWT Muestra cómo autorizar el acceso a los métodos HTTP
específicos en una API con notificaciones JWT.
Autorización de solicitudes mediante un autorizador externo Muestra cómo utilizar un autorizador externo para proteger
el acceso de una API.
Autorización de acceso con el token de OAuth de Google Muestra cómo autorizar el acceso a los puntos de conexión
con Google como proveedor de tokens de OAuth.
Generación de la firma de acceso compartido y reenvío de la Muestra cómo generar una firma de acceso compartido
solicitud a Azure Storage mediante expresiones y reenviar la solicitud a Azure Storage
con la directiva de reescritura del identificador URI.
Obtención del token de acceso de OAuth2 desde AAD y Proporciona un ejemplo de uso de OAuth2 para la
reenvío al back-end autorización entre la puerta de enlace y un back-end.
Muestra cómo obtener un token de acceso en AAD y
reenviarlo al back-end.
Obtención del token de X-CSRF en la puerta de enlace de Muestra cómo implementar el patrón X-CSRF que utilizan
SAP mediante la directiva de solicitud de envío muchas API. En este ejemplo es específico de la puerta de
enlace de SAP.
Enrutamiento de la solicitud en función del tamaño de su Muestra cómo enrutar las solicitudes en función del tamaño
cuerpo de su cuerpo.
Envío de información contextual de la solicitud al servicio de Muestra cómo enviar información contextual al servicio de
back-end back-end para el registro o el procesamiento.
Establecimiento de la duración en caché de las respuestas Muestra cómo establecer la duración en caché de las
respuestas con el valor maxAge en el encabezado de control
de caché que envía el back-end.
Directivas de salida
Filtrado del contenido de la respuesta Muestra cómo filtrar los elementos de datos de la carga de
respuesta según el producto asociado a la solicitud.
Directivas de errores
Registro de errores en Stackify Muestra cómo agregar una directiva de registro de errores
para enviarlos a Stackify para el registro.
Ejemplos de Azure PowerShell para API Management
En la tabla siguiente hay scripts de ejemplo para trabajar con el servicio de API Management desde PowerShell.
Aprovisionamiento y administración
Incorporación de un usuario Crea un usuario en API Management y obtiene una clave de

suscripción.
Creación de un servicio APIM Crea un servicio de administración de API de SKU de

desarrollador.
Restauración de servicio Realiza copias de seguridad y restaura un servicio APIM.
Escala un servicio APIM Escala y agrega regiones al servicio APIM.
Configuración de dominio personalizado Configura el dominio personalizado en el punto de conexión

de proxy y portal del servicio API Management.
Definición de API
Importación de API Importa una API y la agrega a un producto APIM.
Protección
Seguridad de back-end Asegura el back-end con autenticación mutua de certificados.
Protección
Configuración de la directiva de límite de velocidad Aplica el límite de velocidad para la directiva en el nivel de
producto.
Terminología
Este artículo proporciona definiciones para los términos que son específicos de API Management (APIM ).
Definiciones de términos
API de back-end: servicio HTTP que implementa la API y sus operaciones.
API de front-end/API APIM: una API de APIM no hospeda las API, crea fachadas para las API con el fin
de personalizarlas según sus necesidades sin tocar la API de back-end. Para obtener más información,
consulte Importación y publicación de la primera API.
Producto de APIM producto que contiene una o varias API, así como una cuota de uso y los términos de
uso. Puede incluir varias API y ofrecerlas a los desarrolladores mediante el Portal para desarrolladores.
Para obtener más información, consulte Creación y publicación de un producto.
Operación de API de APIM: cada API representa un conjunto de operaciones disponibles para los
desarrolladores. Cada API de APIM contiene una referencia a un servicio back-end que implementa la API
y sus operaciones se asignan a las operaciones implementadas por dicho servicio. Para obtener más
información, consulte Simulación de respuestas de API.
Versión: habrá quienes quieran publicar características de la API nuevas o diferentes para algunos
usuarios, mientras que otros preferirán quedarse con la API que actualmente les vale. Para obtener más
información, consulte Publicación de varias versiones de la API.
Revisión: cuando la API esté lista y los desarrolladores empiecen a usarla, normalmente hay que tener
cuidado al realizar cambios en dicha API y, al mismo, tiempo, no interrumpir a quienes la llaman. También
resulta útil informar a los desarrolladores de los cambios realizados. Para obtener más información,
consulte el artículo sobre el uso de revisiones.
Portal para desarrolladores de: los clientes (programadores) deben usar el Portal para desarrolladores
para acceder a las API. Se puede personalizar el Portal para desarrolladores. Para obtener más
información, consulte cómo personalizar el Portal para desarrolladores.
Pasos siguientes
Creación de una instancia
Directivas de Azure API Management
En Azure API Management (APIM ), las directivas constituyen una eficaz funcionalidad del sistema que permite
al editor cambiar el comportamiento de la API mediante la configuración. Las directivas son una colección de
declaraciones que se ejecutan secuencialmente en la solicitud o respuesta de una API. Entre las declaraciones
más usadas se encuentran la conversión de formato de XML a JSON y la limitación de tasa de llamadas para
restringir la cantidad de llamadas entrantes de un desarrollador. Hay muchas más directivas disponibles y listas
para usar.
Las directivas se aplican en la puerta de enlace que se encuentra entre el consumidor de la API y la API
administrada. La puerta de enlace recibe todas las solicitudes y normalmente las reenvía sin modificar a la API
subyacente. Sin embargo, una directiva puede aplicar cambios a la solicitud de entrada y a la respuesta de
salida.
directivas de API Management, a menos que la directiva especifique lo contrario. Algunas directivas como
Flujo de control y Establecer variable se basan en expresiones de directiva. Para obtener más información,
consulte Directivas avanzadas y Expresiones de directiva.
Descripción de la configuración de directivas

La definición de la directiva es un documento XML simple que describe una secuencia de declaraciones de
entrada y de salida. El XML se puede editar directamente en la ventana de definición. Se ofrece una lista de
instrucciones a la derecha y las instrucciones aplicables al ámbito actual están habilitadas y resaltadas.
Al hacer clic en una declaración habilitada se agregará el XML correspondiente en la ubicación del cursor en la
vista de definición.
NOTE
Si la directiva que desea agregar no está habilitada, asegúrese de que se encuentra en el ámbito correcto para esa
directiva. Cada instrucción de la directiva está diseñada para su uso en determinados ámbitos y secciones de la directiva.
Para revisar las secciones y los ámbitos de una directiva, compruebe la sección de uso de esa directiva en la referencia de
directivas.
La configuración se divide en inbound , backend , outbound y on-error . La serie de instrucciones de una

directiva determinada se ejecuta en orden para una solicitud y una respuesta.
<policies>
<inbound>

</inbound>
<backend>

</backend>
<outbound>

</outbound>
<on-error>

</on-error>
</policies>
Si se produce un error durante el procesamiento de una solicitud, los pasos restantes de las secciones inbound ,
backend o outbound se omiten y la ejecución salta a las instrucciones de la sección on-error . Mediante la
colocación de instrucciones de directiva en la sección on-error puede revisar el error con la propiedad
context.LastError , inspeccionar y personalizar la respuesta de error con la directiva set-body y configurar lo
que ocurre si se produce un error. Existen códigos de error para pasos integrados y errores que pueden
producirse durante el procesamiento de las instrucciones de directiva. Para más información, consulte Control
de errores en las directivas de administración de API.
Configuración de directivas
Para información sobre cómo configurar directivas, consulte el artículo sobre edición o establecimiento de
directivas.
Referencia de las directivas

Consulte Referencia de directivas para ver una lista completa de declaraciones de directivas y su configuración.
Ejemplos de directivas
Vea ejemplos de directivas para obtener más código de ejemplo.
Ejemplos
Aplicación de las directivas especificadas en distintos ámbitos
Si tiene una directiva de nivel global y una directiva configurada para una API, cuando se use esa API en
concreto, se aplicarán ambas directivas. Administración de API tiene en cuenta el orden determinista de
declaraciones de directiva combinadas mediante el elemento base.
<policies>
<inbound>
<cross-domain />
<base />
<find-and-replace from="xyz" to="abc" />
</inbound>
</policies>
En la definición de directiva del ejemplo anterior, la instrucción cross-domain se ejecutaría antes de las
directivas superiores que, a su vez, irían seguidas de la directiva find-and-replace .
Restricción de las solicitudes de entrada
Para agregar una nueva instrucción a fin de restringir las solicitudes de entrada a direcciones IP concretas, sitúe
el cursor exactamente dentro del contenido del elemento XLM inbound y haga clic en la instrucción Restrict
caller IPs (Restringir las IP del autor de llamada).
Así, se agregará un fragmento de código XML al elemento inbound que ofrece orientación sobre cómo
configurar la instrucción.
<ip-filter action="allow | forbid">

<address>address</address>
<address-range from="address" to="address"/>
</ip-filter>
Para limitar las solicitudes de entrada y aceptar solo las procedentes de una dirección IP de 1.2.3.4, modifique
el XML de la manera siguiente:
<ip-filter action="allow">
<address>1.2.3.4</address>
</ip-filter>
Pasos siguientes
Para obtener más información sobre cómo trabajar con directivas, consulte:
API de transformación
En la Referencia de directivas se muestra una lista completa de declaraciones de directivas y su
configuración
Directivas de administración de API
En esta sección se proporciona una referencia para las siguientes directivas de API Management. Para obtener
más información sobre cómo agregar y configurar directivas, consulte Directivas en Administración de API.
Las directivas constituyen una eficaz funcionalidad del sistema que permite al publicador cambiar el
comportamiento de la API a través de la configuración. Las directivas son una colección de declaraciones que se
ejecutan secuencialmente en la solicitud o respuesta de una API. Entre las declaraciones más usadas se
encuentran la conversión de formato de XML a JSON y la limitación de tasa de llamadas para restringir la
cantidad de llamadas entrantes de un desarrollador. Hay muchas más directivas disponibles y listas para usar.
directivas de API Management, a menos que la directiva especifique lo contrario. Algunas directivas como Flujo
de control y Establecer variable se basan en expresiones de directiva. Para más información, consulte Directivas
avanzadas y Expresiones de directiva.
Directivas
Activar encabezado HTTP : aplica la existencia o el valor de un encabezado HTTP.
Limitar la frecuencia de llamadas por suscripción : evita los picos de uso de la API limitando la
frecuencia de llamadas, por suscripción.
Limitar la frecuencia de llamadas por clave : evita los picos de uso de la API limitando la frecuencia de
llamadas, por clave.
Restringir IP de autor de llamada : filtra (permite/deniega) las llamadas de direcciones IP específicas o
de intervalos de direcciones.
Establecer cuota de uso por suscripción : le permite aplicar un volumen de llamadas renovables o
permanentes o una cuota de ancho de banda por suscripción.
Establecer cuota de uso por clave : le permite aplicar un volumen de llamadas renovables o
permanentes o una cuota de ancho de banda por clave.
Validar JWT : aplica la existencia y la validez de un JWT extraído de un encabezado HTTP especificado o
un parámetro de consulta especificado.
Flujo de control: aplica condicionalmente instrucciones de directiva basadas en la evaluación de
expresiones booleanas.
Reenviar solicitud : reenvía la solicitud al servicio back-end.
Limitar la simultaneidad: evita que las directivas delimitadas las ejecute simultáneamente un número de
solicitudes mayor que el especificado.
Log to Event Hub (Registrar en el centro de eventos): envía mensajes en el formato especificado a un
destino de mensaje definido por una entidad del registrador.
Mock response (Simular respuesta): anula la ejecución de la canalización y devuelve la respuesta ficticia
directamente al llamador.
Reintentar : reintenta ejecutar las instrucciones de directiva adjuntas, si y hasta que se cumple la
condición. La ejecución se repite en los intervalos de tiempo especificados y hasta el número de
reintentos indicado.
Devolver respuesta : anula la ejecución de la canalización y devuelve la respuesta especificada
Enviar solicitud unidireccional : envía una solicitud a la dirección URL especificada sin esperar una
respuesta.
Enviar solicitud : envía una solicitud a la dirección URL especificada.
Establecer el proxy HTTP: permite enrutar las solicitudes reenviadas a través de un proxy HTTP.
Set variable (Establecer variable): conserva un valor en una variable de contexto con nombre para el
acceso posterior.
Establecer método de solicitud : le permite cambiar el método HTTP de una solicitud.
Establecimiento de código de estado: cambia el código de estado HTTP al valor especificado.
Seguimiento: agrega una cadena a la salida de API Inspector.
Wait (Esperar): espera a que se completen las directivas adjuntas Send request (Enviar solicitud), Get
value from cache (Obtener el valor de caché) o Control flow (Flujo de control) antes de continuar.
Autenticar con opción básica : autenticar con un servicio de back-end mediante la autenticación básica.
Autenticar con certificado de cliente : autenticar con un servicio de back-end mediante certificados de
cliente.
Autenticar con identidad administrada: autenticar con un servicio de back-end mediante una identidad
administrada.
Caching policies
Obtener de caché : realiza una búsqueda en caché y devuelve una respuesta en caché válida cuando esté
disponible.
Almacenar en caché : almacena en caché la respuesta de acuerdo con la configuración de control de
caché especificada.
Obtener valor de caché : recupere un elemento almacenado en caché por clave.
Almacenar valor en caché : almacene un elemento en la memoria caché por clave.
Quitar valor de caché ; quita un elemento de la memoria caché por clave.
Permitir llamadas entre dominios : permite que la API sea accesible desde los clientes basados en
explorador de Adobe Flash y Microsoft Silverlight.
CORS : agrega soporte de uso compartido de recursos entre orígenes (CORS ) a una operación o a una
API para permitir llamadas entre dominios desde clientes basados en explorador.
JSONP : agrega JSON con soporte de relleno (JSONP ) a una operación o a una API para permitir
llamadas entre dominios desde clientes basados en explorador de JavaScript.
Convertir JSON a XML : convierte el cuerpo de solicitud o respuesta de JSON a XML.
Convertir XML a JSON : convierte el cuerpo de solicitud o respuesta de XML a JSON.
Buscar y reemplazar la cadena en el cuerpo : encuentra una subcadena de solicitud o de respuesta y la
reemplaza por una subcadena diferente.
Enmascarar URL en el contenido : reescribe (enmascara) vínculos en el cuerpo de respuesta para que
apunten al vínculo equivalente a través de la puerta de enlace.
Establecer el servicio back-end : cambia el servicio back-end para una solicitud entrante.
Establecer cuerpo -establece el cuerpo del mensaje para las solicitudes entrantes y salientes.
Establecer encabezado HTTP : asigna un valor a un encabezado de respuesta o de solicitud existente o
agrega un nuevo encabezado de este tipo.
Establecer el parámetro de cadena de consulta : agrega, reemplaza el valor o elimina el parámetro de la
cadena de consulta de la solicitud.
URL de reescritura : convierte una URL de solicitud de su forma pública a la forma esperada por el
servicio web.
Transform XML using an XSLT (Transformar XML mediante una XSLT): aplica una transformación de
XSL al XML del cuerpo de la solicitud o respuesta.
Pasos siguientes
Suscripciones en Azure API Management
Las suscripciones son un concepto importante en Azure API Management. Son la forma más habitual para los
consumidores de obtener acceso a las API publicadas mediante una instancia de API Management. En este
artículo se proporciona información general del concepto.
¿Qué son las suscripciones?

Al publicar las API mediante API Management, es sencillo y frecuente proteger el acceso a ellas mediante claves
de suscripción. Los desarrolladores que necesiten usar las API publicadas deben incluir una clave de suscripción
válida en las solicitudes HTTP al realizar llamadas a esas API. De lo contrario, la puerta de enlace de API
Management rechaza las llamadas inmediatamente. No se reenvían a los servicios back-end.
Para obtener una clave de suscripción para acceder a las API se necesita una suscripción. Una suscripción es
básicamente un contenedor con nombre para un par de claves de suscripción. Los desarrolladores que necesiten
usar las API publicadas pueden obtener suscripciones. Y no necesitan aprobación de los publicadores de API. Los
publicadores de API también pueden crear suscripciones directamente para los consumidores de API.
TIP
API Management también admite otros mecanismos para proteger el acceso a las API, por ejemplo:
OAuth2.0
Certificados de cliente
Lista de direcciones IP permitidas
Ámbito de las suscripciones

Las suscripciones se pueden asociar a diversos ámbitos: producto, todas las API o una API individual.
Suscripciones para un producto
Tradicionalmente, las suscripciones en API Management se han asociado siempre a un solo ámbito del producto
de API. Los desarrolladores encontraron la lista de productos en el Portal para desarrolladores. A continuación,
enviarían las solicitudes de suscripción para los productos que deseaban usar. Una vez aprobada una solicitud de
suscripción, bien de forma automática o por parte de los publicadores de API, el desarrollador puede usar las
claves de esta para acceder a todas las API del producto. Por el momento, el portal para desarrolladores solo
muestra las suscripciones de ámbito de producto de la sección del perfil de usuario.
TIP
En determinadas situaciones, es posible que los publicadores de API deseen publicar un producto de API para el público sin
necesidad de suscripciones. Pueden anular la selección de la opción Require subscription (Requerir suscripción) en la página
Settings (Configuración) del producto en Azure Portal. Como resultado, se puede tener acceso a todas las API del producto
sin una clave de API.
Suscripciones para todas las API o una API individual

Cuando introdujimos el nivel de consumo de API Management, realizamos algunos cambios para optimizar la
administración de claves:
En primer lugar, agregamos dos ámbitos más de suscripción: todas las API y una API individual. El ámbito
de las suscripciones ya no se limita a un producto de API. Ahora es posible crear claves que concedan
acceso a una API (o a todas las API de una instancia de API Management), sin necesidad de crear un
producto y agregar las API a este primero. Además, cada instancia de API Management incluye ahora de
una suscripción inmutable para todas las API. Esta suscripción facilita y agiliza la prueba y la depuración de
las API de la consola de prueba.
En segundo lugar, API Management permite ahora suscripciones independientes. Ya no es necesario que
Suscripciones se asocie a una cuenta de desarrollador. Esta característica es útil en situaciones como, por
ejemplo, cuando varios desarrolladores o equipos comparten una suscripción.
Por último, los publicadores de API ahora pueden crear suscripciones directamente en Azure Portal:
Pasos siguientes
Para más información sobre API Management:
Aprenda otros conceptos en API Management.
Siga nuestros tutoriales para más información sobre API Management.
Consulte nuestra página de preguntas frecuentes para ver las preguntas habituales.
Administración de Azure API Management mediante
Azure Automation
Esta guía presenta el servicio Azure Automation y cómo se puede usar para simplificar la administración de Azure
API Management.
¿Qué es Azure Automation?

Azure Automation es un servicio de Azure para simplificar la administración en la nube mediante la
automatización de procesos. Mediante Azure Automation, se pueden automatizar las tareas de ejecución
prolongada, manuales, propensas a errores y que se repiten para aumentar la confiabilidad, la eficiencia y el valioso
tiempo para su organización.
Azure Automation proporciona un motor de ejecución de flujo de trabajo altamente confiable y de alta
disponibilidad que se adapta para satisfacer sus necesidades. En Azure Automation, los sistemas de terceros
pueden interrumpir los procesos manualmente o en intervalos programados para que las tareas se realicen justo
cuando sea necesario.
Reduzca la sobrecarga operativa y libere al personal de TI/DevOps para concentrarse en el trabajo que
proporciona valor al negocio trasladando las tareas de administración en la nube para que se ejecuten
automáticamente mediante Azure Automation.
¿Cómo puede ayudar Azure Automation a administrar Azure API

Management?
API Management se puede administrar en Azure Automation mediante el uso de cmdlets de Windows PowerShell
para la API de Azure API Management. En Azure Automation, puede escribir scripts de flujo de trabajo de
PowerShell para llevar a cabo muchas de las tareas de API Management con los cmdlets. También puede
emparejar estos cmdlets en Azure Automation con los cmdlets para otros servicios de Azure, para automatizar
tareas complejas a través de los servicios de Azure y sistemas de terceros.
Estos son algunos ejemplos del uso de API Management con PowerShell:
Ejemplos de Azure PowerShell para API Management
Pasos siguientes
Ahora que ha aprendido los aspectos básicos de Azure Automation y cómo se puede usar para administrar Azure
API Management, siga estos vínculos para obtener más información.
Consulte el tutorial de introducción de Azure Automation.
Control de errores en las directivas de API
Management
Azure API Management proporciona un objeto ProxyError que permite a los publicadores responder a las
condiciones de error que se pueden producir durante el procesamiento de solicitudes. Para acceder al objeto
ProxyError se usa la propiedad context.LastError. Este objeto se puede usar en las directivas de la sección de
directivas on-error . En este tema se proporciona una referencia a las funcionalidades de control de errores de
Azure API Management.
Control de errores en API Management

Las directivas de Azure API Management están divididas en las secciones inbound , backend , outbound y
on-error , como se muestra en el ejemplo siguiente.
<policies>
<inbound>

</inbound>
<backend>

</backend>
<outbound>

</outbound>
<on-error>

</on-error>
</policies>
Durante el procesamiento de una solicitud, se ejecutan pasos integrados junto con las directivas que están en el
ámbito de la solicitud. Si se produce un error, el procesamiento salta inmediatamente a la sección de directivas
on-error .
La sección de directivas on-error se puede utilizar en cualquier ámbito. Los publicadores de API pueden
configurar comportamientos predeterminados, como registrar el error en los centros de eventos o crear una nueva
respuesta para devolver al autor de la llamada.
NOTE
La sección on-error no está presente en las directivas de forma predeterminada. Para agregar la sección on-error a una
directiva, vaya a la directiva deseada en el editor de directivas y agréguela. Para más información sobre cómo configurar
directivas, consulte Directivas en API Management.
Si no hay ninguna sección on-error , los autores de la llamada recibirán mensajes de respuesta HTTP 400 o 500 si se
produce una condición de error.
Directivas permitidas en on-error

Las siguientes directivas se pueden usar en la sección de directivas on-error .
choose
set-variable
find-and-replace
return-response
set-header
set-method
set-status
send-request
send-one-way-request
log-to-eventhub
json-to-xml
xml-to-json
lastError
Cuando se produce un error y el control salta a la sección de directivas on-error , el error se almacena en la
propiedad context.LastError a la que pueden acceder las directivas de la sección on-error . LastError tiene las
siguientes propiedades:
NOMBRE TYPE DESCRIPCIÓN OBLIGATORIO
Source string Nombre del elemento donde Sí

se produjo el error. Puede
ser el nombre de una
directiva o el nombre de un
paso de canalización
integrado.
Reason string Código de error reconocible Sin

por la máquina, que se
puede utilizar en el control
de errores.
Message string Descripción del error legible Sí

para el usuario.
Scope string Nombre del ámbito donde Sin

se produjo el error; podría
ser "global", "producto", "api"
u "operación"
Section string Nombre de la sección donde Sin

se produjo el error. Valores
posibles: "inbound",
"backend", "outbound" u
"on-error".
Path string Especifica directivas Sin

anidadas, por ejemplo,
"choose[3]/when[2]".
PolicyId string Valor del atributo id , si lo Sin

especifica el cliente, en la
directiva donde se produjo el
error.
TIP
Se puede acceder al código de estado con context.Response.StatusCode.
NOTE
Todas las directivas tienen un atributo id opcional que se pude agregar al elemento raíz de la directiva. Si este atributo está
presente en una directiva cuando se produce una condición de error, el valor del atributo se puede recuperar mediante la
propiedad context.LastError.PolicyId .
Errores predefinidos para pasos integrados

Los errores siguientes están predefinidos para condiciones de error que se pueden producir durante la evaluación
de pasos de procesamiento integrados.
ORIGEN CONDICIÓN MOTIVO MESSAGE
configuración El identificador URI no OperationNotFound No se puede hacer coincidir

coincide con ninguna API u la solicitud entrante con una
operación. operación.
authorization No se ha proporcionado la SubscriptionKeyNotFound Acceso denegado debido a

clave de suscripción. que falta la clave de
suscripción. Asegúrese de
incluir la clave de la
suscripción al realizar
solicitudes a esta API.
authorization El valor de la clave de SubscriptionKeyInvalid Acceso denegado debido a

suscripción no es válido. una clave de suscripción no
válida. Asegúrese de
proporcionar una clave
válida para una suscripción
activa.
Errores predefinidos en directivas

Los errores siguientes están predefinidos para condiciones de error que se pueden producir durante la evaluación
de directivas.
rate-limit Límite de velocidad excedido RateLimitExceeded Rate limit is exceeded (Se ha

excedido el límite de
velocidad).
quota Cuota superada QuotaExceeded Out of call volume quota.

(Fuera de la cuota de
volumen de la llamada.) La
cuota se reabastecerá en
xx:xx:xx. O bien, Out of
bandwidth quota (Fuera de
la cuota de ancho de banda).
La cuota se reabastecerá en
xx:xx:xx.
jsonp El valor del parámetro de CallbackParameterInvalid Value of callback parameter

devolución de llamada no es {callback-parameter-name} is
válido (contiene caracteres not a valid JavaScript
incorrectos). identifier (El valor del
parámetro de devolución de
llamada {callback-parameter-
name} no es un identificador
de JavaScript válido).
ip-filter No se pudo analizar la IP de FailedToParseCallerIP Failed to establish IP address

autor de llamada de la for the caller. Access denied
solicitud. (No se pudo establecer la
dirección IP del autor de la
llamada. Acceso denegado).
ip-filter La IP del autor de la llamada CallerIpNotAllowed Caller IP address {ip-address}

no está en la lista de is not allowed. Access denied
permitidos. (No se permite la IP del
autor de la llamada {ip-
address}. Acceso denegado).
ip-filter La IP del autor de la llamada CallerIpBlocked Caller IP address is blocked.

está en la lista de Access denied (La IP del
bloqueados. autor de la llamada está
bloqueada. Acceso
denegado).
check-header El encabezado necesario no HeaderNotFound Header {header-name} was

está presente o falta un not found in the request.
valor. Access denied (No se
encontró el encabezado
{header-name} en la
solicitud. Acceso denegado).
check-header El encabezado necesario no HeaderValueNotAllowed Header {header-name} value

está presente o falta un of {header-value} is not
valor. allowed. Access denied (No
se permite el valor {header-
name} del encabezado de
{header-value}. Acceso
denegado).
validate-jwt Falta el token Jwt en la TokenNotFound JWT not found in the

solicitud. request. Access denied (No
se encuentra JWT en la
solicitud. Acceso denegado).
validate-jwt Error de validación de TokenSignatureInvalid <mensaje de la biblioteca de

contraseña. jwt>. Acceso denegado.
validate-jwt Audiencia no válida. TokenAudienceNotAllowed <mensaje de la biblioteca de

jwt>. Acceso denegado.
validate-jwt Emisor no válido TokenIssuerNotAllowed <mensaje de la biblioteca de

validate-jwt Token expirado TokenExpired <mensaje de la biblioteca de

validate-jwt La clave de firma no se TokenSignatureKeyNotFoun <mensaje de la biblioteca de

resolvió por el identificador. d jwt>. Acceso denegado.
validate-jwt Faltan las notificaciones TokenClaimNotFound JWT token is missing the

necesarias del token. following claims (Falta el
token de JWT en las
siguientes notificaciones):
<c1>, <c2>, … Acceso
denegado.
validate-jwt Error de coincidencia de TokenClaimValueNotAllowed Claim {claim-name} value of

valores de notificación. {claim-value} is not allowed.
Acceso denegado.
validate-jwt Otros errores de validación JwtInvalid <mensaje de la biblioteca de

jwt>.
Ejemplo
Establecer una directiva de API en:
<policies>
<inbound>
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<set-header name="ErrorSource" exists-action="override">
<value>@(context.LastError.Source)</value>
</set-header>
<set-header name="ErrorReason" exists-action="override">
<value>@(context.LastError.Reason)</value>
</set-header>
<set-header name="ErrorMessage" exists-action="override">
<value>@(context.LastError.Message)</value>
</set-header>
<set-header name="ErrorScope" exists-action="override">
<value>@(context.LastError.Scope)</value>
</set-header>
<set-header name="ErrorSection" exists-action="override">
<value>@(context.LastError.Section)</value>
</set-header>
<set-header name="ErrorPath" exists-action="override">
<value>@(context.LastError.Path)</value>
</set-header>
<set-header name="ErrorPolicyId" exists-action="override">
<value>@(context.LastError.PolicyId)</value>
</set-header>
<set-header name="ErrorStatusCode" exists-action="override">
<value>@(context.Response.StatusCode.ToString())</value>
</set-header>
<base />
</on-error>
</policies>
y enviar una solicitud no autorizada dará como resultado la respuesta siguiente:
Pasos siguientes
En la Referencia de directivas se muestra una lista completa de declaraciones de directivas y su configuración
Restricciones de importación de API y problemas
conocidos
Acerca de esta lista

Al importar una API, podría encontrarse con algunas restricciones o identificar problemas que es necesario
corregir antes de realizar esta operación. En este artículo se documenta todo esto, organizado por el formato de
importación de la API.
OpenAPI/Swagger
Si recibe errores al importar el documento de OpenAPI, asegúrese de haberlo validado con antelación. Para ello,
use el diseñador en Azure Portal (Diseño - Front-End - OpenAPI Specification Editor [Editor de especificaciones
de OpenAPI]) o con una herramienta de terceros como Swagger Editor.
General
Los parámetros necesarios en la ruta de acceso y en la consulta deben tener nombres únicos. (En OpenAPI,
un nombre de parámetro solo debe ser único dentro de una ubicación; por ejemplo, ruta de acceso, consulta,
encabezado. Pero en API Management se permite que los parámetros tanto de la ruta de acceso como de la
consulta [que OpenAPI no admite] discriminen las operaciones. Por eso es necesario que los nombres de los
parámetros sean únicos en toda la plantilla de la dirección URL ).
Los punteros de $$ref no pueden hacer referencia a archivos externos.
x-ms-paths y x-servers son las únicas extensiones admitidas.
Las extensiones personalizadas se omiten durante la importación y no se guardan ni conservan para la
exportación.
Recursión: API Management no es compatible con definiciones establecidas de forma recursiva (por
ejemplo, esquemas que hacen referencia a sí mismos).
La dirección URL (si está disponible) del archivo de origen se aplica a direcciones URL del servidor relativas.
OpenAPI versión 2
Solo se admite el formato JSON.
OpenAPI versión 3
Si se especifican muchos servidores, API Management tratará de seleccionar la primera dirección URL
HTTPS. Si no hay ninguna dirección URL HTTPS: la primera dirección URL HTTP. Si no hay ninguna
dirección URL HTTP: la dirección URL del servidor estará vacía.
Ejemplos no se admite, pero ejemplo sí.
Multipart/form -data no se admite.
IMPORTANT
Consulte este documento para obtener información importante y consejos relacionados con la importación de OpenAPI.
WSDL
Los archivos WSDL se usan para crear API de paso a través de SOAP y de SOAP a REST.
Enlaces SOAP: solo se admiten los enlaces SOAP cuya codificación es de tipo "documento" o "literal". No se
admiten las codificaciones de estilo "rpc" o SOAP.
WSDL:Import: no se admite este atributo. Los clientes deben combinar las importaciones en un único
documento.
Mensajes con varias partes: en la actualidad no se admiten estos tipos de mensajes.
WCF wsHttpBinding: los servicios SOAP creados con Windows Communication Foundation deben usar
basicHttpBinding. No se admite el uso de wsHttpBinding.
MTOM: los servicios que usan MTOM podrían funcionar. No se ofrece soporte técnico oficial en este
momento.
Recursión: APIM no admite los tipos que se definen de modo recursivo (por ejemplo, hacen referencia a una
matriz formada por ellos mismos).
Varios espacios de nombres: en un esquema se pueden usar varios espacios de nombres, pero el único que
se puede usar para definir las partes del mensaje es el de destino. Los espacios de nombres que se usen para
definir otros elementos de entrada o salidas, y que no sean el destino, no se conservan. Aunque se puede
importar un documento WSDL, en la exportación todas las partes del mensaje tendrá el espacio de nombres
de destino de WSDL.
Matrices: la transformación de SOAP a REST admite solo las matrices encapsuladas que se muestran en el
siguiente ejemplo:
<complexType name="arrayTypeName">
<sequence>
<element name="arrayElementValue" type="arrayElementType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="typeName">
<sequence>
<element name="element1" type="someTypeName" minOccurs="1" maxOccurs="1"/>
<element name="element2" type="someOtherTypeName" minOccurs="0" maxOccurs="1" nillable="true"/>
<element name="arrayElement" type="arrayTypeName" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
WADL
Actualmente, no hay ningún problema de importación conocido de WADL.
Atributos de seguridad para la administración de API
En este artículo describe los atributos de seguridad integrados en API Management.

Un atributo de seguridad es una cualidad o característica de un servicio de Azure que ayuda a dicho servicio a
prevenir y detectar vulnerabilidades de seguridad, así como a responder a ellas.
Los atributos de seguridad se clasifican en las siguientes categorías:
Prevención
Segmentación de red
Detección
Compatibilidad con la administración de identidades y acceso (IAM )
Pista de auditoría
Controles de acceso (si se utilizan)
Administración de la configuración (si se utiliza)
En todas las categorías, especificamos si el atributo se utiliza o no (sí/no). En posible que, en algunos servicios, haya
atributos que no sean aplicables, lo que se indica con N/A. También puede incluirse una nota o un vínculo para
aportar más información sobre un atributo.
Prevención
ATRIBUTO DE SEGURIDAD SÍ/NO NOTAS
Cifrado en reposo: Sí (solo para el cifrado del servicio) Los datos confidenciales, como
Cifrado del servidor certificados, claves y valores con
Cifrado del servidor con claves nombre secreto se cifran con
administradas por el cliente administradas del servicio, por las claves
Otras características de cifrado de la instancia de servicio.
(por ejemplo, del cliente, siempre
cifrado, etc.)
Cifrado en tránsito: Sí Expressroute y proporciona el cifrado de

Cifrado de ExpressRoute red virtual por redes de Azure.
En el cifrado de red virtual
Cifrado de red virtual a red
virtual
Control de claves de cifrado (CMK, No Todas las claves de cifrado son por
BYOK, etcetera.) instancia de servicio y servicio
administrado.
Cifrado de nivel de columna (Azure Data N/D

Services)
Llamadas a API cifradas Sí Las llamadas de plano de administración

se realizan a través de Azure Resource
Manager a través de TLS. Se requiere un
token web de JSON (JWT) válido. Las
llamadas de plano de datos pueden
estar protegidas con TLS y uno de los
mecanismos de autenticación admitidos
(por ejemplo, el certificado de cliente o
JWT).
Segmentación de red
Compatibilidad de punto de conexión No

de servicio
Compatibilidad con inserción de redes Sí

virtuales
Aislamiento de red y la compatibilidad Sí Uso de grupos de seguridad de red

con Firewall (NSG) y Azure Application Gateway (u
otro dispositivo de software),
respectivamente.
Fuerza la tunelización de soporte Sí Las redes de Azure proporcionan la

técnico tunelización forzada.
Detección
Supervisión de soporte técnico (Log Sí

analytics, Application insights, etcetera)
de Azure
Administración de identidades y acceso

Authentication Sí
Autorización Sí
Pista de auditoría
Auditoría y registro del plano de control Sí Registros de actividad de Azure Monitor

y administración
Auditoría y registro del plano de datos Sí Registros de diagnóstico de Azure

Monitor y (opcionalmente) Azure
Application Insights.
Administración de configuración
Compatibilidad con la administración de Sí Mediante el Kit de recursos de DevOps

configuración (control de versiones de de Azure API Management
configuración, etcetera.)
Exámenes de vulnerabilidades de falsos positivos

Esta sección documentan las vulnerabilidades más comunes, que no afectan a la administración de API de Azure.
VULNERABILIDAD DESCRIPCIÓN
Ticketbleed (CVE-2016-9244) Ticketbleed es una vulnerabilidad en la implementación de la

extensión TLS SessionTicket que se encuentra en algunos
productos de F5. Permite la pérdida ("hemorragia") de hasta
31 bytes de datos de la memoria sin inicializar. Esto se debe a
la pila TLS, relleno de un identificador de sesión que se pasa
desde el cliente, con los datos para que sea una longitud de
32 bits.
Adición manual de una API
En los pasos de este artículo se explica cómo usar Azure Portal para agregar manualmente una API a la instancia
de API Management (APIM ). Un escenario común es si quiere crear una API en blanco y definirla manualmente
cuando desee simular la API. Para obtener más información sobre la simulación de una API, consulte el artículo
sobre cómo simular respuestas de API.
Si desea importar una API existente, consulte la sección de temas relacionados.
En este artículo, creará una API en blanco y especificará httpbin.org (un servicio de prueba público) como API de
back-end.
Requisitos previos
Complete el siguiente inicio rápido: Creación de una instancia de Azure API Management

TIP
Creación de una API

2. En el menú izquierdo, seleccione + Agregar API.
3. Seleccione API en blanco en la lista.
4. Escriba la configuración de la API.
NOMBRE VALOR DESCRIPCIÓN
Nombre para mostrar "API en blanco" El nombre se muestra en el Portal

Dirección URL de servicio web "https://httpbin.org" Si desea simular una API,

(opcional) recomendamos no escribir nada.
En este caso, escribimos
https://httpbin.org. Se trata de un
servicio de prueba público.
Si desea importar una API que se
asigne automáticamente a un back-
end, consulte uno de los temas de la
sección de temas relacionados.
Esquema URL "HTTPS" En este caso, aunque el back-end

tenga acceso HTTP no seguro,
especifique un acceso HTTPS de
APIM seguro al back-end.
Este tipo de escenario (HTTPS a
HTTP) se denomina "terminación
HTTPS". Podría hacerlo si su API se
encuentra dentro de una red virtual
(donde sabe que el acceso está
protegido aunque no se utilice
HTTPS).
Puede usar la terminación HTTPS
para ahorrar algunos ciclos de CPU.
Sufijo de dirección URL "hbin" El sufijo es un nombre que identifica

esta API concreta en esta instancia de
APIM. Debe ser exclusivo en esta
instancia de APIM.
NOMBRE VALOR DESCRIPCIÓN
Productos "Sin límite" Publique la API asociándola a un

producto. Si desea que la API se
publique y esté disponible para los
desarrolladores, agréguela a un
producto. Puede hacerlo durante la
creación de la API o configurarla más
adelante.
Los productos son asociaciones de

una o varias API. Puede incluir varias
API y ofrecerlas a los desarrolladores
desarrolladores.
En primer lugar, los desarrolladores
deben suscribirse a un producto para
acceder a la API. Al suscribirse,
obtienen una clave de suscripción
que funciona con cualquier API de
ese producto. Si creó la instancia de
APIM, ya es un administrador, así
que, de forma predeterminada, está
suscrito a todos los productos.

instancia de API Management incluye
dos productos de ejemplo: Starter y
Unlimited.
En este momento, no tiene ninguna operación en APIM que se asigne a las operaciones en la API de back-end. Si
se llama a una operación que se expone a través del back-end, pero no a través de la APIM, obtendrá una
respuesta 404.
NOTE
De forma predeterminada, cuando agrega una API, aunque esté conectado a algún servicio back-end, APIM no expondrá
ninguna operación hasta que incorpore a la lista blanca. Para incluir en la lista blanca una operación del servicio de back-end,
cree una operación de APIM que se asigne a la operación de back-end.
Adición y prueba de una operación

En esta sección se muestra cómo agregar una operación "/get" para asignarla a la operación de back-end
"http://httpbin.org/get".
Agregar una operación
3. En la URL, seleccione GET y escriba "/get" en el recurso.
4. Escriba "FetchData" en Nombre para mostrar.
5. Seleccione Guardar.
Probar una operación
Pruebe la operación en Azure Portal. También puede probarla en el Portal para desarrolladores.
2. Seleccione FetchData.
3. Presione Enviar.
Se muestra la respuesta que genera la operación "http://httpbin.org/get". Si desea transformar las operaciones,
consulte Transformación y protección de una API.
Adición y prueba de una operación con parámetros

En esta sección se explica cómo agregar una operación que toma un parámetro. En este caso, se asigna la
operación a "http://httpbin.org/status/200".
Adición de la operación
1. Seleccione API que creó en los pasos anteriores.
3. En la URL, seleccione GET y escriba "/status/{code}" en el recurso. Si lo desea, puede proporcionar cierta
información asociada a este parámetro. Por ejemplo, escriba "Número" en TYPE y "200" (valor
predeterminado) en VALUES.
4. Escriba "GetStatus" en Nombre para mostrar.
Prueba de la operación
Pruebe la operación en Azure Portal. También puede probarla en el Portal para desarrolladores.
2. Seleccione GetStatus. De forma predeterminada, el valor de código se establece en "200". Puede cambiarlo
para probar otros valores. Por ejemplo, escriba "418".
3. Presione Enviar.
Se muestra la respuesta que genera la operación "http://httpbin.org/status/200". Si desea transformar las
operaciones, consulte Transformación y protección de una API.
Anexión de otras API

Una API puede constar de varias API expuestas por diferentes servicios, entre las que se incluyen la especificación
OpenAPI, una API de SOAP, la característica API Apps de Azure App Service, Azure Function App, Azure Logic
Apps y Azure Service Fabric.
Para anexar una API diferente a la API existente, complete los pasos siguientes. Al importar otra API, las
operaciones se anexan a la API actual.
1. Vaya a la instancia de Azure API Management en Azure Portal.
2. Seleccione API del menú de la izquierda.
3. Haga clic en ... junto a la API a la que desea anexar otra API.
4. Seleccione Importar en el menú desplegable.
5. Seleccione un servicio desde el que se va a importar una API.
Temas relacionados
Limitaciones de importación de API
Importación de una aplicación de Azure Function App
Importación de una aplicación lógica de Azure.
Importación de un servicio Service Fabric
Edición de una API
Pasos siguientes
En este artículo se explica cómo importar una API de back-end de Especificación OpenAPI que reside en
https://conferenceapi.azurewebsites.net?format=json. Esta API de back-end la proporciona Microsoft y se
hospeda en Azure. El artículo también muestra cómo probar la API de APIM.
IMPORTANT
Consulte este documento para obtener información importante y consejos relacionados con la importación de OpenAPI.
En este artículo, aprenderá a:

Importación de una API de back-end de la especificación OpenAPI
Requisitos previos

TIP

2. Seleccione Especificación OpenAPI de la lista Add a new API (Agregar una nueva API).
3. Especifique la configuración adecuada. Puede establecer los valores de API durante la creación. Como
alternativa, puede establecer algunos de ellos más adelante accediendo a la pestaña Configuración.
Si presiona Tab, algunos de los campos, o todos, se rellenan con la información del servicio de back-end
especificado.
Especificación OpenAPI https://conferenceapi.azurewebsites.n Hace referencia al servicio que

et?format=json implementa la API. API Management
envía las solicitudes a esta dirección.
Nombre para mostrar API de conferencia de demostración Si presiona la tecla Tab después de
(API de conferencia de demostración) escribir la dirección URL del servicio,
JSON.
El nombre se muestra en el Portal
Nombre demo-conference-api Proporciona un nombre único para la

API.
Si presiona la tecla Tab después de
escribir la dirección URL del servicio,
JSON.
Descripción Proporcione una descripción opcional Si presiona la tecla Tab después de

de la API. escribir la dirección URL del servicio,
JSON.
Sufijo de dirección URL de API conference El sufijo se anexa a la dirección URL

base del servicio API Management.
API Management distingue las API
por su sufijo, por lo que el sufijo
debe ser único para cada API de un
publicador determinado.
Esquema URL HTTPS Determina los protocolos que se

pueden usar para acceder a la API.
Productos Sin límite Publique la API asociándola a un

producto. Para agregar,
opcionalmente, esta nueva API a un
producto, escriba el nombre del
producto. Este paso se puede repetir
varias veces para agregar la API a
varios productos.
Los productos son asociaciones de
una o varias API. Puede incluir varias
API y ofrecerlas a los desarrolladores
desarrolladores. En primer lugar, los
desarrolladores deben suscribirse a
un producto para acceder a la API. Al
suscribirse, obtienen una clave de
suscripción que funciona con
cualquier API de ese producto. Si
creó la instancia de APIM, ya es un
administrador, así que, de forma
predeterminada, está suscrito a
todos los productos.
instancia de API Management
incluye dos productos de ejemplo:
Starter y Unlimited.
NOTE
Las limitaciones de la importación de API se documentan en otro artículo.

Se puede llamar a las operaciones directamente desde Azure Portal, lo que proporciona una forma cómoda de ver
y probar las operaciones de una API.

3. Haga clic en GetSpeakers.
La página muestra los campos de los parámetros de consulta, pero, en este caso, no tiene ninguno. La
página también muestra los campos de los encabezados. Uno de los encabezados es "Ocp-Apim-
Suscripción-Key", para la clave de suscripción del producto que está asociado a esta API. Si ha creado la
instancia APIM, ya es administrador, por lo que la clave se rellena automáticamente.
4. Presione Enviar.

También se pueden llamar a las operaciones desde portal para desarrolladores para probar las API.
1. Seleccione la API que creó en el paso "Importación y publicación de una API de back-end".
2. Presione Portal para desarrolladores.
Se abre el sitio "Portal para desarrolladores".

3. Seleccione API.
5. Haga clic en GetSpeakers.
La página muestra los campos de los parámetros de consulta, pero, en este caso, no tiene ninguno. La
página también muestra los campos de los encabezados. Uno de los encabezados es "Ocp-Apim-
Suscripción-Key", para la clave de suscripción del producto que está asociado a esta API. Si ha creado la
instancia APIM, ya es administrador, por lo que la clave se rellena automáticamente.
7. Presione Enviar.
Después de invocar una operación, el portal para desarrolladores mostrará el estado de respuesta, los
encabezados de respuesta y el contenido de respuesta.

Temas relacionados
Edición de una API
Pasos siguientes
Este artículo explica cómo importar una representación XML estándar de una API de SOAP. El artículo también
muestra cómo probar la API de APIM.
Requisitos previos

TIP

2. Seleccione WSDL en la lista Add a new API (Agregar una nueva API).
3. En la especificación WSDL, escriba la dirección URL donde reside la API de SOAP.

4. El botón de radio Paso a través de SOAP está seleccionado de forma predeterminada. Con esta selección,
la API se va a exponer como SOAP. El consumidor tiene que utilizar reglas SOAP. Si desea usar Restify en
la API, siga los pasos descritos en Import a SOAP API and convert it to REST (Importación de una API de
SOAP y conversión a REST).
5. Presione Tab.
Los siguientes campos se rellenan con la información de la API de SOAP: Nombre para mostrar, Nombre y
Descripción.
6. Agregue un sufijo URL de API. El sufijo es un nombre que identifica esta API concreta en esta instancia de
APIM. Debe ser exclusivo en esta instancia de APIM.
7. Publique la API asociándola a un producto. En este caso, se usa el producto "Unlimited". Si desea que la
API se publique y esté disponible para los desarrolladores, agréguela a un producto. Puede hacerlo
durante la creación de la API o configurarla más adelante.
Los productos son asociaciones de una o varias API. Puede incluir varias API y ofrecerlas a los
desarrolladores mediante el portal para desarrolladores. En primer lugar, los desarrolladores deben
suscribirse a un producto para acceder a la API. Al suscribirse, obtienen una clave de suscripción que
funciona con cualquier API de ese producto. Si creó la instancia de APIM, ya es un administrador, así que,
de forma predeterminada, está suscrito a todos los productos.
De forma predeterminada, cada instancia de API Management incluye dos productos de ejemplo:
Starter
Sin límite
Prueba de la nueva API de APIM en el portal de administración
Se puede llamar a las operaciones directamente desde el portal administrativo para desarrolladores, lo que
proporciona una forma cómoda de ver y probar las operaciones de una API.
3. Seleccione alguna operación.
La página muestra los campos de parámetros de consulta y los campos para los encabezados. Uno de los
encabezados es "Ocp-Apim-Suscripción-Key", para la clave de suscripción del producto que está asociado
a esta API. Si ha creado la instancia APIM, ya es administrador, por lo que la clave se rellena
automáticamente.
4. Presione Enviar.
3. Seleccione la API que ha creado.
4. Haga clic en la operación que desea probar.
6. Presione Enviar.

Temas relacionados
Edición de una API
Pasos siguientes
Este artículo muestra cómo importar una API de SOAP y convertirla en REST. El artículo también muestra cómo
probar la API de APIM.
Requisitos previos

TIP

2. Seleccione WSDL en la lista Add a new API (Agregar una nueva API).
3. En la especificación WSDL, escriba la dirección URL donde reside la API de SOAP.

4. Haga clic en el botón de radio De SOAP a REST. Cuando se hace clic en esta opción, APIM trata de
realizar una transformación automática entre XML y JSON. En este caso, los consumidores deben llamar
a la API como API RESTful, que devuelve JSON. APIM convierte cada solicitud en una llamada SOAP.
5. Presione Tab.
Los siguientes campos se rellenan con la información de la API de SOAP: Nombre para mostrar, Nombre
y Descripción.
Starter
Sin límite

automáticamente.
4. Presione Enviar.

6. Presione Enviar.

Una API puede constar de varias API expuestas por diferentes servicios, entre las que se incluyen la
especificación OpenAPI, una API de SOAP, la característica API Apps de Azure App Service, Azure Function App,
Azure Logic Apps y Azure Service Fabric.
Temas relacionados
Edición de una API
Pasos siguientes
Importación de una aplicación de API como API
Este artículo muestra cómo importar una aplicación de API como una API. El artículo también muestra cómo
Importación de una aplicación de API como API
Requisitos previos
Completar la guía de inicio rápido siguiente: Creación de una instancia de Azure API Management
Asegúrese de que hay una aplicación de API en su suscripción. Para más información, consulte la
Documentación de App Service.

TIP

2. Seleccione Aplicación de API en la lista Add a new API (Agregar una nueva API).
3. Presione Examinar para ver la lista de aplicaciones API Apps en su suscripción.

4. Seleccione la aplicación. APIM busca el swagger asociado a la aplicación seleccionada, lo captura y lo
importa.
En caso de que APIM no encuentre el swagger, expone la API como una API de "acceso directo".
Starter
Sin límite

automáticamente.
4. Presione Enviar.

6. Presione Enviar.

Temas relacionados
Edición de una API
Pasos siguientes
Importación de una instancia de Azure Function App
como API en Azure API Management
Azure API Management admite la importación de instancias de Azure Function App como API nuevas o su
anexión a las API existentes. El proceso genera automáticamente una clave de host en Azure Function App que,
después, se asigna a un valor con nombre en Azure API Management.
En este artículo se explica cómo importar una instancia de Azure Function App como API en Azure API
Management. También se describe el proceso de realización de pruebas.
Aprenderá a:
Importar una instancia de Azure Function App como una API
Anexar una instancia de Azure Function App a una API
Ver la nueva clave de host de Azure Function App y el valor con nombre de Azure API Management
Prueba de la API en el portal para desarrolladores
Requisitos previos
Complete la guía de inicio rápido Creación de una instancia de Azure API Management.
Asegúrese de que tiene una aplicación de Azure Functions en la suscripción. Para más información, consulte
Creación de una instancia de Azure Function App. Debe contener funciones con desencadenador HTTP y la
configuración del nivel de autorización debe establecerse en Anónimo o Función.

TIP
Importación de una instancia de Azure Function App como una API

nueva
Siga estos pasos para crear una API desde una instancia de Azure Function App.
1. En la instancia del servicio Azure API Management, seleccione API en el menú de la izquierda.
2. En la lista Add a new API (Agregar una nueva API), seleccione Function App.
3. Haga clic en Examinar para seleccionar las funciones que se van a importar.
4. Haga clic en la sección Function App para elegir en la lista de instancias de Function App.
5. Busque la instancia de Function App de la que desea importar funciones, haga clic en ella y presione
Seleccionar.
6. Seleccione las funciones que desea importar y haga clic en Seleccionar.
NOTE
Solo se pueden importar funciones que se basen en desencadenador HTTP y que tengan la configuración del nivel
de autorización establecida en Anónimo o Función.
7. Cambie a la vista Completa y asigne el Producto a la nueva API. Si es necesario, edite otros campos que
se rellenan automáticamente.
8. Haga clic en Create(Crear).
Anexión de una instancia de Azure Function App a una API existente

Siga estos pasos para anexar Azure Function App a una API existente.
1. En la instancia del servicio Azure API Management, seleccione API en el menú de la izquierda.
2. Elija una API que desea importar en una instancia de Azure Function App. Haga clic en ... y seleccione
Importar en el menú contextual.
3. Haga clic en el icono Function App.

4. En la ventana emergente, haga clic en Examinar.
5. Haga clic en la sección Function App para elegir en la lista de instancias de Function App.
6. Busque la instancia de Function App de la que desea importar funciones, haga clic en ella y presione
Seleccionar.
7. Seleccione las funciones que desea importar y haga clic en Seleccionar.
8. Haga clic en Import.
Autorización
La importación de una instancia de Azure Function App genera automáticamente:
una clave de host en la aplicación de función con el nombre apim-{nombre de instancia del servicio Azure API
Management}.
un valor con nombre dentro de la instancia de Azure API Management con el nombre {nombre de la instancia
de Azure Function App}-key, que contiene la clave de host creada.
En el caso de las API creadas después del 4 de abril de 2019, la clave de host se pasa en las solicitudes HTTP
desde API Management a la aplicación de función en un encabezado. Las API más antiguas pasan la clave de
host como un parámetro de consulta. Se puede cambiar este comportamiento mediante la PATCH Backend
llamada API REST en la entidad de back-end asociada con la aplicación de función.
WARNING
Si se quita o se cambia el valor de la clave de host de Azure Function App o el valor con nombre de Azure API
Management, se interrumpirá la comunicación entre los servicios. Los valores no se sincronizan automáticamente.
Si necesita rotar la clave de host, asegúrese de que también se modifica el valor con nombre de Azure API Management.
Acceso a la clave de host de Azure Function App

1. Vaya a la instancia de Azure Function App.
2. Seleccione Configuración de Function App en la información general.
3. La clave se encuentra en la sección Host Keys (Claves de host).
Acceso al valor con nombre en Azure API Management

Vaya a la instancia de Azure API Management y seleccione Valores con nombre en el menú de la izquierda. La
clave de Azure Function App se almacena ahí.
Prueba de la nueva API Management en Azure Portal
Puede llamar a operaciones directamente desde Azure Portal. Mediante Azure Portal es una manera cómoda de
1. Seleccione la API que ha creado en la sección anterior.
3. Seleccione una operación.
encabezados es Ocp-Apim -Suscripción-Key para la clave de suscripción del producto que está asociado
a esta API. Si ha creado la instancia de API Management, significa que ya es administrador, por lo que la
clave se rellena automáticamente.
4. Seleccione Enviar.
El back-end responde con 200 Aceptar y algunos datos.

También puede llamar a las operaciones desde el portal para desarrolladores para probar las API.
1. Seleccione la API que ha creado en el paso Importación y publicación de una API de back-end.
2. Seleccione Portal para desarrolladores.
Se abre el sitio del portal para desarrolladores.
4. Seleccione la operación que desea probar.
5. Seleccione Pruébelo.
6. Seleccione Enviar.
Temas relacionados
Edición de una API
Pasos siguientes
Importación de una aplicación lógica como API
Este artículo muestra cómo importar una aplicación lógica como una API. El artículo también muestra cómo
Importación de una aplicación lógica como API
Requisitos previos
Asegúrese de que hay alguna aplicación lógica en su suscripción que expone un punto de conexión HTTP.
Para más información, consulte el artículo acerca del desencadenamiento de flujos de trabajo con puntos de
conexión HTTP

TIP

2. Seleccione Aplicación lógica en la lista Add a new API (Agregar una nueva API).
3. Presione Examinar para ver la lista de aplicaciones Logic Apps a las que se puede llamar en su
suscripción.
4. Seleccione la aplicación. APIM busca el swagger asociado a la aplicación seleccionada, lo captura y lo
importa.
Starter
Sin límite

automáticamente.
4. Presione Enviar.

6. Presione Enviar.

NOTE
Cada aplicación lógica tiene una operación manual-invoke. Si desea que la API contenga varias aplicaciones lógicas, para
que no tenga colisión, debe cambiar el nombre de la función.
Temas relacionados
Edición de una API
Pasos siguientes
Integrar API Management con Service Fabric en
Azure
La implementación de Azure API Management con Service Fabric es un escenario avanzado. API Management es
útil cuando es necesario publicar API con un completo conjunto de reglas de enrutamiento para los servicios de
Service Fabric de back-end. Las aplicaciones en la nube normalmente necesitan una puerta de enlace front-end
para proporcionar un único punto de entrada para usuarios, dispositivos u otras aplicaciones. En Service Fabric, una
puerta de enlace puede ser cualquier servicio sin estado diseñado para la entrada de tráfico, como una aplicación
ASP.NET Core, Event Hubs, IoT Hub o Azure API Management.
En este artículo se muestra cómo configurar Azure API Management con Service Fabric para enrutar el tráfico a un
servicio de back-end de Service Fabric. Cuando haya terminado, habrá implementado API Management en una red
virtual y configurado una operación de API para enviar tráfico a servicios sin estado de back-end. Para más
información sobre escenarios de Azure API Management con Service Fabric, consulte el artículo de introducción.
NOTE
Disponibilidad
IMPORTANT
Esta característica ya está disponible en los niveles Premium y Developer de API Management debido a la compatibilidad
requerida con redes virtuales.
Requisitos previos
Antes de empezar:
Si no tiene ninguna suscripción a Azure, cree una cuenta gratuita
Instale Azure Powershell o la CLI de Azure.
Cree un clúster de Windows en un grupo de seguridad de red.
Si implementa un clúster de Windows, configure un entorno de desarrollo de Windows. Instale
Visual Studio 2019 y las cargas de trabajo de desarrollo Azure, desarrollo web y ASP.NET y desarrollo a
través de plataformas .NET Core. Después, configure un entorno de desarrollo .NET.
Topología de red
Ahora que tiene un clúster de Windows seguro en Azure, implemente API Management en la red virtual (VNET),
en la subred y en el grupo de seguridad de red diseñados para API Management. En este artículo la plantilla de
Resource Manager para API Management está preconfigurada para usar los nombres de la red virtual, la subred y
el grupo de seguridad de red que configuró en el tutorial del clúster de Windows. Asimismo, este artículo
implementa la siguiente topología en Azure, donde API Management y Service Fabric están en subredes de la
misma red virtual:
Inicio de sesión en Azure y selección de la suscripción

Inicie sesión en su cuenta de Azure y seleccione su suscripción antes de ejecutar comandos de Azure.
Connect-AzAccount
Get-AzSubscription
Set-AzContext -SubscriptionId <guid>
az login
az account set --subscription <guid>
Implementación de un servicio de back-end de Service Fabric

Antes de configurar API Management para enrutar el tráfico a un servicio back-end de Service Fabric, primero
necesita un servicio en ejecución que acepte solicitudes.
Cree un servicio básico y confiable de ASP.NET Core sin estado, con la plantilla de proyecto de Web API
predeterminada. Así se crea un punto de conexión HTTP para el servicio que se expone en Azure API Management.
Inicie Visual Studio como administrador y cree un servicio ASP.NET Core:
1. En Visual Studio, seleccione Archivo -> Nuevo proyecto.
2. En Nube, seleccione la plantilla de aplicación de Service Fabric y asígnele el nombre "ApiApplication" .
3. Seleccione la plantilla de servicio de ASP.NET Core sin estado y denomine al proyecto "WebApiService" .
4. Seleccione la plantilla de proyecto de ASP.NET Core 2.0 de API web.
5. Una vez creado el proyecto, abra PackageRoot\ServiceManifest.xml y quite los atributos Port de la
configuración del recurso de punto de conexión:
<Resources>
<Endpoints>
<Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" />
</Endpoints>
</Resources>
Al quitar el puerto permite que Service Fabric especificar un puerto dinámicamente desde el intervalo de
puertos de aplicación, puede abrir a través del grupo de seguridad de red en la plantilla de Cluster Resource
Manager, permitiendo el tráfico fluya a él desde API Management.
6. Presione F5 en Visual Studio para comprobar que la API web está disponible de manera local.
Abra Service Fabric Explorer y vaya a una instancia específica del servicio ASP.NET Core para ver la
dirección base donde escucha el servicio. Agregue /api/values a la dirección base y ábralo en un
explorador. Esto invoca el método Get en ValuesController en la plantilla de Web API. Devuelve la respuesta
predeterminada de la plantilla, una matriz JSON con dos cadenas:
["value1", "value2"]`
Este es el punto de conexión que debe exponer a través de API Management en Azure.
7. Por último, implemente la aplicación en el clúster en Azure. In Visual Studio, haga clic con el botón derecho
en el proyecto de la aplicación y seleccione Publicar. Proporcione el punto de conexión del clúster (por
ejemplo, mycluster.southcentralus.cloudapp.azure.com:19000 ) para implementar la aplicación en el clúster de
Service Fabric en Azure.
En el clúster de Service Fabric en Azure ahora se ejecutará un servicio sin estado ASP.NET Core denominado
fabric:/ApiApplication/WebApiService .
Descarga e información de las plantillas de Resource Manager

Descargue y guarde las plantillas de Resource Manager y el archivo de parámetros siguientes:
network-apim.json
network-apim.parameters.json
apim.json
apim.parameters.json
La plantilla network-apim.json implementa un nuevo grupo de seguridad de red y una nueva subred en la red
virtual donde se implementa el clúster de Service Fabric.
En las siguientes secciones se describen los recursos que se definen mediante la plantilla apim.json. Para más
información, siga los vínculos a la documentación de referencia de plantilla dentro de cada sección. Los parámetros
configurables que se definen en el archivo de parámetros apim.parameters.json se establecen más adelante en este
artículo.
Microsoft.ApiManagement/service
Microsoft.ApiManagement/service describe la instancia de servicio de API Management: nombre, SKU o nivel,
ubicación del grupo de recursos, información del editor y red virtual.
Microsoft.ApiManagement/service/certificates
Microsoft.ApiManagement/service/certificates configura la seguridad de API Management. API Management debe
autenticarse con el clúster de Service Fabric para la detección de servicios mediante un certificado de cliente con
acceso al clúster. En este artículo se usa el mismo certificado que se especificó anteriormente al crear el clúster de
Windows que, de forma predeterminada, se puede usar para tener acceso al clúster.
En este artículo se usa el mismo certificado para la autenticación de cliente y la seguridad de nodo a nodo del
clúster. Puede utilizar otro certificado de cliente si tiene uno configurado para acceder al clúster de Service Fabric.
Rellene los campos name, password y data (cadena codificada en base-64) del archivo de clave privada (.pfx) del
certificado del clúster que especificó al crear el clúster de Service Fabric.
Microsoft.ApiManagement/service/backends
Microsoft.ApiManagement/service/backends describe el servicio back-end al que se reenvía el tráfico.
En los servidores back-end de Service Fabric, su clúster sirve de back-end, en lugar de usar un servicio de Service
Fabric específico. Esto permite que una única directiva enrute a más de un servicio del clúster. Aquí el campo url es
el nombre completo de un servicio del clúster al que se enrutan todas las solicitudes de forma predeterminada si
no se especifica ningún nombre de servicio en una directiva de back-end. Puede usar un nombre de servicio falso,
como "fabric:/fake/service" si no desea un servicio de reserva. resourceId especifica el punto de conexión de
administración del clúster. clientCertificateThumbprint y serverCertificateThumbprints identifican los
certificados usados para autenticarse con el clúster.
Microsoft.ApiManagement/service/products
Microsoft.ApiManagement/service/products crea un producto. En Azure API Management, un producto contiene
una o varias API, así como una cuota de uso y los términos de uso. Una vez publicado un producto, los
desarrolladores pueden suscribirse al producto y comenzar a usar las API del producto.
Rellene el campo displayName con un valor descriptivo y el campo description del producto. En este artículo, se
necesita una suscripción, pero no es necesario que la apruebe un administrador. El valor de state de este producto
es "publicado" y es visible para los suscriptores.
Microsoft.ApiManagement/service/apis
Microsoft.ApiManagement/service/apis crea una API. En API Management, una API representa un conjunto de
operaciones que puede invocarse por las aplicaciones cliente. Una vez agregadas las operaciones, la API se agrega
a un producto y se puede publicar. Una vez publicada una API, pueden usarla y suscribirse a ella los
desarrolladores.
displayName puede ser cualquier nombre para la API. En este artículo usará "Service Fabric App".
name proporciona un nombre único y descriptivo para la API, como "aplicación de service fabric". Se muestra
en el portal para desarrolladores y en el portal del publicador.
serviceUrl hace referencia al servicio HTTP que implementa la API. API Management envía las solicitudes a
esta dirección. En servidores back-end de Service Fabric, este valor de dirección URL no se usa. Puede escribir
aquí cualquier valor. Este artículo, por ejemplo "http://servicefabric".
path se anexa a la dirección URL base del servicio API Management. La dirección URL base es común para
todas las API hospedadas en una instancia del servicio API Management. API Management distingue las API
por su sufijo, por lo que el sufijo debe ser único para cada API de un publicador determinado.
El campo protocols determina los protocolos que se pueden usar para acceder a la API. En este artículo, se
muestran http y https.
path es un sufijo de la API. En este artículo deberá usar "myapp".
Microsoft.ApiManagement/service/apis/operations
Microsoft.ApiManagement/service/apis/operations: antes de usar una API de API Management, se deben agregar
operaciones a la API. Los clientes externos usan una operación para comunicarse con el servicio sin estado de
ASP.NET Core que se ejecuta en el clúster de Service Fabric.
Para agregar una operación de API de front-end, rellene los valores:
displayName y description describen la operación. En este artículo deberá usar "Values".
method especifica el verbo HTTP. En este artículo deberá especificar GET.
urlTemplate se anexa a la dirección URL base de la API e identifica una única operación HTTP. En este artículo
deberá usar /api/values si agregó el servicio back-end de .NET, o getMessage si agregó el servicio back-end de
Java. De forma predeterminada, la ruta de acceso URL que se especifica aquí se envía al servicio de back-end de
Service Fabric. Si usa aquí la misma ruta de acceso URL que usa el servicio, como "/api/values", la operación
funciona sin más modificaciones. También puede especificar aquí una ruta de acceso URL distinta de la que usa
el servicio de back-end de Service Fabric, en cuyo caso también debe especificar después una ruta de acceso de
reescritura en la directiva de la operación.
Microsoft.ApiManagement/service/apis/policies
Microsoft.ApiManagement/service/apis/policies crea una directiva de back-end, que vincula todos los elementos.
Es donde se configura el servicio de back-end de Service Fabric al que se enrutan las solicitudes. Puede aplicar esta
directiva a cualquier operación de API. Para más información, consulte Introducción a las directivas.
La configuración de back-end de Service Fabric proporciona los controles de enrutamiento de solicitudes
siguientes:
Selección de instancias de servicio mediante la especificación de un nombre de instancia de servicio de Service
Fabric, ya sea codificado de forma rígida (por ejemplo, "fabric:/myapp/myservice" ) o generado a partir de la
solicitud HTTP (por ejemplo, "fabric:/myapp/users/" + context.Request.MatchedParameters["name"] ).
Resolución de la partición mediante la generación de una clave de partición a partir de cualquier esquema de
partición de Service Fabric.
Selección de réplicas para los servicios con estado.
Condiciones de reintento de resolución que permiten especificar las condiciones para volver a resolver una
ubicación de servicio y volver a enviar una solicitud.
policyContent es el contenido XML con escape JSON de la directiva. En este artículo deberá crear una directiva de
back-end que enrute las solicitudes directamente al servicio sin estado .NET o Java implementado anteriormente.
Agregue una directiva set-backend-service bajo las directivas de entrada. Reemplace el valor de sf-service-instance-
name por fabric:/ApiApplication/WebApiService , si anteriormente implementó el servicio back-end de .NET, o por
fabric:/EchoServerApplication/EchoServerService , si implementó el servicio Java. backend -id hace referencia a un
recurso de back-end, en este caso el recurso Microsoft.ApiManagement/service/backends definido en la plantilla
apim.json. backend -id también puede hacer referencia a otro recurso de back-end creado mediante las API de API
Management. En este artículo deberá establecer backend -id en el valor del parámetro
service_fabric_backend_name.
<policies>
<inbound>
<base/>
<set-backend-service
backend-id="servicefabric"
sf-service-instance-name="service-name"
sf-resolve-condition="@(context.LastError?.Reason == "BackendConnectionFailure")" />
</inbound>
<backend>
<base/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Para obtener un conjunto completo de los atributos de directiva de back-end de Service Fabric, consulte la
documentación de back-end de API Management
Definición de los parámetros e implementación de API Management
Rellene los siguientes parámetros vacíos en apim.parameters.json para la implementación.
. VALOR
apimInstanceName sf-apim
apimPublisherEmail [email protected]
apimSku Developer
serviceFabricCertificateName sfclustertutorialgroup320171031144217
certificatePassword q6D7nN%6ck@6
serviceFabricCertificateThumbprint C4C1E541AD512B8065280292A8BA6079C3F26F10
serviceFabricCertificate <cadena codificada en base 64>
url_path /api/values
clusterHttpManagementEndpoint https://mysfcluster.southcentralus.cloudapp.azure.com:19080
inbound_policy <Cadena XML>
certificatePassword y serviceFabricCertificateThumbprint deben coincidir con el certificado usado para configurar

el clúster.
serviceFabricCertificate es el certificado como una cadena codificada en base 64, que se puede generar mediante el
siguiente script:
$bytes = [System.IO.File]::ReadAllBytes("C:\mycertificates\sfclustertutorialgroup220171109113527.pfx");
$b64 = [System.Convert]::ToBase64String($bytes);
[System.Io.File]::WriteAllText("C:\mycertificates\sfclustertutorialgroup220171109113527.txt", $b64);
En inbound_policy, reemplace el valor de sf-service-instance-name por fabric:/ApiApplication/WebApiService si

implementó antes el servicio de back-end de .NET, o por fabric:/EchoServerApplication/EchoServerService si
implementó el servicio Java. backend -id hace referencia a un recurso de back-end, en este caso el recurso
Microsoft.ApiManagement/service/backends definido en la plantilla apim.json. backend -id también puede hacer
referencia a otro recurso de back-end creado mediante las API de API Management. En este artículo deberá
establecer backend -id en el valor del parámetro service_fabric_backend_name.
<policies>
<inbound>
<base/>
</inbound>
<backend>
<base/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Use el siguiente script para implementar la plantilla de Resource Manager y los archivos de parámetros para API
Management:
$groupname = "sfclustertutorialgroup"
$clusterloc="southcentralus"
$templatepath="C:\clustertemplates"
New-AzResourceGroupDeployment -ResourceGroupName $groupname -TemplateFile "$templatepath\network-apim.json" -

TemplateParameterFile "$templatepath\network-apim.parameters.json" -Verbose
New-AzResourceGroupDeployment -ResourceGroupName $groupname -TemplateFile "$templatepath\apim.json" -

TemplateParameterFile "$templatepath\apim.parameters.json" -Verbose
ResourceGroupName="sfclustertutorialgroup"
az group deployment create --name ApiMgmtNetworkDeployment --resource-group $ResourceGroupName --template-file
network-apim.json --parameters @network-apim.parameters.json
az group deployment create --name ApiMgmtDeployment --resource-group $ResourceGroupName --template-file

apim.json --parameters @apim.parameters.json
Pruébelo
Ahora puede intentar enviar una solicitud al servicio back-end de Service Fabric a través de API Management
directamente desde Azure Portal.
1. En el servicio API Management, seleccione API.
2. En la API de Service Fabric App que creó en los pasos anteriores, seleccione la pestaña Prueba y, a
continuación, la operación Values.
3. Haga clic en el botón Enviar para enviar una solicitud de prueba al servicio de back-end. La respuesta HTTP
debe ser similar a la siguiente:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Vary: Origin
Ocp-Apim-Trace-Location:
https://apimgmtstodhwklpry2xgkdj.blob.core.windows.net/apiinspectorcontainer/PWSQOq_FCDjGcaI1rdMn8w2-2?
sv=2015-07-08&sr=b&sig=MhQhzk%2FEKzE5odlLXRjyVsgzltWGF8OkNzAKaf0B1P0%3D&se=2018-01-
28T01%3A04%3A44Z&sp=r&traceId=9f8f1892121e445ea1ae4d2bc8449ce4
Date: Sat, 27 Jan 2018 01:04:44 GMT
["value1", "value2"]
Un clúster está formado por muchos otros recursos de Azure, además del propio recurso del clúster. La manera
más sencilla de eliminar el clúster y todos los recursos que consume es eliminar el grupo de recursos.
Inicie sesión en Azure y seleccione el identificador de suscripción con el que quiere quitar el clúster. Para encontrar
el identificador de suscripción, inicie sesión en Azure Portal. Eliminar el grupo de recursos y todos los recursos de
clúster mediante el cmdlet Remove-AzResourceGroup.
$ResourceGroupName = "sfclustertutorialgroup"
Remove-AzResourceGroup -Name $ResourceGroupName -Force
az group delete --name $ResourceGroupName
Pasos siguientes
Obtenga más información acerca de cómo usar API Management.
vice-fabric-scripts-and-templates/blob/master/templates/service-integration/network-apim.parameters.jsonn
Edición de una API
Los pasos descritos en este tutorial muestran cómo usar API Management (APIM ) para editar una API.
Para hacerlo, puede agregar, eliminar, cambiar el nombre de las operaciones en la instancia de APIM.
Puede editar el swagger de la API.
Requisitos previos

TIP

Edición de una API en APIM
1. Haga clic en la pestaña API.

2. Seleccione una de las API que haya importado previamente.
3. Seleccione la pestaña Diseño.
4. Seleccione una operación que desee editar.
5. Para cambiar el nombre de la operación, seleccione un lápiz en la ventana Frontend.
Actualización del swagger

Puede actualizar su back-end API desde Azure Portal siguiendo estos pasos:
1. Seleccione Todas las operaciones
2. Haga clic en lápiz en la ventana front-end.
Aparece el swagger de la API.

3. Actualización del swagger.
4. Presione Save(Guardar).
Temas relacionados
Edición de una API
Pasos siguientes
Directivas de ejemplo de APIM Transformación y protección de una API publicada
Capacidad de una instancia de Azure API
Management
La capacidad la métrica de Azure Monitor individual más importante para tomar decisiones informadas acerca
de si se debe escalar una instancia de API Management para acomodar más carga. Su construcción es compleja e
impone un comportamiento concreto.
En este artículo se explica lo que es la capacidad y su comportamiento. Muestra cómo acceder a la métrica de
capacidad en Azure Portal y sugiere cuándo hay que considerar la posibilidad de escalar o actualizar una
instancia de API Management.
Requisitos previos
Para seguir los pasos de este artículo, debe tener:
Una suscripción de Azure activa.
Una instancia de APIM. Para más información, vea Creación de una instancia de Azure API Management.
Disponibilidad
IMPORTANT
¿Qué es la capacidad?
La capacidad es un indicador de la carga de una instancia de APIM. Refleja el uso de los recursos (CPU y
memoria) y las longitudes de cola de la red. El uso de la CPU y la memoria revela el consumo de recursos por
parte de:
Los servicios de APIM, como las acciones de administración o el procesamiento de solicitudes, lo que puede
incluir el reenvío de solicitudes o la ejecución de una directiva
Procesos seleccionados del sistema operativo, entre los que se incluyen los procesos que implican el costo de
los protocolos de enlace de SSL en las nuevas conexiones.
La capacidad total es un promedio de sus propios valores de cada unidad de una instancia de API Management.
Comportamiento de la métrica de capacidad

Dada su construcción, en la vida real la capacidad puede verse afectada por muchas variables, como por
ejemplo:
patrones de conexión (conexión nueva en una solicitud frente a reutilización de la conexión existente);
tamaño de una solicitud y respuesta;
directivas configuradas en cada API o número de clientes que envían solicitudes.
Cuanto más complejas sean las operaciones de las solicitudes, más alto será el consumo de la capacidad. Por
ejemplo, las directivas de transformación compleja consumen mucha más CPU que el reenvío de una solicitud
simple. Las respuestas lentas al servicio del back-end también la incrementarán.
IMPORTANT
La capacidad no es una medida directa del número de solicitudes que se procesan.
La capacidad también puede tener picos intermitentes o ser mayor que cero aunque no se procesen solicitudes.
Esto sucede debido a acciones específicas del sistema o de la plataforma, y no debe tenerse en cuenta al decidir si
se escala una instancia.
Uso de Azure Portal para examinar la capacidad

1. Acceda a la instancia de APIM de Azure Portal.
2. Seleccione Métrica (vista previa) .
3. En la sección púrpura, seleccione la métrica Capacidad y deje la agregación Avg predeterminada.
TIP
Para evitar interpretaciones incorrectas, siempre debe mirar el desglose de la métrica de capacidad por ubicación.
4. En la sección verde, seleccione Ubicación para dividir la métrica por dimensión.

5. Elija el período que desee en la barra superior de la sección.
Puede establecer una alerta de métrica que le avise cuando ocurra algo inesperado. Por ejemplo, obtenga
notificaciones cuando la instancia de APIM haya superado su capacidad máxima esperada durante más de
20 minutos.
TIP
Puede configurar alertas para saber en qué momento se está quedando sin capacidad un servicio o utilizar la
funcionalidad de escalado automático de Azure Monitor para agregar automáticamente una unidad de Azure API
Management. La operación de escalado puede tardar unos 30 minutos, por lo que debe planear las reglas en
consecuencia.
Solo se permite el escalado de la ubicación maestra.
Uso de la capacidad para decidir acerca del escalado

La capacidad la métrica de para tomar decisiones acerca de si se debe escalar una instancia de API Management
para acomodar más carga. Considere:
El examen del promedio y de la tendencia a largo plazo.
La omisión de picos repentinos que muy probablemente no estén relacionados con los aumentos en la carga
(para obtener una explicación, consulte la sección "Comportamiento de la métrica de capacidad").
La actualización o el escalado de la instancia cuando el valor de la capacidad supera el 60 % o 70 % durante
un período mayor (por ejemplo, 30 minutos). Para su servicio o escenario es posible que sean más apropiados
otros valores.
TIP
Si puede calcular el tráfico de antemano, pruebe su instancia de APIM en las cargas de trabajo que espera. Puede aumentar
la carga de solicitudes en el inquilino gradualmente y supervisar qué valor de la métrica de capacidad corresponde a la carga
máxima. Siga los pasos de la sección anterior para usar Azure Portal para saber la capacidad que se utiliza en un momento
dado.
Pasos siguientes
Escalado o actualización de una instancia del servicio Azure API Management
Actualización y escalado de una instancia de Azure
API Management
Para escalar una instancia de Azure API Management (APIM ) los clientes pueden agregar o eliminar unidades.
Una unidad se compone de recursos de Azure dedicados y tiene cierta capacidad de carga, que se expresa
mediante el número de llamadas API que se realizan cada mes. Dicho número no representa un límite de
llamadas, sino un valor de rendimiento máximo que permite el planeamiento de la capacidad aproximada. El
rendimiento y la latencia reales varían considerablemente en función de factores como el número y la tasa de
conexiones concurrentes, el tipo y número de directivas configuradas, los tamaños de las solicitudes y respuestas
y la latencia del back-end.
La capacidad y el precio de cada unidad dependen del nivel en que se encuentra la unidad. Puede elegir entre
cuatro niveles: Desarrollador, Básico, Estándar, Premium. Si necesita más capacidad para un servicio de un
nivel, debe agregar una unidad. Si el nivel que está seleccionado actualmente en la instancia de APIM no permite
agregar más unidades, deberá actualizar a un nivel superior.
El precio de cada unidad y las características disponibles (por ejemplo, la implementación en varias regiones)
dependen del nivel elegido para la instancia de APIM. En el artículo sobre los precios, se explican el precio por
unidad y las características que se obtienen en cada nivel.
NOTE
En este artículo sobre los precios, se indica el número aproximado de unidades que puede tener cada nivel. Para obtener
unos datos más exactos, deberá consultar un escenario que se ajuste a la realidad de sus API. Consulte el artículo Capacidad
de una instancia de Azure API Management.
Requisitos previos
Para seguir los pasos de este artículo, debe:
Tener una suscripción de Azure activa.
Tener una instancia de APIM. Para más información, vea Creación de una instancia de Azure API
Management.
Comprender el concepto de Capacidad de una instancia de Azure API Management.
Disponibilidad
IMPORTANT
Actualización y escalado
Puede elegir entre cuatro niveles: Desarrollador, Básico, Estándar y Premium. El nivel Desarrollador debe
utilizarse para evaluar el servicio; no debe emplearse para producción. El nivel Desarrollador no dispone de un
Acuerdo de Nivel de Servicio y no se puede escalar (no se pueden agregar o quitar unidades).
Los niveles de producción Básico, Estándar y Premium cuentan con un Acuerdo de Nivel de Servicio y se
pueden escalar. El nivel Básico es el más económico que cuenta con un contrato de nivel de servicio (SLA) y
puede escalarse hasta dos unidades. El nivel Estándar puede escalarse hasta cuatro unidades. Puede agregar
cualquier número de unidades en el nivel Premium.
El nivel Premium permite distribuir una instancia de Azure API Management individual entre cualquier número
de regiones de Azure. Inicialmente, cuando se crea un servicio Azure API Management, la instancia contiene una
sola unidad y reside en una única región de Azure. La región inicial se designa como región primaria. Pueden
agregarse otras regiones fácilmente. Cuando agregue una región, debe especificar el número de unidades que
desea asignar. Por ejemplo, puede tener una unidad en la región primaria y cinco unidades en otra región. Puede
adaptar el número de unidades al tráfico que tiene en cada región. Para más información, consulte
Implementación de una instancia del servicio Azure API Management en varias regiones de Azure.
Puede cambiar un nivel por otro superior o inferior. Tenga en cuenta que, si cambia a un nivel superior o inferior,
es posible que algunas características dejen de estar disponibles, como ocurre con las VNET o las
implementaciones en varias regiones cuando se pasa del nivel Premium al nivel Estándar o Básico.
NOTE
El proceso de actualización o escalado puede tardar entre 15 y 45 minutos en aplicarse. Recibirá una notificación cuando se
haya completado.
Uso de Azure Portal para actualizar y escalar

2. Seleccione Escalado y precios en el menú.
3. Elija el nivel que desee.
4. Especifique el número de unidades que desea agregar. Puede utilizar el control deslizante o escribir
directamente el número.
Si selecciona el nivel Premium, primero tendrá que seleccionar una región.
Pasos siguientes
Implementación de una instancia del servicio Azure API Management en varias regiones de Azure
Escalado automático de una instancia de servicio de Azure API Management
Escalado automático de una instancia de Azure API
Management
Una instancia de servicio de Azure API Management puede escalarse de manera automática en función de un
conjunto de reglas. Este comportamiento se puede habilitar y configurar a través de Azure Monitor y solo se
admite en los niveles Estándar y Premium del servicio Azure API Management.
En este artículo se le guía por el proceso de configuración de escalado automático y sugiere una configuración
óptima de las reglas de escalado automático.
Requisitos previos
Para seguir los pasos de este artículo, debe:
Tener una suscripción de Azure activa.
Tener una instancia de Azure API Management. Para más información, vea Creación de una instancia de Azure
API Management.
Comprender el concepto de Capacidad de una instancia de Azure API Management.
Comprender el proceso de escalado manual de una instancia de Azure API Management, incluidas las
consecuencias de costos.
Disponibilidad
IMPORTANT
Limitaciones de escalado automático de Azure API Management

Ciertas limitaciones y consecuencias de las decisiones de escalado deben tenerse en cuenta antes de configurar el
comportamiento de escalado automático.
La escalabilidad automática se puede habilitar solo para los niveles Estándar y Premium del servicio Azure
API Management.
Los planes de tarifa también especifican el número máximo de unidades para una instancia de servicio.
El proceso de escalado tardará al menos 20 minutos.
Si el servicio está bloqueado por otra operación, la solicitud de escalado producirá un error y volverá a
intentarse automáticamente.
En el caso de un servicio con implementaciones en varias regiones, solo se pueden escalar las unidades en la
Ubicación principal. No se puede escalar las unidades en otras ubicaciones.
Habilitación y configuración del escalado automático para el servicio

Siga los pasos a continuación para configurar el escalado automático para un servicio Azure API Management:
1. Acceda a la instancia Monitor en Azure Portal.
2. Seleccione Escalado automático del menú de la izquierda.
3. Busque el servicio Azure API Management en función de los filtros en los menús desplegables.
4. Seleccione la instancia de servicio deseada de Azure API Management.
5. En la sección recién abierta, haga clic en el botón Habilitar escalado automático.
6. En la sección Reglas, haga clic en + Agregar una regla.

7. Defina una nueva regla de escalado horizontal.
Por ejemplo, una regla de escalado horizontal podría desencadenar una adición de una unidad de Azure API
Management, cuando la métrica de capacidad promedio durante los últimos 30 minutos supere el 80 %. En
la tabla siguiente se proporciona la configuración para este tipo de regla.
PARÁMETRO VALOR NOTAS
Origen de métricas Recurso actual Defina la regla según las métricas de

recursos de Azure API Management
actuales.
Criterios
Agregación de tiempo Media
Nombre de métrica Capacity La métrica de capacidad es una

métrica de Azure API Management
que refleja el uso de recursos de una
instancia de Azure API Management.
Estadísticas de intervalo de Media

agregación
Operador Mayor que
Umbral 80 % El umbral de la métrica de capacidad

promedio.
Duración (en minutos) 30 El intervalo de tiempo para

promediar la métrica de capacidad es
específica a los patrones de uso.
Cuanto mayor sea el período de
tiempo, más suave será la reacción:
los picos intermitentes tendrán un
efecto menor sobre la decisión de
escalado horizontal. Sin embargo,
también se demorará el
desencadenador de escalado
horizontal.
Acción
Operación Aumentar recuento en
Recuento de instancias 1 Escale la instancia de Azure API

Management horizontalmente en 1
unidad.
Tiempo de finalización (minutos) 60 El servicio Azure API Management

tarda al menos 20 minutos en
escalarse horizontalmente. En la
mayoría de los casos, el período de
finalización de 60 minutos evita que
se desencadenen muchos escalados
horizontales.
8. Haga clic en Agregar para guardar la regla.

9. Haga clic en nuevo en + Agregar una regla.
Esta vez, debe definirse una regla de reducción horizontal. Esto garantizará que no se malgasten los
recursos, cuando se reduzca el uso de las API.
10. Defina una nueva regla de reducción horizontal.
Por ejemplo, una regla de reducción horizontal podría desencadenar una eliminación de una unidad de
Azure API Management, cuando la métrica de capacidad promedio durante los últimos 30 minutos haya
sido inferior al 35 %. En la tabla siguiente se proporciona la configuración para este tipo de regla.
Origen de métricas Recurso actual Defina la regla según las métricas de

recursos de Azure API Management
actuales.
Criterios
Agregación de tiempo Media
Nombre de métrica Capacity La misma métrica que la utilizada

para la regla de escalado horizontal.
Estadísticas de intervalo de Media

agregación
Operador Menor que

Umbral 35 % De forma similar a la regla para

escalado horizontal, este valor
depende en gran medida los
patrones de uso de Azure API
Management.
Duración (en minutos) 30 El mismo valor que el utilizado para la

regla de escalado horizontal.
Acción
Operación Reducir el recuento en Opuesta a lo que se usó para la regla

de escalado horizontal.
Recuento de instancias 1 El mismo valor que el utilizado para la

regla de escalado horizontal.
Tiempo de finalización (minutos) 90 La reducción horizontal debe ser más

conservadora que un escalado
horizontal, por lo que el período de
finalización debe ser mayor.
11. Haga clic en Agregar para guardar la regla.
12. Establezca el número máximo de unidades de Azure API Management.

NOTE
Azure API Management tiene un límite de unidades a las que se puede escalar horizontalmente una instancia. El
límite depende del nivel del servicio.
13. Haga clic en Save(Guardar). Se ha configurado el escalado automático.
Pasos siguientes
Implementación de una instancia del servicio Azure API Management en varias regiones de Azure
Configurar un nombre de dominio personalizado
Cuando se crea una instancia del servicio Azure API Management (APIM ), Azure le asigna el subdominio de
azure-api.net (por ejemplo, apim-service-name.azure-api.net ). Sin embargo, los puntos de conexión de APIM se
pueden exponer con su propio nombre de dominio personalizado, como contoso.com. En este tutorial se muestra
cómo asignar un nombre DNS personalizado existente a los puntos de conexión expuestos por una instancia de
API Management.
WARNING
Los clientes que deseen usar la asignación de certificados para mejorar la seguridad de sus aplicaciones deben usar un
nombre de dominio personalizado > y el certificado que administran, no el certificado predeterminado. Los clientes que
asignen el certificado predeterminado en su lugar tendrán > una gran dependencia de las propiedades del certificado que no
controlen, no siendo esto una práctica recomendada.
Requisitos previos
Para seguir los pasos que se describen en este artículo, debe tener:
Una instancia de API Management Para más información, vea Creación de una instancia de Azure API
Management.
Nombre de dominio personalizado que sea de su propiedad. El nombre de dominio personalizado que
desee usar debe adquirirse por separado y hospedarse en un servidor DNS. Este tema no contiene
instrucciones acerca de cómo hospedar un nombre de dominio personalizado.
Debe tener un certificado válido con una clave pública y privada (. PFX). El firmante o el nombre alternativo
del firmante (SAN ) debe coincidir con el nombre de dominio; de este modo, API Management puede
exponer de forma segura direcciones URL a través de SSL.
Uso de Azure Portal para configurar un nombre de dominio

personalizado
1. Vaya a la instancia de API Management en Azure Portal.
2. Seleccione Dominios personalizados y SSL.
Hay varios puntos de conexión a los que puede asignar un nombre de dominio personalizado. En la
actualidad, están disponibles los siguientes:
Proxy (el valor predeterminado es <apim-service-name>.azure-api.net ),
Portal (el valor predeterminado es <apim-service-name>.portal.azure-api.net ),
Management (el valor predeterminado es <apim-service-name>.management.azure-api.net ),
SCM (el valor predeterminado es <apim-service-name>.scm.azure-api.net ).
NOTE
Puede actualizar algunos o todos los puntos de conexión. Por lo general, los clientes actualizan Proxy (esta dirección
URL se utiliza para llamara a la API expuesta a través de API Management) y Portal (dirección URL del portal del
desarrollador). Los puntos de conexión Management y SCM los usan internamente los propietarios de la instancia
de API Management y, por tanto, se les asigna con menor frecuencia un nombre de dominio personalizado. En la
mayoría de los casos, solo se puede establecer un nombre de dominio personalizado para un punto de conexión
dado. Sin embargo, el nivel premium admite la configuración de varios nombres de host para el punto de conexión
Proxy.
3. Seleccione el punto de conexión que desee actualizar.

4. En la ventana de la derecha, haga clic en Personalizar.
En Nombre de dominio personalizado, especifique el nombre que desee usar. Por ejemplo,
api.contoso.com . También se pueden usar nombres de dominio comodín (por ejemplo, *. dominio.com ).
En Certificado, seleccione un certificado de Key Vault. También puede cargar un archivo .PFX válido y
proporcionar su contraseña, si el certificado está protegido con una contraseña.
TIP
Se recomienda usar Azure Key Vault para administrar certificados y configurarlos para la rotación automática. Si usa
Azure Key Vault para administrar el certificado SSL de dominio personalizado, asegúrese de que el certificado se
inserta en Key Vault como un certificado, no como un secreto.
Para obtener un certificado SSL, API Management debe tener la lista de permisos y obtener los permisos de secretos
en la instancia de Key Vault que contiene el certificado. Cuando se usa Azure Portal, todos los pasos de configuración
necesarios se realizarán automáticamente. Cuando se usan las herramientas de línea de comandos o API
Management, estos permisos se deben conceder manualmente. Para ello, debe realizar dos pasos. En primer lugar,
use la página de identidades administradas de la instancia de API Management para asegurarse de que está
habilitada la identidad administrada, y anote el identificador de la entidad que se muestra en esa página. En segundo
lugar, proporcione la lista de permisos y obtenga los permisos de secretos de este identificador de entidad en la
instancia de Azure Key Vault que contiene el certificado.
Si el certificado está establecido para rotar automáticamente, API Management seleccionará automáticamente la
versión más reciente sin tiempo de inactividad para el servicio (si el plan de API Management tiene SLA en todos los
planes, excepto el plan de desarrollador).
5. Haga clic en Aplicar.
NOTE
El proceso de asignación del certificado puede tardar unos 15 minutos o más según el tamaño de la implementación.
La SKU de desarrollador tiene un tiempo de inactividad, mientras que las SKU básica y superiores no.
Respuesta del servidor proxy de APIM con certificados SSL en el

protocolo de enlace TLS
Clientes que llaman con encabezado SNI
Si el cliente tiene uno o varios dominios personalizados configurados para el proxy, APIM puede responder a las
solicitudes HTTPS desde los dominios personalizados (por ejemplo, contoso.com), así como desde el dominio
predeterminado (por ejemplo, apim-service-name.azure-api.net). Según la información del encabezado de
Indicación de nombre de servidor (SNI), APIM responde con el certificado de servidor correspondiente.
Clientes que llaman sin encabezado SNI
Si el usuario usa un cliente, que no envía el encabezado SNI, APIM crea respuestas basadas en la lógica siguiente:
Si el servicio tiene un solo dominio personalizado configurado para el proxy, el certificado predeterminado es
el certificado emitido para el dominio personalizado de proxy.
Si el servicio tiene varios dominios personalizados configurados para el proxy (solo se admite en el nivel
Premium ), el cliente puede designar qué certificado debe ser el certificado predeterminado. Para establecer el
certificado predeterminado, la propiedad defaultSslBinding debe establecerse en true
("defaultSslBinding":"true"). Si el cliente no establece la propiedad, el certificado predeterminado es el
certificado emitido para el dominio de proxy predeterminado hospedado en *.azure-api.net.
Compatibilidad para la solicitud PUT/POST con una carga grande

El servidor proxy de APIM admite la solicitud con una carga grande cuando se usan certificados HTTPS del lado
cliente (por ejemplo, carga > 40 KB ). Para evitar que la solicitud del servidor se quede congelada, los clientes
pueden establecer la propiedad "negotiateClientCertificate": "true" en el nombre de host del proxy. Si la propiedad
está establecida en true, el certificado de cliente se solicita en el tiempo de conexión SSL/TLS, antes de
intercambiar cualquier solicitud HTTP. Puesto que la configuración se aplica al nivel de Nombre de host del
proxy, todas las solicitudes de conexión piden el certificado de cliente. Los clientes pueden configurar hasta veinte
dominios personalizados para el proxy (solo se admite en el nivel Premium ) y aplicar una solución temporal para
esta limitación.
Pasos siguientes
Actualización y escalado del servicio
Incorporación del almacenamiento en caché para
mejorar el rendimiento en Azure API Management
En Administración de API, las operaciones se pueden configurar para el almacenamiento en caché de respuestas.
El almacenamiento en caché de respuestas puede reducir significativamente la latencia de la API, el consumo de
ancho de banda y la carga del servicio web en cuanto a datos que no cambian con frecuencia.
Para más información acerca del almacenamiento en caché, consulte Directivas de almacenamiento en caché de
API Management y Almacenamiento en caché personalizado en Azure API Management.
Temas que se abordarán:

Agregar almacenamiento en caché de respuesta a una API
Comprobar el almacenamiento en caché en acción
Disponibilidad
NOTE
La memoria caché interna no está disponible en el nivel Consumo de Azure API Management. Puede usar una instancia
externa de Azure Redis Cache en su lugar.
Requisitos previos
Para completar este tutorial:
Incorpore y publique una API
Adición de las directivas de almacenamiento en caché
Con las directivas de almacenamiento en caché que se muestran en este ejemplo, la primera solicitud de la
operación GetSpeakers devuelve una respuesta del servicio back-end. Dicha respuesta se almacena en la caché,
con una clave especificada mediante encabezados y parámetros de la cadena de consulta. Las siguientes llamadas
a la operación, con parámetros coincidentes, devolverán la respuesta almacenada en caché hasta que el intervalo
de duración en la caché haya expirado.
1. Inicie sesión en Azure Portal en https://portal.azure.com.
2. Vaya a la instancia de APIM.
3. Seleccione la pestaña API.
5. Seleccione GetSpeakers.
7. En la sección Procesamiento de entrada, haga clic en el icono </> .
8. En el elemento inbound, agregue la siguiente directiva:
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false">

<vary-by-header>Accept</vary-by-header>
<vary-by-header>Accept-Charset</vary-by-header>
<vary-by-header>Authorization</vary-by-header>
</cache-lookup>
9. En el elemento outbound, agregue la siguiente directiva:
<cache-store caching-mode="cache-on" duration="20" />
Duración especifica el intervalo de expiración de las respuestas almacenadas en caché. En este ejemplo, el
intervalo es 20 segundos.
TIP
Si usa una memoria caché externa, como se describe en Uso de una memoria caché de Redis externa en Azure API
Management, es posible que desee especificar el atributo caching-type de las directivas de almacenamiento en caché.
Consulte Directivas de almacenamiento en caché de API Management para más detalles.
Llamada a una operación y prueba del almacenamiento en caché

Para ver cómo funciona el almacenamiento en caché, llame a la operación desde el portal para desarrolladores.
1. En Azure Portal, vaya a la instancia de APIM.
3. Seleccione la API a la que ha agregado directivas de almacenamiento en caché.
5. Haga clic en la pestaña Test (Prueba) del menú superior derecho.
6. Presione Enviar.
Pasos siguientes
Para más información sobre las directivas de almacenamiento en caché, consulte Caching policies (Directivas
de almacenamiento en caché) en API Management policy reference (Referencia de la directiva de API
Management).
Para obtener información sobre el almacenamiento en caché de los elementos por parte de la clave mediante
expresiones de directiva, consulte Custom caching in Azure API Management.
Para más información sobre el uso de una instancia externa de Azure Redis Cache, consulte Uso de una
memoria caché de Redis externa en Azure API Management.
Uso de una instancia externa de Azure Redis Cache
en Azure API Management
Además de utilizar la memoria caché integrada, Azure API Management permite también almacenar en caché
las respuestas en una instancia externa de Azure Redis Cache.
El uso de una memoria caché externa permite superar algunas limitaciones de la memoria caché integrada.
Resulta especialmente útil si desea:
Evitar que la memoria caché se borre periódicamente durante las actualizaciones de API Management
Tener más control sobre la configuración de la memoria caché
Almacenar en memoria caché más datos de los que permite el plan de API Management
Usar el almacenamiento en caché con el nivel de consumo de API Management
Para más información acerca del almacenamiento en caché, consulte Directivas de almacenamiento en caché de
API Management y Almacenamiento en caché personalizado en Azure API Management.
Temas que se abordarán:

Agregar una memoria caché externa en API Management
Requisitos previos
Para completar este tutorial, necesita:
Comprender el almacenamiento en memoria caché en Azure API Management
Creación de una instancia de Azure Redis Cache

En esta sección se explica cómo crear una instancia de Azure Redis Cache en Azure. Si ya tiene una instancia de
Azure Redis Cache, dentro o fuera de Azure, puede pasar a la sección siguiente.
1. Para crear una memoria caché, primero inicie sesión en Azure Portal. A continuación, seleccione Crear un
recurso > Bases de datos > Azure Redis Cache.
2. En New Azure Cache for Redis (Nueva instancia de Azure Redis Cache), configure la nueva caché.
Nombre DNS Nombre único globalmente El nombre de caché. Tiene que ser
una cadena de entre 1 y 63
caracteres y solo puede contener
números, letras y el carácter - . El
nombre de la memoria caché no
puede comenzar ni terminar por el
carácter - y no se pueden usar
varios caracteres - consecutivos.
Suscripción Su suscripción La suscripción en la que se crea esta

nueva instancia de Azure Redis
Cache.
Grupos de recursos TestResources Nombre del nuevo grupo de

recursos en el que se va a crear la
caché. Al colocar todos los recursos
de una aplicación en un grupo,
puede administrarlos juntos. Por
ejemplo, si elimina el grupo de
recursos también se eliminarán
todos los recursos que están
asociados con la aplicación.
Ubicación Este de EE. UU Elija una región cerca de otros

servicios que vayan a usar la
memoria caché.
Plan de tarifa C0 para básico (caché de 250 MB) El plan de tarifa determina el
tamaño, el rendimiento y las
características disponibles para la
memoria caché. Para más
información, consulte la introducción
a Azure Redis Cache.
Anclar al panel Seleccionado Ancle la nueva caché para

encontrarla con facilidad.
3. Una vez que las nuevas opciones de caché estén configuradas, seleccione Crear.
La creación de la caché puede tardar unos minutos. Para comprobar el estado, puede supervisar el
progreso en el panel. Después de crear la memoria caché, testa tendrá el estado En ejecución y estará
lista para su uso.
Adición de una memoria caché externa

Siga estos pasos para agregar una instancia externa de Azure Redis Cache en Azure API Management.
NOTE
La configuración Utilizar desde especifica qué implementación regional de API Management se comunicará con la
memoria caché configurada en el caso de una configuración regional múltiple de API Management. Las memorias caché
especificadas como Predeterminada serán reemplazadas por las memorias caché con un valor regional.
Por ejemplo, si API Management está hospedado en las regiones Este de EE. UU., Sudeste Asiático y Europa Occidental y
hay dos memorias caché configuradas, una como Predeterminada y otra para Sudeste Asiático, la instancia de API
Management de Sudeste Asiático usará su propia memoria caché, mientras que las otras dos regiones utilizará la entrada
de caché Predeterminada.
Incorporación de una instancia de Azure Redis Cache desde la misma suscripción

2. Seleccione la pestaña Caché externa en el menú de la izquierda.
3. Haga clic en el botón + Agregar.
4. Seleccione la memoria caché en el campo de lista desplegable Instancia de caché.
5. Seleccione Predeterminada o especifique la región deseada en el campo de lista desplegable Utilizar
desde.
Incorporación de una instancia de Azure Redis Cache hospedada fuera de la suscripción de Azure actual o de
Azure en general
2. Seleccione la pestaña Caché externa en el menú de la izquierda.
4. Seleccione Personalizada en el campo de lista desplegable Instancia de caché.
5. Seleccione Predeterminada o especifique la región deseada en el campo de lista desplegable Utilizar
desde.
6. Proporcione la cadena de conexión de Azure Redis Cache en el campo Cadena de conexión.
Uso de la memoria caché externa

Una vez que la memoria caché externa está configurada en Azure API Management, se puede usar mediante
directivas de almacenamiento en caché. Consulte Incorporación del almacenamiento en caché para mejorar el
rendimiento en Azure API Management para conocer los pasos detallados.
Pasos siguientes
Para más información sobre las directivas de almacenamiento en caché, consulte Caching policies (Directivas
de almacenamiento en caché) en API Management policy reference (Referencia de la directiva de API
Management).
Para obtener información sobre el almacenamiento en caché de los elementos por parte de la clave mediante
expresiones de directiva, consulte Custom caching in Azure API Management.
Creación de suscripciones en Azure API Management
Al publicar las API mediante Azure API Management, es sencillo y frecuente proteger el acceso a ellas mediante
claves de suscripción. Las aplicaciones cliente que necesiten usar las API publicadas deben incluir una clave de
suscripción válida en las solicitudes HTTP al realizar llamadas a esas API. Para obtener una clave de suscripción
para acceder a las API se necesita una suscripción. Para más información sobre las suscripciones, consulte
Suscripciones en Azure API Management.
Este artículo le guiará por los pasos necesarios para crear suscripciones en Azure Portal.
Requisitos previos
Para aprovechar los pasos de este artículo, los requisitos previos son los siguientes:
Crear una instancia de API Management.
Entender las suscripciones en API Management.
Crear una nueva suscripción

1. Seleccione Suscripciones en el menú de la izquierda.
2. Seleccione Agregar suscripción.
3. Proporcione un nombre de suscripción y seleccione el ámbito.
4. Si lo desea, elija si la suscripción se debe asociar a un usuario.
Después de crear la suscripción, se proporcionan dos claves para acceder a las API. Una clave es la principal y la
otra, la secundaria.
Pasos siguientes
Para más información sobre API Management:
Aprenda otros conceptos en API Management.
Siga nuestros tutoriales para más información sobre API Management.
Consulte nuestra página de preguntas frecuentes para ver las preguntas habituales.
Protección de API mediante la autenticación de
certificados de cliente en API Management
API Management proporciona la capacidad de proteger el acceso a las API (es decir, de cliente a API
Management) mediante certificados de cliente. Puede validar el certificado entrante y comprobar las propiedades
del certificado con los valores deseados mediante expresiones de directiva.
Para obtener información acerca de cómo proteger el acceso al servicio back-end de una API mediante
certificados de cliente (es decir, API Management a back-end), vea cómo asegurar servicios back-end mediante el
cliente de autenticación de certificados
IMPORTANT
Para recibir y comprobar los certificados de cliente en el nivel de consumo debe activar "Certificado de cliente de solicitud"
establecer en la hoja "Dominios personalizados", tal como se muestra a continuación.
Comprobación del emisor y el asunto

Es posible configurar las directivas siguientes para comprobar el emisor y el firmante de un certificado de cliente:
<choose>
<when condition="@(context.Request.Certificate == null || !context.Request.Certificate.Verify() ||
context.Request.Certificate.Issuer != "trusted-issuer" || context.Request.Certificate.SubjectName.Name !=
"expected-subject-name")" >
<return-response>
<set-status code="403" reason="Invalid client certificate" />
</return-response>
</when>
</choose>
NOTE
Para deshabilitar el uso de lista de revocación de certificados comprobación
context.Request.Certificate.VerifyNoRevocation() en lugar de context.Request.Certificate.Verify() . Si el
certificado de cliente es un certificado autofirmado, raíz (o intermedia) deben ser certificados de CA cargado a la API de
administración de context.Request.Certificate.Verify() y context.Request.Certificate.VerifyNoRevocation()
funcione.
Comprobación de la huella digital

Es posible configurar las directivas siguientes para comprobar la huella digital de un certificado de cliente:
<choose>
context.Request.Certificate.Thumbprint != "desired-thumbprint")" >
<return-response>
</return-response>
</when>
</choose>
NOTE
funcione.
Comprobación de una huella digital en relación con certificados

cargados en API Management
En el ejemplo siguiente se muestra cómo comprobar la huella digital de un certificado de cliente en relación con
los certificados cargados en API Management:
<choose>
!context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >
<return-response>
</return-response>
</when>
</choose>
NOTE
funcione.
TIP
Problema de interbloqueo de certificado de cliente se describe en este artículo puede manifestarse de varias maneras, por
ejemplo, las solicitudes inmovilizar, el resultado de las solicitudes 403 Forbidden código de estado después de agotar el
tiempo, context.Request.Certificate es null . Este problema afecta a normalmente POST y PUT las solicitudes con la
longitud del contenido de aproximadamente 60 KB o superior. Para evitar este problema produzca habilite "Certificado de
cliente Negotiate" para los nombres de host deseado en la hoja "Dominios personalizados" tal como se muestra a
continuación. Esta característica no está disponible en el nivel de consumo.
Pasos siguientes
Cómo asegurar servicios back-end con la autenticación de certificados de cliente
¿Cómo se cargan certificados?
Protección de una API mediante OAuth 2.0 con
Azure Active Directory API Management
En esta guía se muestra cómo configurar la instancia de Azure API Management para proteger una API mediante
el protocolo OAuth 2.0 con Azure Active Directory (Azure AD ).
Requisitos previos
Una instancia de API Management
Una API que se vaya a publicar y que use la instancia de API Management
Un inquilino de Azure AD
Aquí se muestra una introducción rápida de los pasos:
1. Registre una aplicación (aplicación back-end) en Azure AD que represente la API.
2. Registre otra aplicación (aplicación cliente) en Azure AD que represente una aplicación de cliente que deba
llamar a la API.
3. En Azure AD, conceda permisos para que la aplicación cliente llame a la aplicación back-end.
4. Configure la consola del desarrollador para utilizar la autorización de usuario OAuth 2.0.
5. Agregue la directiva validate-jwt para validar el token de OAuth para todas las solicitudes entrantes.
Registro de una aplicación en Azure AD que represente la API

Para proteger una API con Azure AD, el primer paso es registrar una aplicación en Azure AD que la represente.
1. Vaya a la página Azure Portal: registros de aplicaciones.
2. Seleccione Nuevo registro.
3. Cuando aparece la página Registrar una aplicación, escriba la información de registro de la aplicación:
En la sección Nombre, escriba un nombre significativo para la aplicación, que se mostrará a los usuarios
de la aplicación, por ejemplo, backend-app .
En la sección Tipos de cuenta compatibles, seleccione Cuentas en cualquier directorio
organizativo.
4. Deje la sección URI de redireccionamiento vacía por ahora.
5. Seleccione Registrar para crear la aplicación.
6. En la página Información general de la aplicación, busque el valor de Id. de aplicación (cliente) y
regístrelo para usarlo más tarde.
Una vez creada la aplicación, tome nota del Id. de aplicación para usarlo en un paso posterior.
Registro de otra aplicación en Azure AD que represente una aplicación

cliente
Todas las aplicaciones cliente que llamen a la API deben registrarse también como aplicación en Azure AD. En este
ejemplo, la aplicación cliente de ejemplo es la consola del desarrollador en el portal para desarrolladores de API
Management. A continuación se indica cómo registrar otra aplicación en Azure AD que represente la consola del
desarrollador.
1. Vaya a la página Azure Portal: registros de aplicaciones.
2. Seleccione Nuevo registro.
3. Cuando aparece la página Registrar una aplicación, escriba la información de registro de la aplicación:
En la sección Nombre, escriba un nombre significativo para la aplicación, que se mostrará a los usuarios
de la aplicación, por ejemplo, client-app .
En la sección Tipos de cuenta compatibles, seleccione Cuentas en cualquier directorio
organizativo.
4. En la sección URI de redirección, seleccione Web e introduzca la URL
https://contoso5.portal.azure-api.net/signin .
5. Seleccione Registrar para crear la aplicación.

6. En la página Información general de la aplicación, busque el valor de Id. de aplicación (cliente) y
regístrelo para usarlo más tarde.
Ahora, cree un secreto de cliente para esta aplicación que usaremos en un paso posterior.
1. En la lista de páginas de la aplicación cliente, seleccione Certificados y secretos y Nuevo secreto de
cliente.
2. En Agregar un secreto de cliente, proporcione una descripción. Elija cuando debe expirar la clave y
seleccione Agregar.
Anote el valor de la clave.
Concesión de permisos en Azure AD

Ahora que hemos registrado dos aplicaciones que representan la API y la consola del desarrollador, es necesario
conceder permisos para que la aplicación cliente pueda llamar a la aplicación back-end.
1. Vaya a Registros de aplicaciones.
2. Seleccione client-app y, en la lista de páginas de la aplicación, seleccione Permisos de API.
3. Seleccione Agregar un permiso.
4. En Seleccionar una API, busque y seleccione backend-app .
5. En Permisos delegados, seleccione los permisos adecuados para backend-app .
6. Seleccione Agregar permisos.
NOTE
Si Azure Active Directory no aparece en los permisos para otras aplicaciones, haga clic en Agregar y agréguelo desde la
lista.
Habilitación de la autorización de usuario OAuth 2.0 en la consola del

desarrollador
En este punto ya se han creado nuestras aplicaciones en Azure AD y se han concedido los permisos pertinentes
para que la aplicación cliente pueda llamar a la aplicación back-end.
En este ejemplo, la consola del desarrollador es la aplicación cliente. En los pasos siguientes se describe la
habilitación de la autorización de usuario OAuth 2.0 en la consola del desarrollador.
1. En Azure Portal, vaya a la instancia de API Management.
2. Seleccione OAuth 2.0 > Agregar.
3. Proporcione un Nombre para mostrar y una Descripción.
4. Como URL de la página de registro de cliente, escriba un valor de marcador de posición como
http://localhost . La URL de la página de registro de cliente señala a la página que los usuarios
pueden utilizar para crear y configurar sus propias cuentas para proveedores de OAuth 2.0 que admiten
esto. En este ejemplo, los usuarios no crean ni configuran sus propias cuentas, por lo que se usa un
marcador de posición en su lugar.
5. En Tipos de concesión de autorización, seleccione Código de autorización.
6. Especifique la URL del punto de conexión de autorización y la URL del punto de conexión de token.
Recupere estos valores desde la página Puntos de conexión del inquilino de Azure AD. Vaya a la página
Registros de aplicaciones de nuevo y seleccione Puntos de conexión.
7. Copie el punto de conexión de autorización de OAuth 2.0 y péguelo en el cuadro de texto URL de
punto de conexión de autorización.
8. Copie el punto de conexión de token de OAuth 2.0 y péguelo en el cuadro de texto URL de punto de
conexión del token. Además de pegarlo en el punto de conexión del token, agregue un parámetro de
cuerpo denominado resource. Como valor de este parámetro, use el Id. de aplicación para la aplicación
de back-end.
9. A continuación, especifique las credenciales del cliente. Estas son las credenciales para la aplicación cliente.
10. Como Id. de cliente, use el Id. de aplicación de la aplicación cliente.
11. Como secreto de cliente, use la clave que creó para la aplicación cliente.
12. Inmediatamente después del secreto del cliente se encuentra redirect_url como tipo de concesión de
código de autorización. Anote esta dirección URL.
14. Vuelva a la página Configuración de la aplicación cliente.
15. Seleccione URL de respuesta y pegue el valor de redirect_url en la primera fila. En este ejemplo, ha
reemplazado https://localhost por la dirección URL en la primera fila.
Ahora que ha configurado un servidor de autorización de OAuth 2.0, la consola del desarrollador puede obtener
tokens de acceso de Azure AD.
El paso siguiente consiste en habilitar la autorización de usuario de OAuth 2.0 para la API. Esto permite que la
consola del desarrollador sepa que debe obtener un token de acceso en nombre del usuario antes de realizar
llamadas a la API.
1. Vaya a la instancia de API Management y a API.
2. Seleccione la API que desea proteger. En este ejemplo, puede usar Echo API .
3. Vaya a Configuración.
4. En Seguridad, elija OAuth 2.0 y seleccione el servidor OAuth 2.0 que se configuró anteriormente.
Llamada correcta a la API desde el portal para desarrolladores

NOTE
Esta sección no es aplicable al nivel de consumo, que no es compatible con el portal para desarrolladores.
Ahora que la autorización de usuario OAuth 2.0 está habilitada en Echo API , la consola del desarrollador obtiene
un token de acceso para el usuario antes de llamar a la API.
1. Vaya a cualquier operación de Echo API en el portal para desarrolladores y, a continuación, seleccione
Probar. Aparecerá la consola del desarrollador.
2. Tenga en cuenta el nuevo elemento de la sección Autorización correspondiente al servidor de autorización
que acaba de agregar.
3. Seleccione Código de autorización de la lista desplegable de autorizaciones y se le pedirá que inicie
sesión en el inquilino de Azure AD. Si ya ha iniciado sesión con la cuenta, es posible que no se le indique
nada.
4. Al iniciar sesión correctamente, un encabezado Authorization se agregará a la solicitud con un token de
acceso de Azure AD. El siguiente es un token de ejemplo (con codificación Base64):
Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlNTUWRoSTFjS3ZoUUVEU0p4RTJnR1lzNDBRMCIsImtpZCI6IlNTUWRoSTF
jS3ZoUUVEU0p4RTJnR1lzNDBRMCJ9.eyJhdWQiOiIxYzg2ZWVmNC1jMjZkLTRiNGUtODEzNy0wYjBiZTEyM2NhMGMiLCJpc3MiOiJod
HRwczovL3N0cy53aW5kb3dzLm5ldC80NDc4ODkyMC05Yjk3LTRmOGItODIwYS0yMTFiMTMzZDk1MzgvIiwiaWF0IjoxNTIxMTUyNjMz
LCJuYmYiOjE1MjExNTI2MzMsImV4cCI6MTUyMTE1NjUzMywiYWNyIjoiMSIsImFpbyI6IkFWUUFxLzhHQUFBQUptVzkzTFd6dVArcGF
4ZzJPeGE1cGp2V1NXV1ZSVnd1ZXZ5QU5yMlNkc0tkQmFWNnNjcHZsbUpmT1dDOThscUJJMDhXdlB6cDdlenpJdzJLai9MdWdXWWdydH
hkM1lmaDlYSGpXeFVaWk9JPSIsImFtciI6WyJyc2EiXSwiYXBwaWQiOiJhYTY5ODM1OC0yMWEzLTRhYTQtYjI3OC1mMzI2NTMzMDUzZ
TkiLCJhcHBpZGFjciI6IjEiLCJlbWFpbCI6Im1pamlhbmdAbWljcm9zb2Z0LmNvbSIsImZhbWlseV9uYW1lIjoiSmlhbmciLCJnaXZl
bl9uYW1lIjoiTWlhbyIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDE
xZGI0Ny8iLCJpcGFkZHIiOiIxMzEuMTA3LjE3NC4xNDAiLCJuYW1lIjoiTWlhbyBKaWFuZyIsIm9pZCI6IjhiMTU4ZDEwLWVmZGItND
UxMS1iOTQzLTczOWZkYjMxNzAyZSIsInNjcCI6InVzZXJfaW1wZXJzb25hdGlvbiIsInN1YiI6IkFGaWtvWFk1TEV1LTNkbk1pa3Z3M
UJzQUx4SGIybV9IaVJjaHVfSEM1aGciLCJ0aWQiOiI0NDc4ODkyMC05Yjk3LTRmOGItODIwYS0yMTFiMTMzZDk1MzgiLCJ1bmlxdWVf
bmFtZSI6Im1pamlhbmdAbWljcm9zb2Z0LmNvbSIsInV0aSI6ImFQaTJxOVZ6ODBXdHNsYjRBMzBCQUEiLCJ2ZXIiOiIxLjAifQ.agGf
aegYRnGj6DM_-
N_eYulnQdXHhrsus45QDuApirETDR2P2aMRxRioOCR2YVwn8pmpQ1LoAhddcYMWisrw_qhaQr0AYsDPWRtJ6x0hDk5teUgbix3gazb7
F-TVcC1gXpc9y7j77Ujxcq9z0r5lF65Y9bpNSefn9Te6GZYG7BgKEixqC4W6LqjtcjuOuW-
ouy6LSSox71Fj4Ni3zkGfxX1T_jiOvQTd6BBltSrShDm0bTMefoyX8oqfMEA2ziKjwvBFrOjO0uK4rJLgLYH4qvkR0bdF9etdstqKMo
5gecarWHNzWi_tghQu9aE3Z3EZdYNI_ZGM-Bbe3pkCfvEOyA
5. Seleccione Enviar y podrá llamar a la API correctamente.
Configurar una directiva de validación de JWT para autorizar

previamente las solicitudes
En este momento, si un usuario intenta realizar una llamada desde la consola del desarrollador, se le pide al
usuario que inicie sesión. La consola del desarrollador obtiene un token de acceso en nombre del usuario.
Sin embargo, ¿qué ocurre si alguien llama a la API sin un token o con uno no válido? Por ejemplo, puede seguir
llamando a la API incluso si elimina el encabezado Authorization . La razón es que API Management no valida el
token de acceso en este momento. Simplemente pasa el encabezado Authorization a la API de back-end.
La directiva de validación de JWT se puede usar para autorizar previamente las solicitudes en API Management, al
validarse los tokens de acceso de cada solicitud entrante. Si una solicitud no tiene un token válido, API
Management la bloquea. Por ejemplo, puede agregar la directiva siguiente a la sección de la directiva <inbound>
de Echo API . Comprueba la notificación de audiencia en un token de acceso y devuelve un mensaje de error si el
token no es válido. Para información sobre cómo configurar directivas, consulte el artículo sobre edición o
establecimiento de directivas.
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-

message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>{Application ID of backend-app}</value>
</claim>
</required-claims>
</validate-jwt>
Compilación de una aplicación para llamar a la API

En esta guía, se utiliza la consola del desarrollador en API Management como la aplicación de cliente de ejemplo
para llamar a Echo API protegido por OAuth 2.0. Para más información sobre cómo compilar una aplicación e
implementar OAuth 2.0, consulte Ejemplos de código de Azure Active Directory.
Pasos siguientes
Obtenga más información sobre Escenarios de autenticación para Azure AD.
Consulte más vídeos sobre la administración de API.
Para conocer otras formas de proteger el servicio back-end, consulte Autenticación de certificado mutua.
Creación de una instancia del servicio de API Management.
Administración de su primera API en Administración de API de Azure.
Usar Azure API Management con redes virtuales
Azure Virtual Network (VNET) le permiten colocar cualquier recurso de Azure en una red que se pueda enrutar
distinta de Internet y a la que controla el acceso. Después, estas redes se pueden conectar a sus redes locales
mediante diversas tecnologías de VPN. Para más información sobre Azure Virtual Network, vea: Información
general sobre Azure Virtual Network.
Azure API Management se puede implementar dentro de la red virtual (VNET), por lo que puede tener acceso a
los servicios back-end dentro de la red. El portal para desarrolladores y la puerta de enlace de API pueden
configurarse para que sea accesible desde Internet o solo dentro de la red virtual.
NOTE
Azure API Management admite redes virtuales clásicas y de Azure Resource Manager.
NOTE
Disponibilidad
IMPORTANT
Esta característica está disponible únicamente en los niveles Premium y Desarrollador de API Management.
Requisitos previos
Una instancia de APIM. Para más información, vea Creación de una instancia de Azure API Management.
Habilitar la conexión de VNET

Habilitación de la conectividad de VNET mediante Azure Portal
2. Seleccione Virtual Network.
3. Configure la instancia de API Management que se va a implementar dentro de la red virtual.
4. Seleccione el tipo de acceso que prefiera:
Externo: la puerta de enlace de API Management y el portal para desarrolladores son accesibles
públicamente desde Internet con un equilibrador de carga externo. La puerta de enlace puede
acceder a recursos dentro de la red virtual.
Interno: la puerta de enlace de API Management y el portal para desarrolladores solo son accesibles
desde la red virtual con un equilibrador de carga interno. La puerta de enlace puede acceder a
recursos dentro de la red virtual.
Ahora verá una lista de todas las regiones donde se aprovisiona el servicio Administración de API.
Seleccione una VNET y la subred de cada región. La lista se rellena con redes virtuales de Resource
Manager y clásicas disponibles en las suscripciones de Azure que se configuran en la región que va a
configurar.
NOTE
El punto de conexión de servicio en el diagrama anterior incluye la puerta de enlace o proxy, Azure Portal,
el portal para desarrolladores, el portal para editores, GIT y el punto de conexión de administración directa.
Punto de conexión de administración en el diagrama anterior es el punto de conexión hospedado en el
servicio para administrar la configuración mediante Azure Portal y Powershell. Además, tenga en cuenta que,
aunque el diagrama muestra las direcciones IP para sus diversos puntos de conexión, el servicio API
Management solo responde en sus nombres de host configurados.
IMPORTANT
Al implementar una instancia de Azure API Management en una VNET de Resource Manager, el servicio debe
estar en una subred dedicada que no contiene ningún otro recurso excepto instancias de Azure API
Management. Si se intenta implementar una instancia de Azure API Management en una subred de VNET de
Resource Manager que contiene otros recursos, se producirá un error en la implementación.
5. Haga clic en Guardar en la barra de navegación superior.
6. Haga clic en Aplicar configuración de red en la barra de navegación superior.
NOTE
Tenga en cuenta que la dirección VIP de la instancia de API Management cambiará cada vez que se habilita o deshabilita
VNET. La dirección VIP también cambia cuando se mueve API Management de externo a interno o viceversa.
IMPORTANT
Si elimina API Management de una red virtual o cambia aquella en la que se implementa, la red virtual usada anteriormente
puede permanecer bloqueada hasta dos horas. Durante este periodo no será posible eliminar la red virtual ni implementar un
nuevo recurso en ella.
Habilitar una conexión de VNET con cmdlets de PowerShell

También puede habilitar la conectividad de VNET con los cmdlets de PowerShell
Crear un servicio de API Management dentro de una red virtual: use el cmdlet New -
AzApiManagement para crear un servicio Azure API Management dentro de una red virtual.
Implementar un servicio existente de API Management dentro de una VNET: use el cmdlet Update-
AzApiManagementRegion para mover un servicio Azure API Management existente dentro de una red
virtual.
Conectar a un servicio web hospedado en una red virtual

Después de conectar el servicio API Management a la VNET, se accede a los servicios de back-end de la misma
forma que a los servicios públicos. Solo tiene que escribir la dirección IP local o el nombre de host (si se ha
configurado un servidor DNS para la VNET) del servicio web en el campo Dirección URL de servicio web al
crear una API o editar una existente.
Problemas comunes de configuración de red
A continuación se muestra una lista de problemas de errores de configuración comunes que pueden producirse al
implementar el servicio de API Management en una red virtual.
Configuración del servidor DNS personalizado: el servicio de API Management depende de varios
servicios de Azure. Cuando API Management está hospedado en una red virtual con un servidor DNS
personalizado, necesita resolver los nombres de host de esos servicios de Azure. Siga estas instrucciones sobre
la configuración de DNS personalizado. Vea la siguiente tabla de puertos y otros requisitos de red a efectos de
referencia.
IMPORTANT
Si planea utilizar un servidor DNS personalizado para la red virtual, debe configurarlo antes de implementar en él un servicio
API Management. En caso contrario, deberá actualizar el servicio API Management cada vez que cambie los servidores DNS
mediante la ejecución de la operación Aplicar configuración de red
Puertos necesarios para API Management: el tráfico entrante y saliente en la subred en la que se
implementa API Management puede controlarse mediante el grupo de seguridad de red. Si alguno de estos
puertos no está disponible, es posible que API Management no funcione correctamente y sea inaccesible. Tener
bloqueados uno o varios de estos puertos es otro problema común de una configuración incorrecta cuando se
usa API Management con una red virtual.
Cuando la instancia del servicio API Management se hospeda en una red virtual, se usan los puertos de la tabla
siguiente.
ETIQUETAS DE
PUERTOS DE PROTOCOLO DE SERVICIO TIPO DE RED
ORIGEN/DESTINO DIRECCIÓN TRANSPORTE ORIGEN/DESTINO PROPÓSITO (*) VIRTUAL
* / 80, 443 Entrada TCP INTERNET/VIRTU Comunicación de Externo

AL_NETWORK cliente con
Administración
de API
* / 3443 Entrada TCP ApiManagement Punto de Externa e interna

/ conexión de
VIRTUAL_NETWO administración
RK para Azure Portal
y Powershell
* / 80, 443 Salida TCP VIRTUAL_NETWO Dependencia de Externa e interna

RK/Storage Azure Storage
* / 80, 443 Salida TCP VIRTUAL_NETWO Azure Active Externa e interna

RK / Directory (si
AzureActiveDirect procede)
ory
* / 1433 Salida TCP VIRTUAL_NETWO Acceso a los Externa e interna

RK / SQL puntos de
conexión de
Azure SQL
* / 5672 Salida TCP VIRTUAL_NETWO Dependencia de Externa e interna

RK/EventHub la directiva de
registro en el
centro de
eventos y el
agente de
supervisión
* / 445 Salida TCP VIRTUAL_NETWO Dependencia del Externa e interna

RK/Storage recurso
compartido de
archivos de Azure
para Git
* / 1886 Salida TCP VIRTUAL_NETWO Se necesita para Externa e interna

RK/INTERNET publicar el estado
de
mantenimiento
en Resource
Health
* / 443 Salida TCP VIRTUAL_NETWO Publicar registros Externa e interna

RK / de diagnóstico y
AzureMonitor métricas
*/25 Salida TCP VIRTUAL_NETWO Conexión a la Externa e interna

RK/INTERNET retransmisión de
SMTP para enviar
correos
electrónicos
ETIQUETAS DE
PUERTOS DE PROTOCOLO DE SERVICIO TIPO DE RED
ORIGEN/DESTINO DIRECCIÓN TRANSPORTE ORIGEN/DESTINO PROPÓSITO (*) VIRTUAL
*/587 Salida TCP VIRTUAL_NETWO Conexión a la Externa e interna

SMTP para enviar
correos
electrónicos
* / 25028 Salida TCP VIRTUAL_NETWO Conexión a la Externa e interna

SMTP para enviar
correos
electrónicos
* / 6381 - 6383 Entrada y salida TCP VIRTUAL_NETWO Acceso a Externa e interna

RK/VIRTUAL_NET instancias de
WORK Azure Cache for
Redis entre
RoleInstances
*/* Entrada TCP AZURE_LOAD_BA Equilibrador de Externa e interna

LANCER / carga de la
VIRTUAL_NETWO infraestructura de
RK Azure
IMPORTANT
Los puertos para los que el Propósito está en negrita son necesarios para que el servicio API Management se implemente
correctamente. Sin embargo, si se bloquean los otros puertos, se producirá la degradación de la capacidad de usar y
supervisar el servicio en ejecución.
Funcionalidad SSL: para permitir la creación y validación de la cadena de certificados SSL, el servicio API
Management necesita conectividad de red saliente a ocsp.msocsp.com, mscrl.microsoft.com y
crl.microsoft.com. Esta dependencia no es obligatoria, si los certificados que cargue en API Management
contienen la cadena completa de la raíz de la entidad de certificación.
Acceso DNS: Se requiere acceso saliente en el puerto 53 para establecer la comunicación con los
servidores DNS. Si existe un servidor DNS personalizado en el otro punto de conexión de una puerta de
enlace de VPN, el servidor DNS debe estar accesible desde la subred que alberga la API Management.
Supervisión de métricas y estado: conexión de red saliente a puntos de conexión de supervisión de
Azure, que se resuelven en los siguientes dominios:
ENTORNO DE AZURE PUNTOS DE CONEXIÓN
Azure Public prod.warmpath.msftcloudes.com

shoebox2.metrics.nsatc.net
prod3.metrics.nsatc.net
prod3-black.prod3.metrics.nsatc.net
prod3-red.prod3.metrics.nsatc.net
prod.warm.ingestion.msftcloudes.com
azure region .warm.ingestion.msftcloudes.com
donde East US 2 es
eastus2.warm.ingestion.msftcloudes.com
ENTORNO DE AZURE PUNTOS DE CONEXIÓN
Azure Government fairfax.warmpath.usgovcloudapi.net

Azure China mooncake.warmpath.chinacloudapi.cn

Retransmisión de SMTP: conectividad de red de salida para la retransmisión de SMTP, que se resuelve en
el host smtpi-co1.msn.com , smtpi-ch1.msn.com , smtpi-db3.msn.com , smtpi-sin.msn.com y
ies.global.microsoft.com .
CAPTCHA del portal para desarrolladores: conectividad de red saliente para el CAPTCHA del portal
para desarrolladores, que se resuelve en el host client.hip.live.com .
Diagnósticos de Azure Portal: para permitir el flujo de registros de diagnóstico desde Azure Portal al usar
la extensión API Management desde dentro de una red Virtual, se requiere el acceso saliente a
dc.services.visualstudio.com en el puerto 443. Esto ayuda a solucionar los problemas que pueden surgir al
usar la extensión.
Forzar la tunelización del tráfico al firewall local mediante la aplicación virtual de red o de
Express Route: Una configuración común de los clientes es definir su propia ruta predeterminada
(0.0.0.0.0/0) que fuerza a todo el tráfico de la subred delegada de API Management a pasar a través de un
firewall local o a un dispositivo virtual de red. El flujo de tráfico interrumpe invariablemente la conectividad
con Azure API Management porque el tráfico saliente está bloqueado de forma local o porque se usa NAT
para convertirlo en un conjunto de direcciones irreconocibles que no funcionan con varios puntos de
conexión de Azure. La solución requiere que se hagan un par de cosas:
Habilite los puntos de conexión de servicio en la subred en la que se ha implementado el servicio API
Management. Los puntos de conexión de servicio debe habilitarse para Azure SQL, Azure Storage,
Azure Event Hubs y Azure ServiceBus. La habilitación de los puntos de conexión directamente desde
la subred delegada de API Management a estos servicios les permite utilizar la red troncal de
Microsoft Azure, que proporciona un enrutamiento óptimo para el tráfico de servicios. Si usa puntos
de conexión de servicio con una API Management con túnel forzado, el tráfico de servicios de Azure
anterior no se enruta a través de tunelización forzada. El resto del tráfico de dependencia del servicio
API Management se enruta con tunelización forzada y no se puede perder o este servicio no
funcionaría correctamente.
Todo el tráfico del plano de control desde Internet al punto de conexión de administración del
servicio API Management se enruta a través de un conjunto específico de IP de entrada hospedadas
en API Management. Cuando el tráfico se produce con tunelización forzada, no se asignarán
simétricamente las respuestas a estas direcciones IP de origen de entrada. Para superar la limitación,
necesitamos agregar las siguientes rutas definidas por el usuario (UDR ) para dirigir el tráfico de
vuelta a Azure mediante el establecimiento del destino de estas rutas de host a "Internet". El conjunto
de direcciones IP de entrada para el tráfico del plano de control es como sigue:
13.84.189.17/32, 13.85.22.63/32, 23.96.224.175/32, 23.101.166.38/32, 52.162.110.80/32,

104.214.19.224/32, 13.64.39.16/32, 40.81.47.216/32, 51.145.179.78/32, 52.142.95.35/32,
40.90.185.46/32, 20.40.125.155/32
Para otras dependencias de servicios API Management con tunelización forzada, debería haber una
forma de resolver el nombre de host y llegar hasta el punto de conexión. Entre ellas se incluyen las
siguientes:
Supervisión de métricas y estado
Diagnósticos de Azure Portal
Retransmisión de SMTP
CAPTCHA del portal para desarrolladores
Solución de problemas
Programa de instalación inicial: cuando la implementación inicial del servicio API Management en una
subred no se realiza correctamente, se recomienda implementar una máquina virtual en la misma subred.
Siga con el escritorio remoto en la máquina virtual y compruebe que hay conectividad al menos con cada
recurso que abarca su suscripción de Azure
Azure Storage Blob
Azure SQL Database
Tabla de Azure Storage
IMPORTANT
Una vez que valide la conectividad, asegúrese de quitar todos los recursos implementados en la subred, antes de
implementar API Management en ella.
Actualizaciones incrementales: Al realizar cambios en la red, consulte NetworkStatus API para validar si
el servicio API Management no ha perdido el acceso a cualquiera de los recursos críticos de los que
depende. El estado de conectividad debe actualizarse cada 15 minutos.
Vínculos de navegación de recursos: cuando se implementan en la subred de red virtual del estilo de
Resource Manager, API Management reserva la subred creando un vínculo de navegación de recursos. Si la
subred ya contiene un recurso de un proveedor distinto, la implementación producirá un error. De forma
similar, al eliminar un servicio API Management o moverlo a una subred diferente, se quitará ese vínculo de
navegación de recursos.
Requisitos de tamaño de subred

Azure reserva algunas direcciones IP dentro de cada subred y estas direcciones no se pueden usar. La primera y la
última dirección IP de las subredes están reservadas para la conformidad con el protocolo, junto con otras tres
direcciones usadas para los servicios de Azure. Para más información, consulte ¿Hay alguna restricción en el uso
de direcciones IP dentro de estas subredes?
Además de las direcciones IP que usa la infraestructura de Azure VNET, cada instancia de API Management de la
subred usa dos direcciones IP por unidad de SKU Premium y una dirección IP adicional para la SKU de
desarrollador. Cada instancia reserva una dirección IP adicional para el equilibrador de carga externo. Cuando se
implementa en la red virtual interna, requiere una dirección IP adicional para el equilibrador de carga interno.
Dado el cálculo anterior, el tamaño mínimo de la subred en la que se puede implementar API Management es/29,
que proporciona tres direcciones IP.
Enrutamiento
También se reservará una dirección IP pública (VIP ) con equilibrio de carga para proporcionar acceso a todos
los puntos de conexión del servicio.
Se usará una dirección IP de un intervalo de IP de subred (DIP ) para el acceso a los recursos dentro de la red
virtual y una dirección IP pública (VIP ) para el acceso a los recursos fuera de la red virtual.
La dirección IP pública con equilibrio de carga puede encontrarse en la hoja Información general/nformación
esencial en Azure Portal.
Limitaciones
Una subred que contenga instancias de API Management no puede contener otros tipos de recursos de Azure.
La subred y el servicio API Management tienen que estar en la misma suscripción.
Una subred que contenga instancias de API Management no se puede mover a otras suscripciones.
Para implementaciones de API Management de varias regiones configuradas en el modo de red virtual interna,
los usuarios son responsables de administrar el equilibrio de carga a través de varias regiones, ya que son los
propietarios del enrutamiento.
La conectividad de un recurso en una VNET emparejada globalmente a otra región con el servicio API
Management en modo interno no funciona debido a la limitación de la plataforma. Para obtener más
información, consulte el apartado Los recursos en una red virtual no pueden comunicarse con la dirección IP de
un equilibrador de carga interno de Azure en la red virtual emparejada.
Contenido relacionado
Conexión de una red virtual a back-end mediante VPN Gateway
Conexión a una red virtual a partir de diferentes modelos de implementación
Uso de API Inspector para hacer un seguimiento de las llamadas en Azure API Management
Preguntas más frecuentes acerca de Virtual Network
Etiquetas de servicio
Uso del servicio Azure API Management con una red
virtual interna
Con Azure Virtual Network, Azure API Management puede administrar las API que no están accesibles desde
Internet. Para establecer la conexión, hay una serie de tecnologías de VPN disponibles. API Management puede
implementarse de dos modos en una red virtual:
Externo
Interno
Cuando API Management se implementa en el modo de red virtual interna, todos los puntos de conexión de
servicio (puerta de enlace, portal del desarrollador, Azure Portal, administración directa y Git) solamente están
visibles en una red virtual en la que usted controla el acceso. Ninguno de los puntos de conexión de servicio está
registrado en el servidor DNS público.
Si utiliza API Management en modo interno, puede conseguir los siguientes escenarios:
Puede conseguir que terceras personas puedan obtener acceso de forma segura a las API hospedadas en el
centro de datos privado desde fuera de este centro utilizando conexiones de sitio a sitio o conexiones de VPN
de Azure ExpressRoute.
Puede permitir escenarios de nube híbrida exponiendo las API basadas en la nube y las API locales a través de
una puerta de enlace común.
Puede administrar las API hospedadas en varias ubicaciones geográficas mediante un único punto de conexión
de puerta de enlace.
Disponibilidad
IMPORTANT
Requisitos previos
Una suscripción activa a Azure.
Una instancia de Azure API Management. Para más información, vea Creación de una instancia de
Cuando se implementa un servicio API Management en una red virtual, un lista de puertos se usan y deben
estar abiertos.
Creación de una instancia de API Management en una red virtual

interna
El servicio API Management en una red virtual interna se hospeda detrás de un equilibrador de carga interno
(clásico). Esta es la única opción disponible y no se puede cambiar.
Habilitación de una conexión de red virtual mediante Azure Portal
1. Navegue a la instancia de Azure API Management en Azure Portal.
2. Seleccione Red virtual.
3. Configure la instancia de API Management que se va a implementar dentro de la red virtual.
Después de la implementación se realiza correctamente, debería ver privada dirección IP virtual y pública
dirección IP virtual del servicio API Management en la hoja de información general. El privada dirección IP virtual
es una carga equilibrada de la dirección IP desde dentro de la API de administración delegada subred sobre qué
gateway , portal , management y scm pueden tener acceso a los puntos de conexión. El pública se utiliza la
dirección IP virtual sólo para controlar el tráfico del plano a management punto de conexión de puerto 3443 y
puede bloquearse hasta el [ApiManagement] ServiceTags servicetag.
NOTE
La consola de prueba disponible en Azure Portal no funcionará con un servicio implementado en una red virtual interna, ya
que la dirección Url de puerta de enlace no está registrada en el DNS público. En su lugar, debe usar la consola de prueba que
se ofrece en el Portal para desarrolladores.
Habilitación de una conexión de red virtual mediante cmdlets de PowerShell

NOTE
También puede habilitar la conectividad de la red virtual utilizando cmdlets de PowerShell.

Crear un servicio API Management dentro de una red virtual: Use el cmdlet New AzApiManagement para
crear un servicio de Azure API Management dentro de una red virtual y configúrelo para utilizar el tipo de
red virtual interna.
Actualizar una implementación existente de un servicio API Management dentro de una red virtual: Use el
cmdlet actualización AzApiManagementRegion para mover un servicio API Management existente en una
red virtual y configúrelo para utilizar el tipo de red virtual interna.
Configuración de DNS
Cuando API Management está en modo de red virtual externa, el DNS está administrado por Azure. En el modo
de red virtual interna, es usted quien tiene que administrar su propio enrutamiento.
NOTE
El servicio API Management no escucha las solicitudes procedentes de direcciones IP. Solo responde a las solicitudes dirigidas
al nombre de host establecido en los puntos de conexión de servicio. Estos puntos de conexión pueden ser la puerta de
enlace, Azure Portal y el portal del desarrollador, el punto de conexión de administración directa y GIT.
Acceso de nombres de host predeterminados

Cuando se crea un servicio API Management, denominado "contosointernalvnet" por ejemplo, los siguientes
extremos de servicio se configuran de forma predeterminada:
Puerta de enlace o proxy: contosointernalvnet.azure-api.net
El portal de Azure y el portal para desarrolladores: contosointernalvnet.portal.azure-api.net
Direct management endpoint: contosointernalvnet.management.azure-api.net
Git: contosointernalvnet.scm.azure-api.net
Para obtener acceso a estos puntos de conexión de servicio de API Management, puede crear una máquina virtual
en una subred conectada a la red virtual en la que está implementado API Management. Suponiendo que la
dirección IP virtual interna para el servicio es 10.1.0.5, puede asignar el archivo de hosts, %
SystemDrive%\drivers\etc\hosts, como se indica a continuación:
10.1.0.5 contosointernalvnet.azure-api.net
10.1.0.5 contosointernalvnet.portal.azure-api.net
10.1.0.5 contosointernalvnet.management.azure-api.net
10.1.0.5 contosointernalvnet.scm.azure-api.net
Así, podrá tener acceso a todos los puntos de conexión de servicio desde la máquina virtual que ha creado. Si
utiliza un servidor DNS personalizado en una red virtual, también puede crear registros D de DNS y acceder a
estos puntos de conexión desde cualquier lugar de la red virtual.
Acceso de nombres de dominio personalizados
1. Si no quiere acceder al servicio API Management con los nombres de host predeterminados, puede definir
nombres de dominio personalizados para todos los puntos de conexión de servicio, tal y como se indica en
la siguiente ilustración:
2. A continuación, puede crear registros en el servidor DNS para acceder a los puntos de conexión que solo
están accesibles desde dentro de la red virtual.
Enrutamiento
Se reservará una dirección IP virtual privada con equilibrio de carga desde el intervalo de subred y se utilizará
para tener acceso a los puntos de conexión del servicio API Management desde la red virtual.
También se reservará una dirección IP pública (VIP ) con equilibrio de carga para proporcionar acceso al punto
de conexión del servicio de administración solo a través del puerto 3443.
Se usará una dirección IP de un intervalo de IP de subred (DIP ) para el acceso a los recursos dentro de la red
virtual y una dirección IP pública (VIP ) para el acceso a los recursos fuera de la red virtual.
Las direcciones IP privadas y públicas con equilibrio de carga pueden encontrarse en la hoja Información
general/nformación esencial en Azure Portal.
Contenido relacionado
Para obtener más información, consulte los artículos siguientes:
Problemas comunes de configuración de red al establecer Azure API Management en una red virtual
Preguntas más frecuentes (P+F ) acerca de Azure Virtual Network
Creating a record in DNS (Creación de un registro en DNS )
Integración de API Management en una red virtual
interna con Application Gateway
El servicio API Management se puede configurar en una red virtual en modo interno, para que sea accesible
únicamente desde dentro de la red virtual. Azure Application Gateway es un servicio PAAS que proporciona un
equilibrador de carga de nivel 7. Actúa como un servicio de proxy inverso y proporciona entre su oferta un firewall
de aplicaciones web (WAF ).
La combinación de una instancia de API Management aprovisionada en una red virtual interna con el front-end de
Application Gateway permite los siguientes escenarios:
Utilizar el mismo recurso de API Management para su uso por los consumidores internos y los consumidores
externos.
Utilizar un único recurso de API Management y tener definido un subconjunto de API en API Management
disponible para los consumidores externos.
Proporcionar una solución de llave en mano para activar y desactivar el acceso a API Management desde la red
Internet pública.
Disponibilidad
IMPORTANT
Requisitos previos
NOTE
Certificados pfx y cer para el nombre de host de API y pfx para el nombre de host del portal para
desarrolladores.
Escenario
En este artículo se explica cómo usar un único servicio de API Management para los consumidores tanto internos
como externos y hacer que actúe como un único servidor de front-end para las API locales y en la nube. También
verá cómo exponer solamente un subconjunto de las API (resaltado en verde en el ejemplo) para permitir su uso
externo, usando para ello la funcionalidad de enrutamiento disponible en Application Gateway.
En el primer ejemplo de la configuración, todas las API se administran únicamente desde dentro de la red virtual.
Los consumidores internos (resaltados en color naranja) pueden tener acceso a todas las API internas y externas. El
tráfico nunca sale a Internet. La conectividad de alto rendimiento se proporciona mediante circuitos ExpressRoute.
Antes de empezar
Asegúrese de que está usando la versión más reciente de Azure PowerShell. Consulte las instrucciones de
instalación en Instalación de Azure PowerShell.
¿Qué se necesita para crear una integración entre API Management y

Application Gateway?
Grupo de servidores back-end: se trata de la dirección IP virtual interna del servicio API Management.
Configuración del grupo de servidores back-end: cada grupo tiene una configuración como el puerto, el
protocolo y la afinidad basada en las cookies. Estos valores se aplican a todos los servidores del grupo.
Puerto de front-end: es el puerto público que se abre en la puerta de enlace de aplicaciones. El tráfico que
llega se redirige a uno de los servidores back-end.
Agente de escucha: tiene un puerto front-end, un protocolo (Http o Https, estos valores distinguen
mayúsculas de minúsculas) y el nombre del certificado SSL (si se configura la descarga de SSL ).
Regla: la regla enlaza un agente de escucha con un grupo de servidores back-end.
Sondeo de estado personalizado: de forma predeterminada, Application Gateway usa sondeos basados en
direcciones IP para determinar cuáles son los servidores de BackendAddressPool que están activos. El servicio
API Management responde solo a las solicitudes con el encabezado de host correcto, por lo tanto, los sondeos
predeterminados no podrán completarse. Es necesario definir el sondeo de mantenimiento personalizado para
ayudar a la puerta de enlace de aplicaciones a determinar que el servicio está activo y debe reenviar las
solicitudes.
Certificados de dominio personalizado: para tener acceso a API Management desde Internet, debe crear
una asignación de CNAME entre el nombre de host y el nombre DNS del front-end de Application Gateway.
Esto garantiza que el encabezado de nombre de host y el certificado enviados a Application Gateway que se
reenvían a API Management pueden ser reconocidos como válidos por APIM. En este ejemplo, usaremos dos
certificados: uno para el back-end y otro para el portal para desarrolladores.
Pasos necesarios para integrar API Management y Application Gateway
1. Cree un grupo de recursos para Resource Manager.
2. Cree una red virtual, una subred y una IP pública para Application Gateway. Cree otra subred para API
Management.
3. Cree un servicio API Management en la subred de la red virtual creada anteriormente y asegúrese de que usa
el modo interno.
4. Configure un nombre de dominio personalizado en el servicio API Management.
5. Cree un objeto de configuración de Application Gateway.
6. Cree un recurso de Application Gateway.
7. Cree un CNAME del nombre DNS público de Application Gateway en el nombre de host de proxy de API
Management.
Exposición del portal para desarrolladores externamente mediante

Application Gateway
En esta guía también se expondrá el portal para desarrolladores a audiencias externas mediante Application
Gateway. Para ello es necesario realizar pasos adicionales para crear el agente de escucha del portal para
desarrolladores, el sondeo, la configuración y las reglas. Todos los detalles se proporcionan en los pasos
correspondientes.
WARNING
Si usa Azure AD o un método de autenticación de terceros, habilite la característica de afinidad de sesión basada en cookies
de Application Gateway.
Creación de un grupo de recursos para Resource Manager

Paso 1
Connect-AzAccount
Autentíquese con sus credenciales.

Paso 2
Seleccione la suscripción deseada.
$subscriptionId = "00000000-0000-0000-0000-000000000000" # GUID of your Azure subscription

Get-AzSubscription -Subscriptionid $subscriptionId | Select-AzSubscription
Paso 3
Cree un grupo de recursos (omita este paso si usa uno existente).
$resGroupName = "apim-appGw-RG" # resource group name

$location = "West US" # Azure region
New-AzResourceGroup -Name $resGroupName -Location $location
Azure Resource Manager requiere que todos los grupos de recursos especifiquen una ubicación. Esta se utiliza
como ubicación predeterminada para los recursos de ese grupo de recursos. Asegúrese de que todos los
comandos para crear una puerta de enlace de aplicaciones usan el mismo grupo de recursos.
Creación de una red virtual y una subred para la puerta de enlace de

aplicaciones
En el ejemplo siguiente se muestra cómo crear una red virtual con Resource Manager:
Paso 1
Asigne el intervalo de direcciones 10.0.0.0/24 a la variable subnet que se va a usar para Application Gateway al
crear la red virtual.
$appgatewaysubnet = New-AzVirtualNetworkSubnetConfig -Name "apim01" -AddressPrefix "10.0.0.0/24"
Paso 2
Asigne el intervalo de direcciones 10.0.1.0/24 a la variable subnet que se va a usar para API Management al crear
la red virtual.
$apimsubnet = New-AzVirtualNetworkSubnetConfig -Name "apim02" -AddressPrefix "10.0.1.0/24"
Paso 3
Cree una red virtual llamada appgwvnet en el grupo de recursos apim -appGw-RG para la región Oeste de EE.
UU. Use el prefijo 10.0.0.0/16 con las subredes 10.0.0.0/24 y 10.0.1.0/24.
$vnet = New-AzVirtualNetwork -Name "appgwvnet" -ResourceGroupName $resGroupName -Location $location -

AddressPrefix "10.0.0.0/16" -Subnet $appgatewaysubnet,$apimsubnet
Paso 4
Asigne una variable de subred para los pasos siguientes.
$appgatewaysubnetdata = $vnet.Subnets[0]
$apimsubnetdata = $vnet.Subnets[1]
Cree un servicio de API Management dentro de una red virtual

configurada en modo interno.
En el ejemplo siguiente se muestra cómo crear un servicio de API Management en una red virtual configurada
únicamente para el acceso interno.
Paso 1
Cree un objeto de red virtual de API Management con la subred $apimsubnetdata creada anteriormente.
$apimVirtualNetwork = New-AzApiManagementVirtualNetwork -SubnetResourceId $apimsubnetdata.Id
Paso 2
Cree un servicio de API Management dentro de la red virtual.
$apimServiceName = "ContosoApi" # API Management service instance name
$apimOrganization = "Contoso" # organization name
$apimAdminEmail = "[email protected]" # administrator's email address
$apimService = New-AzApiManagement -ResourceGroupName $resGroupName -Location $location -Name $apimServiceName
-Organization $apimOrganization -AdminEmail $apimAdminEmail -VirtualNetwork $apimVirtualNetwork -VpnType
"Internal" -Sku "Developer"
Cuando el comando anterior se complete con éxito, consulte la configuración de DNS necesaria para tener acceso
al servicio de API Management en una red virtual interna para tener acceso a él. Este paso puede tardar más de
media hora.
Configuración de un nombre de dominio personalizado en API

Management
Paso 1
Inicialice las variables siguientes con los detalles de los certificados con claves privadas para los dominios. En este
ejemplo, usaremos api.contoso.net y portal.contoso.net .
$gatewayHostname = "api.contoso.net" # API gateway host

$portalHostname = "portal.contoso.net" # API developer portal host
$gatewayCertCerPath = "C:\Users\Contoso\gateway.cer" # full path to api.contoso.net .cer file
$gatewayCertPfxPath = "C:\Users\Contoso\gateway.pfx" # full path to api.contoso.net .pfx file
$portalCertPfxPath = "C:\Users\Contoso\portal.pfx" # full path to portal.contoso.net .pfx file
$gatewayCertPfxPassword = "certificatePassword123" # password for api.contoso.net pfx certificate
$portalCertPfxPassword = "certificatePassword123" # password for portal.contoso.net pfx certificate
$certPwd = ConvertTo-SecureString -String $gatewayCertPfxPassword -AsPlainText -Force

$certPortalPwd = ConvertTo-SecureString -String $portalCertPfxPassword -AsPlainText -Force
Paso 2
Cree y establezca los objetos de configuración del nombre de host para el servidor proxy y el portal.
$proxyHostnameConfig = New-AzApiManagementCustomHostnameConfiguration -Hostname $gatewayHostname -HostnameType

Proxy -PfxPath $gatewayCertPfxPath -PfxPassword $certPwd
$portalHostnameConfig = New-AzApiManagementCustomHostnameConfiguration -Hostname $portalHostname -HostnameType
Portal -PfxPath $portalCertPfxPath -PfxPassword $certPortalPwd
$apimService.ProxyCustomHostnameConfiguration = $proxyHostnameConfig
$apimService.PortalCustomHostnameConfiguration = $portalHostnameConfig
Set-AzApiManagement -InputObject $apimService
Creación de una dirección IP pública para la configuración del front-

end
Cree un recurso de IP pública publicIP01 en el grupo de recursos.
$publicip = New-AzPublicIpAddress -ResourceGroupName $resGroupName -name "publicIP01" -location $location -

AllocationMethod Dynamic
Se asigna una dirección IP a la puerta de enlace de aplicaciones cuando se inicia el servicio.
Creación de una configuración de puerta de enlace de aplicaciones

Se deben haber definido todos los elementos de configuración antes de crear la puerta de enlace de aplicaciones.
En los pasos siguientes, se crean los elementos de configuración necesarios para un recurso de puerta de enlace de
aplicaciones.
Paso 1
Cree una configuración de IP de puerta de enlace de aplicaciones denominada gatewayIP01. Cuando se inicia
Application Gateway, elige una dirección IP de la subred configurada y redirige el tráfico de red a las direcciones IP
en el grupo IP de back-end. Tenga en cuenta que cada instancia toma una dirección IP.
$gipconfig = New-AzApplicationGatewayIPConfiguration -Name "gatewayIP01" -Subnet $appgatewaysubnetdata
Paso 2
Configure el puerto IP de front-end para el punto de conexión de IP pública. Este puerto es el puerto al que se
conectan los usuarios finales.
$fp01 = New-AzApplicationGatewayFrontendPort -Name "port01" -Port 443
Paso 3
Configuración de la dirección IP de front-end con el punto de conexión de IP pública
$fipconfig01 = New-AzApplicationGatewayFrontendIPConfig -Name "frontend1" -PublicIPAddress $publicip
Paso 4
Configure el certificado para Application Gateway, que se usará para descifrar y volver a cifrar el tráfico que pasa
por ella.
$cert = New-AzApplicationGatewaySslCertificate -Name "cert01" -CertificateFile $gatewayCertPfxPath -Password

$certPwd
$certPortal = New-AzApplicationGatewaySslCertificate -Name "cert02" -CertificateFile $portalCertPfxPath -
Password $certPortalPwd
Paso 5
Cree los agentes de escucha HTTP para Application Gateway. Asígneles la configuración IP de front-end, el puerto
y los certificados SSL que se usarán.
$listener = New-AzApplicationGatewayHttpListener -Name "listener01" -Protocol "Https" -FrontendIPConfiguration

$fipconfig01 -FrontendPort $fp01 -SslCertificate $cert -HostName $gatewayHostname -RequireServerNameIndication
true
$portalListener = New-AzApplicationGatewayHttpListener -Name "listener02" -Protocol "Https" -
FrontendIPConfiguration $fipconfig01 -FrontendPort $fp01 -SslCertificate $certPortal -HostName $portalHostname
-RequireServerNameIndication true
Paso 6
Cree sondeos personalizados para el punto de conexión de dominio del proxy ContosoApi del servicio API
Management. La ruta de acceso /status-0123456789abcdef es un punto de conexión de mantenimiento
predeterminado hospedado en todos los servicios de API Management. Establezca api.contoso.net como un
nombre de host de sondeo personalizado para protegerlo con el certificado SSL.
NOTE
El nombre de host contosoapi.azure-api.net es el nombre de host de proxy predeterminado configurado cuando se crea
un servicio denominado contosoapi en el ámbito público de Azure.
$apimprobe = New-AzApplicationGatewayProbeConfig -Name "apimproxyprobe" -Protocol "Https" -HostName

$gatewayHostname -Path "/status-0123456789abcdef" -Interval 30 -Timeout 120 -UnhealthyThreshold 8
$apimPortalProbe = New-AzApplicationGatewayProbeConfig -Name "apimportalprobe" -Protocol "Https" -HostName
$portalHostname -Path "/signin" -Interval 60 -Timeout 300 -UnhealthyThreshold 8
Paso 7
Cargue el certificado que se usará en los recursos del grupo de back-end habilitado para SSL. Este es el mismo
certificado que ha proporcionado en el paso 4 anterior.
$authcert = New-AzApplicationGatewayAuthenticationCertificate -Name "whitelistcert1" -CertificateFile

$gatewayCertCerPath
Paso 8
Configure las opciones de back-end HTTP para Application Gateway. Esto incluye la configuración de un límite de
tiempo de espera para la solicitud de back-end después del cual se cancela. Este valor es distinto del tiempo de
espera del sondeo.
$apimPoolSetting = New-AzApplicationGatewayBackendHttpSettings -Name "apimPoolSetting" -Port 443 -Protocol

"Https" -CookieBasedAffinity "Disabled" -Probe $apimprobe -AuthenticationCertificates $authcert -RequestTimeout
180
$apimPoolPortalSetting = New-AzApplicationGatewayBackendHttpSettings -Name "apimPoolPortalSetting" -Port 443 -
Protocol "Https" -CookieBasedAffinity "Disabled" -Probe $apimPortalProbe -AuthenticationCertificates $authcert
-RequestTimeout 180
Paso 9:
Configure el grupo de direcciones IP de back-end denominado apimbackend con dirección IP virtual interna para
el servicio de API Management creado anteriormente.
$apimProxyBackendPool = New-AzApplicationGatewayBackendAddressPool -Name "apimbackend" -BackendIPAddresses

$apimService.PrivateIPAddresses[0]
Paso 10
Cree reglas para Application Gateway para usar el enrutamiento básico.
$rule01 = New-AzApplicationGatewayRequestRoutingRule -Name "rule1" -RuleType Basic -HttpListener $listener -

BackendAddressPool $apimProxyBackendPool -BackendHttpSettings $apimPoolSetting
$rule02 = New-AzApplicationGatewayRequestRoutingRule -Name "rule2" -RuleType Basic -HttpListener
$portalListener -BackendAddressPool $apimProxyBackendPool -BackendHttpSettings $apimPoolPortalSetting
TIP
Cambie el tipo de regla y el enrutamiento para restringir el acceso a determinadas páginas del portal para desarrolladores.
Paso 11
Configure el número de instancias y el tamaño de Application Gateway. En este ejemplo, usamos WAF SKU para
aumentar la seguridad de los recursos de API Management.
$sku = New-AzApplicationGatewaySku -Name "WAF_Medium" -Tier "WAF" -Capacity 2
Paso 12
Configuración de WAFS para que esté en modo "Prevención".
$config = New-AzApplicationGatewayWebApplicationFirewallConfiguration -Enabled $true -FirewallMode "Prevention"
Creación de la puerta de enlace de aplicaciones

Cree una instancia de Application Gateway con todos los objetos de configuración de los pasos anteriores.
$appgwName = "apim-app-gw"
$appgw = New-AzApplicationGateway -Name $appgwName -ResourceGroupName $resGroupName -Location $location -
BackendAddressPools $apimProxyBackendPool -BackendHttpSettingsCollection $apimPoolSetting,
$apimPoolPortalSetting -FrontendIpConfigurations $fipconfig01 -GatewayIpConfigurations $gipconfig -
FrontendPorts $fp01 -HttpListeners $listener, $portalListener -RequestRoutingRules $rule01, $rule02 -Sku $sku -
WebApplicationFirewallConfig $config -SslCertificates $cert, $certPortal -AuthenticationCertificates $authcert
-Probes $apimprobe, $apimPortalProbe
Aplicación de un CNAME al nombre de host del proxy de API

Management para el nombre DNS público del recurso de Application
Gateway
Una vez creada la puerta de enlace, el siguiente paso es configurar el front-end para la comunicación. Cuando se
utiliza una dirección IP pública, Application Gateway requiere un nombre DNS asignado dinámicamente, que
puede no ser fácil de usar.
El nombre DNS de Application Gateway se debe utilizar para crear un registro CNAME, que apunta el nombre de
host del proxy (por ejemplo, api.contoso.net en los ejemplos anteriores) a este nombre de DNS. Para configurar
el registro IP CNAME de front-end, recupere los detalles de Application Gateway y su nombre DNS o IP asociados
mediante el elemento PublicIPAddress. No se recomienda el uso de registros A, ya que la VIP puede cambiar al
reiniciarse la puerta de enlace.
Get-AzPublicIpAddress -ResourceGroupName $resGroupName -Name "publicIP01"
Resumen
El servicio Azure API Management configurado en una red virtual proporciona una interfaz de puerta de enlace
única para todas las API configuradas, independientemente de si están hospedadas de forma local o en la nube. La
integración de Application Gateway con API Management proporciona la flexibilidad de habilitar de manera
selectiva API determinadas para que estén accesibles en Internet, así como la provisión de un firewall de aplicación
web como front-end para la instancia de API Management.
Pasos siguientes
Obtenga más información sobre Azure Application Gateway.
Introducción a Puerta de enlace de aplicaciones
Firewall de aplicaciones web de Application Gateway
Application Gateway mediante enrutamiento basado en rutas de acceso
Más información acerca de API Management y redes virtuales
El uso de API Management solo está disponible en la red virtual
Usar Azure API Management con redes virtuales
Cómo asegurar servicios back-end con la
autenticación de certificados de cliente en Azure API
Management
API Management permite acceder de forma segura al servicio back-end de una API con certificados de cliente.
Esta guía muestra cómo administrar certificados del servicio Azure API Management en Azure Portal. También se
explica cómo configurar una API para que use un certificado para acceder a un servicio back-end.
Para obtener más información sobre cómo administrar certificados con la API de REST de API Management,
consulte Entidad de certificado de la API REST de Azure API Management.
Requisitos previos
NOTE
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.
Esta guía muestra cómo configurar la instancia de servicio de API Management para acceder al servicio back-end
de una API con la autenticación de certificados de cliente. Antes de seguir los pasos descritos en este artículo,
debe tener el servicio back-end configurado para la autenticación de certificados de cliente (para configurar la
autenticación de certificados en sitios web de Azure, consulte este artículo). Debe acceder al certificado y a la
contraseña para cargarlos al servicio API Management.
Cargar un certificado de cliente
Siga los pasos que se describen a continuación para cargar un nuevo certificado de cliente. Si todavía no ha
creado una instancia del servicio API Management, consulte el tutorial Creación de una instancia del servicio API
Management.
1. Vaya a la instancia del servicio Azure API Management en Azure Portal.
2. Seleccione Certificados de cliente en el menú.
4. Busque el certificado y proporcione su identificador y la contraseña.

NOTE
El certificado debe estar en formato .pfx . Se admiten los certificados autofirmados.
Una vez que se carga el certificado, aparece en la pestaña Certificados de cliente. Si tiene muchos certificados,
tome nota de la huella digital del certificado deseado con el fin de configurar una API para realizar la autenticación
de puerta de enlace con un certificado de cliente.
NOTE
Para desactivar la validación de la cadena de certificados cuando se utiliza, por ejemplo, un certificado autofirmado, siga los
pasos descritos en esta sección de preguntas más frecuentes.
Eliminar un certificado de cliente

Para eliminar un certificado, haga clic en el menú contextual ... y seleccione Eliminar junto a este.
Si alguna API está usando el certificado, aparecerá una pantalla de advertencia. Para eliminar el certificado,
primero quítelo de todas las API que se hayan configurado para usarlo.
Configurar una API para realizar la autenticación de puerta de enlace
con un certificado de cliente
1. Haga clic en API en el menú API Management de la izquierda y vaya a la API.
2. En la pestaña Diseño, haga clic en un icono de lápiz de la sección Backend.

3. Cambie las credenciales de puerta de enlace a certificado de cliente y seleccione el certificado en la
lista desplegable.
WARNING
Este cambio se hace efectivo de forma inmediata y llama a las operaciones de la API que realizarán la autenticación en el
servidor back-end con el certificado.
TIP
Cuando se especifica un certificado para la autenticación de puerta de enlace del servicio back-end de una API, el certificado
se integra en la directiva de dicha API y puede verse en el editor de directivas.
Certificados autofirmados
Si utiliza certificados autofirmados, tendrá que deshabilitar la validación de la cadena de certificados para que API
Management pueda comunicarse con el sistema back-end. De lo contrario, se producirá un error con el código
500. Para establecer esta configuración, puede utilizar los cmdlets de PowerShell New-AzApiManagementBackend (con
el nuevo back-end) o Set-AzApiManagementBackend (con el back-end existente) y establecer el parámetro
-SkipCertificateChainValidation en True .
$context = New-AzApiManagementContext -resourcegroup 'ContosoResourceGroup' -servicename 'ContosoAPIMService'

New-AzApiManagementBackend -Context $context -Url 'https://contoso.com/myapi' -Protocol http -
SkipCertificateChainValidation $true
Incorporación de un certificado de entidad de
certificación personalizado a Azure API
Management
Azure API Management permite instalar los certificados de entidad de certificación en la máquina dentro de los
almacenes de certificados intermedio y raíz de confianza. Esta funcionalidad debe usarse si los servicios requieren
un certificado de entidad de certificación personalizado.
En este artículo se muestra cómo administrar certificados de entidad de certificación de una instancia del servicio
Azure API Management en Azure Portal.
NOTE
Disponibilidad
IMPORTANT
Carga de un certificado de entidad de certificación
Siga los pasos que se describen a continuación para cargar un nuevo certificado de entidad de certificación. Si
todavía no ha creado una instancia del servicio API Management, consulte el tutorial Creación de una instancia
del servicio API Management.
2. Seleccione Certificados de entidad de certificado de entidad de certificación en el menú.
4. Busque el certificado y decida cuál es el almacén de certificados. Solo se necesita la clave pública, no la
contraseña.
5. Haga clic en Save(Guardar). Esta operación puede tardar algunos minutos.

NOTE
Puede cargar un certificado de entidad de certificación mediante el comando de Powershell
New-AzApiManagementSystemCertificate .
Eliminar un certificado de cliente

Para eliminar un certificado, haga clic en el menú contextual ... y seleccione Eliminar junto a este.
Administración de protocolos y cifrados en Azure API
Management
Azure API Management admite varias versiones del protocolo TLS para los lados cliente y back-end, así como el
cifrado 3DES.
Esta guía muestra cómo administrar la configuración de los protocolos y cifrados en una instancia de Azure API
Management.
Requisitos previos
Una instancia de API Management
Cómo administrar protocolos TLS y el cifrado 3DES

2. Seleccione Configuración del protocolo en el menú.
3. Habilite o deshabilite los protocolos o los cifrados que quiera.
4. Haga clic en Save(Guardar). Los cambios se aplicarán en el plazo de una hora.
Pasos siguientes
Obtenga más información sobre TLS (Seguridad de la capa de transporte).
Consulte más vídeos sobre la administración de API.
Acceso y personalización del nuevo portal para
desarrolladores en Azure API Management
Este artículo muestra cómo acceder al nuevo portal para desarrolladores de Azure API Management. Le guiará a
través de la experiencia del editor visual: incorporación y edición de contenido, así como personalización del
aspecto del sitio web.
Requisitos previos
Importe y publique una instancia de Azure API Management. Para más información, consulte Importación y
publicación.
Disponibilidad
IMPORTANT
NOTE
El nuevo portal para desarrolladores está actualmente en versión preliminar.
Versiones administradas y autohospedadas

Puede crear su portal para desarrolladores de dos maneras:
Versión administrada: mediante la edición y personalización del portal integrado en la instancia de API
Management y accesible a través de la dirección URL
<your-api-management-instance-name>.developer.azure-api.net .
Versión autohospedada: mediante la implementación y autohospedaje del portal fuera de una instancia de
API Management. Este enfoque le permite editar el código base del portal y ampliar la funcionalidad principal
proporcionada. Para obtener información detallada e instrucciones, consulte el repositorio de GitHub con el
código fuente del portal.
Acceso a la versión administrada del portal

Siga los pasos siguientes para acceder a la versión administrada del portal.
1. Vaya a la instancia de servicio de API Management en Azure Portal.
2. Haga clic en el botón New developer portal (preview) (Nuevo portal para desarrolladores: versión
preliminar) en la barra de navegación superior. Se abrirá una nueva pestaña del explorador con una versión
administrativa del portal. Si accede al portal por primera vez, se aprovisionará automáticamente el contenido
predeterminado.
Edición y personalización de la versión administrada del portal

En el siguiente vídeo se muestra cómo editar el contenido del portal, personalizar el aspecto del sitio web y
publicar los cambios.
Pasos siguientes
Más información acerca del nuevo portal para desarrolladores:
Repositorio de GitHub con el código fuente
Instrucciones sobre el autohospedaje del portal
Hoja de ruta pública del proyecto
Modificación del contenido y el diseño de páginas en
el portal para desarrolladores de Azure API
Management
Existen tres maneras fundamentales de personalizar el portal para desarrolladores en Azure API Management:
Editar el contenido de las páginas estáticas y los elementos de diseño de página (que se explica en esta guía)
Actualizar los estilos usados para los elementos de página en el portal para desarrolladores
productos, autenticación de usuario, etc.)
Disponibilidad
IMPORTANT
Estructura de las páginas del portal para desarrolladores

El portal para desarrolladores se basa en el sistema de administración de contenido. El diseño de cada página se
compila en función de un conjunto de pequeños elementos de página conocidos como widgets:
Todos los widgets son editables.

El contenido principal específico de cada página reside en el widget "Contenido". La edición de una página
significa modificar el contenido de este widget.
Todos los elementos de diseño de página están contenidos con los widgets restantes. Los cambios realizados
en estos widgets se aplican a todas las páginas. Se hace referencia a ellos como "widgets de diseño".
En las páginas del día a día, a menudo solo se modificaría el widget Contenido, que tendrá contenido diferente
para cada página.
Modificación del contenido de un widget de diseño

El portal para desarrolladores es accesible desde Azure Portal.
1. Haga clic en Portal para desarrolladores en la barra de herramientas de la instancia de API Management.
2. Para editar el contenido de los widgets, haga clic en el icono formado por dos pinceles en el menú del
portal Developer a la izquierda.
3. Para modificar el contenido del encabezado, desplácese hasta la sección Encabezado en la lista de la
izquierda.
Los widgets son editables dentro de los campos.
4. Una vez que esté preparado para publicar los cambios, haga clic en publicar en la parte inferior de la
página.
Ahora debe aparecer el nuevo encabezado en todas las páginas del portal para desarrolladores.
Pasos siguientes
productos, autenticación de usuario, etc.)
Cómo personalizar el portal para desarrolladores
de Azure API Management mediante plantillas
Existen tres maneras fundamentales de personalizar el portal para desarrolladores en Azure API
Management:
Editar el contenido de las páginas estáticas y los elementos de diseño de página
Modificar las plantillas que se usan para las páginas generadas por el portal de (que se explica en esta
guía)
Las plantillas se usan para personalizar el contenido de las páginas del portal para desarrolladores generadas
por el sistema (por ejemplo, documentos de API, productos, autenticación de usuario, etc.). Mediante la
sintaxis DotLiquid y un conjunto proporcionado de recursos de cadena localizada, iconos y controles de
página, dispone de una gran flexibilidad para configurar el contenido de las páginas según le convenga.
Disponibilidad
IMPORTANT
Información general sobre las plantillas del portal para

desarrolladores
La edición de las reglas de estilo se realiza en el portal para desarrolladores durante el inicio de sesión
como administrador. Para llegar hasta allí, primero abra Azure Portal y haga clic en Portal para
desarrolladores en la barra de herramientas de servicios de su instancia de API Management.
Para acceder a las plantillas del portal para desarrolladores, haga clic en el icono de personalización de la
izquierda para mostrar el menú de personalización y haga clic en Plantillas.
La lista de plantillas muestra varias categorías de plantillas que abarcan las distintas páginas del portal para
desarrolladores. Cada plantilla es diferente, pero los pasos para editarlas y publicar los cambios son los
mismos. Para editar una plantilla, haga clic en el nombre.
Cuando hace clic en una plantilla, se abre la página del portal para desarrolladores que se puede personalizar
con esa plantilla. En este ejemplo se muestra la plantilla Lista de productos. La plantilla Lista de productos
controla el área de la pantalla que se indica con un rectángulo rojo.
Algunas plantillas, como las plantillas Perfil de usuario , personalizan partes diferentes de la misma página.
El editor de cada plantilla del portal para desarrolladores tiene dos secciones que se muestran en la parte
inferior de la página. El lado izquierdo muestra el panel de edición de la plantilla y el lado derecho muestra el
modelo de datos de la plantilla.
El panel de edición de plantillas contiene el marcado que controla la apariencia y el comportamiento de la
página correspondiente en el portal para desarrolladores. El marcado de la plantilla usa la sintaxis DotLiquid .
Un editor popular de DotLiquid es DotLiquid for Designers. Todos los cambios que se realizan en la plantilla
durante la edición se muestran en tiempo real en el explorador, pero no son visibles para los clientes mientras
no se guarda y se publica la plantilla.
El panel Template data (Datos de plantilla) proporciona indicaciones sobre el modelo de datos de las
entidades que están disponibles para su uso en una plantilla determinada. Dichas indicaciones consisten en
los datos actuales que se muestran actualmente en el portal para desarrolladores. Para expandir los paneles
de plantilla, haga clic en el rectángulo de la esquina superior derecha del panel Template data (Datos de
plantilla).
En el ejemplo anterior, se muestran en el portal para desarrolladores dos productos que se recuperaron de los
datos mostrados en el panel Template data (Datos de plantilla), tal como se muestra en el ejemplo siguiente:
{
"Paging": {
"Page": 1,
"PageSize": 10,
"TotalItemCount": 2,
"ShowAll": false,
"PageCount": 1
},
"Filtering": {
"Pattern": null,
"Placeholder": "Search products"
},
"Products": [
{
"Id": "56ec64c380ed850042060001",
"Title": "Starter",
"Description": "Subscribers will be able to run 5 calls/minute up to a maximum of 100
calls/week.",
"Terms": "",
"ProductState": 1,
"AllowMultipleSubscriptions": false,
"MultipleSubscriptionsCount": 1
},
{
"Id": "56ec64c380ed850042060002",
"Title": "Unlimited",
"Description": "Subscribers have completely unlimited access to the API. Administrator
approval is required.",
"Terms": null,
"ProductState": 1,
}
]
}
El marcado de la plantilla Lista de productos procesa los datos para proporcionar el resultado deseado. Para
ello, itere a través de la colección de productos para mostrar información y un vínculo a cada producto.
Observe los elementos <search-control> y <page-control> del marcado. Controlan la presentación de la
búsqueda y los controles de paginación en la página. ProductsStrings|PageTitleProducts es una referencia de
cadena localizada que contiene el texto del encabezado h2 de la página. Para obtener una lista de recursos de
cadena, controles de página e iconos disponibles para su uso en plantillas del portal para desarrolladores,
consulte la referencia de plantillas del portal para desarrolladores de API Management.
<search-control></search-control>
<div class="row">
<div class="col-md-9">
<h2>{% localized "ProductsStrings|PageTitleProducts" %}</h2>
</div>
</div>
<div class="row">
{% if products.size > 0 %}
<ul class="list-unstyled">
{% for product in products %}
<li>
<h3><a href="/products/{{product.id}}">{{product.title}}</a></h3>
{{product.description}}
</li>
{% endfor %}
</ul>
<paging-control></paging-control>
{% else %}
{% localized "CommonResources|NoItemsToDisplay" %}
{% endif %}
</div>
</div>
Para guardar una plantilla

Para guardar una plantilla, haga clic en guardar en el editor de plantillas.
Los cambios guardados no se activan en el portal para desarrolladores mientras no se publiquen.
Para publicar una plantilla

Las plantillas guardadas se pueden publicar individualmente o todas juntas. Para publicar una plantilla
individual, haga clic en publicar en el editor de plantillas.
Haga clic en Sí para confirmar y hacer que la plantilla se active en el portal para desarrolladores.
Para publicar todas las versiones de plantillas actualmente sin publicar, haga clic en Publicar en la lista de
plantillas. Las plantillas no publicadas se indican con un asterisco después del nombre de la plantilla. En este
ejemplo, se van a publicar las plantillas Lista de productos y Producto.
Haga clic en Publicar personalizaciones para confirmar.
Las plantillas recién publicadas entran en vigor de inmediato en el portal para desarrolladores.
Para revertir una plantilla a la versión anterior

Para revertir una plantilla a la versión publicada anterior, haga clic en revertir en el editor de plantillas.
Haga clic en Sí para continuar.
La versión de una plantilla publicada anteriormente estará activa en el portal para desarrolladores en cuanto
se complete la operación de reversión.
Para restaurar una plantilla a la versión predeterminada

La restauración de las plantillas a su versión predeterminada es un proceso que consta de dos pasos. Primero
deben restaurarse las plantillas y después deben publicarse las versiones restauradas.
Para restaurar una sola plantilla a la versión predeterminada, haga clic en restaurar en el editor de plantillas.
Haga clic en Sí para continuar.

Para restaurar todas las plantillas a las versiones predeterminadas, haga clic en Restore default templates
(Restaurar plantillas predeterminadas) en la lista de plantillas.
Las plantillas restauradas deben publicarse individualmente o a la vez siguiendo los pasos descritos en Para
publicar una plantilla.
Pasos siguientes
Para obtener información de referencia sobre plantillas del portal para desarrolladores, recursos de cadena,
iconos y controles de página, consulte la referencia de plantillas del portal para desarrolladores de API
Management.
Autorización de las cuentas de desarrollador
mediante Azure Active Directory en Azure API
Management
En este artículo se muestra cómo habilitar el acceso al portal para desarrolladores para usuarios de Azure Active
Directory. También se muestra cómo administrar grupos de usuarios de Azure AD mediante la adición de grupos
externos que contienen a los usuarios.
Requisitos previos
Importe y publique una instancia de Azure API Management. Para más información, consulte Importación y
publicación.
Disponibilidad
IMPORTANT
Esta característica está disponible en los niveles Premium, Estándar y Desarrollador de API Management.
Autorización de las cuentas de desarrollador con Azure AD

2. Seleccionar .
3. En el cuadro de búsqueda, escriba api.
4. Seleccione Servicios API Management.
6. En Seguridad, seleccione Identidades.
7. Haga clic en + Agregar en la parte superior.
Aparece el panel Agregar proveedor de identidades a la derecha.
8. En Tipo de proveedor, seleccione Azure Active Directory.
En el panel aparecen controles que le permiten escribir otra información necesaria. Los controles incluyen
Id. de cliente y Secreto de cliente. (Más adelante en el artículo obtendrá información sobre estos
controles).
9. Anote el contenido de Dirección URL de redireccionamiento.
10. En el explorador, abra una pestaña diferente.
11. Navegue hasta Azure Portal: Registros de aplicaciones para registrar una aplicación en Active Directory.
12. En Administrar, seleccione Registros de aplicaciones.
13. Seleccione Nuevo registro. En la página Registrar una aplicación, establezca los valores de la manera
siguiente:
Establezca Nombre en un nombre con sentido; por ejemplo, portal-desarrollador
Establezca Tipos de cuenta admitidos en Solo las cuentas de este directorio organizativo.
Establezca URI de redirección en el valor obtenido en el paso 9.
Elija Registro.
14. Una vez registrada la aplicación, copie el Id. de aplicación (cliente) de la página Información general.
15. Vuelva a la instancia de API Management. En la ventana Agregar proveedor de identidades, pegue el
valor de Id. de aplicación (cliente) en el cuadro Id. de cliente.
16. Vuelva a la configuración de Azure AD, seleccione Certificados y secretos en Administrar. Seleccione el
botón Nuevo secreto de cliente. Escriba un valor en Descripción, seleccione cualquier opción para
Expira y elija Agregar. Copie el valor del secreto del cliente antes de salir de la página. Esta información la
necesitará en el siguiente paso.
17. En Administrar, seleccione Autenticación y luego Tokens de id. en Concesión implícita
18. Vuelva a la instancia de API Management, pegue el secreto en el cuadro Secreto de cliente.
IMPORTANT
Asegúrese de actualizar el secreto de cliente antes de que expire la clave.
19. La ventana Add identity provider (Agregar proveedor de identidades) también contiene el cuadro de
texto Allowed Tenants (Inquilinos permitidos). Ahí, especifique los dominios de las instancias de Azure
AD a las que quiere conceder acceso a las API de la instancia de servicio API Management. Puede separar
varios dominios mediante nuevas líneas, espacios o comas.
NOTE
Puede especificar varios dominios en la sección Allowed Tenants (Inquilinos permitidos). Para que un usuario pueda iniciar
sesión desde otro dominio distinto al dominio original donde se registró la aplicación, un administrador global de ese otro
dominio debe conceder antes a la aplicación permiso de acceso a los datos del directorio. Para conceder permiso, el
administrador global debe: a. Ir a https://<URL of your developer portal>/aadadminconsent (por ejemplo,
https://contoso.portal.azure-api.net/aadadminconsent) ). b. Escribir el nombre de dominio del inquilino de Azure AD al que
desea dar acceso. c. Seleccione Submit (Enviar).
20. Después de especificar la configuración deseada, seleccione Agregar.

Después de guardar los cambios, los usuarios de la instancia de Azure AD especificada pueden iniciar sesión en el
portal para desarrolladores siguiendo los pasos de Inicio de sesión en el portal para desarrolladores con una
cuenta de Azure AD.
Incorporación de un grupo externo de Azure AD

Después de permitir el acceso para los usuarios en una instancia de Azure AD, puede agregar grupos de Azure
AD en API Management. Luego, puede administrar de manera más fácil la asociación de los desarrolladores del
grupo con los productos deseados.
IMPORTANT
Para agregar un grupo externo de Azure AD, primero debe configurar la instancia de Azure AD en la pestaña Identidades
mediante el procedimiento de la sección anterior. Además, la aplicación se debe conceder acceso a Azure AD Graph API con
el permiso Directory.Read.All .
Los grupos externos de Azure AD se agregan desde la pestaña Grupos de la instancia de API Management.
1. Seleccione la pestaña Grupos .
2. Seleccione el botón Add AAD group (Agregar grupo de AAD ).
3. Seleccione el grupo que quiere agregar.

4. Presione el botón Select (Seleccionar).
Después de agregar un grupo externo de Azure AD, puede revisar y configurar sus propiedades. Seleccione el
nombre del grupo en la pestaña Groups (Grupos). Desde aquí, puede editar la información de nombre y
descripción del grupo.
Los usuarios de la instancia de Azure AD configurada ya pueden iniciar sesión en el portal para desarrolladores.
Pueden ver los grupos para los que tengan visibilidad y suscribirse a ellos.
Inicio de sesión en el portal para desarrolladores con una cuenta de
Azure AD
Para iniciar sesión en el portal para desarrolladores mediante una cuenta de Azure AD que ha configurado en las
secciones anteriores:
1. Abra una nueva ventana del explorador mediante la dirección URL de inicio de sesión de la configuración
de aplicación de Active Directory y seleccione Azure Active Directory.
2. Escriba las credenciales de uno de los usuarios de Azure AD y seleccione Iniciar sesión.
3. En caso de requerirse más información, puede que se le solicite un formulario de registro. Complete el
formulario de registro y seleccione Suscribirse.
Ahora ya inició sesión en el portal para desarrolladores de la instancia del servicio API Management.
Procedimiento para autorizar a las cuentas de
desarrollador para que usen Azure Active Directory
B2C en Azure API Management
Azure Active Directory B2C es una solución de administración de identidades en la nube, destinada a aplicaciones
móviles y web orientadas al consumidor. Puede usarlo para administrar el acceso a su portal para desarrolladores.
Esta guía le muestra la configuración que se necesita en el servicio de API Management para integrarse con Azure
Active Directory B2C. Para más información sobre cómo habilitar el acceso al portal para desarrolladores con
Azure Active Directory clásico, consulte Procedimiento para autorizar a las cuentas de desarrollador para que usen
Azure Active Directory.
NOTE
Para completar los pasos descritos en esta guía, primero debe tener un inquilino de Azure Active Directory B2C en el que
crear una aplicación. Además, debe tener listas las directivas de registro e inicio de sesión. Para más información, consulte
Introducción a Azure Active Directory B2C.
Disponibilidad
IMPORTANT
Esta característica está disponible en los niveles Premium, Estándar y Desarrollador de API Management.
Autorización de cuentas de desarrollador con Azure Active Directory

B2C
1. Para empezar, inicie sesión en Azure Portal y busque la instancia de API Management.
NOTE
Si todavía no ha creado una instancia del servicio API Management, consulte Creación de una instancia del servicio
API Management en el tutorial Introducción a Azure API Management.
2. En Identidades. Haga clic en + Agregar en la parte superior.

Aparece el panel Agregar proveedor de identidades a la derecha. Elija Azure Active Directory B2C.
3. Copie la Dirección URL de redireccionamiento.
4. En una pestaña nueva, acceda al inquilino de Azure Active Directory B2C en Azure Portal y abra la hoja
Aplicaciones.
5. Haga clic en el botón Agregar para crear una nueva aplicación de Azure Active Directory B2C.
6. En la hoja Nueva aplicación, escriba un nombre para la aplicación. Elija Sí en Aplicación web o API
Web y elija Sí en Permitir flujo implícito. A continuación, pegue la dirección URL de
redireccionamiento que copió en el paso 3 en el cuadro de texto Dirección URL de respuesta.
7. Haga clic en el botón Crear. Cuando se crea la aplicación, aparece en la hoja Aplicaciones. Haga clic en el
nombre de la aplicación para ver sus detalles.
8. En la hoja Propiedades, copie el identificador de aplicación en el Portapapeles.
9. Vuelva al panel Agregar proveedor de identidades de API Management y pegue el identificador en el

cuadro de texto Id. de cliente.
10. Vuelva al registro de la aplicación B2C, haga clic en el botón Claves y, luego, haga clic en Generar clave.
Haga clic en Guardar para guardar la configuración y mostrar la clave de la aplicación. Copie la clave en
el Portapapeles.
11. Vuelva al panel Agregar proveedor de identidades de API Management y pegue la clave en el cuadro de
texto Secreto de cliente.
12. Especifique el nombre de dominio del inquilino de Azure Active Directory B2C en Inquilino de inicio de
sesión.
13. El campo Autoridad le permite controlar la dirección URL de inicio de sesión de Azure AD B2C que se
usará. Establezca el valor en <nombre_de_su_inquilino_de_b2c>. b2clogin.com.
14. Especifique la directiva de registro y la directiva de inicio de sesión en las directivas del inquilino de
B2C. Si lo desea, también puede proporcionar la directiva de edición de perfil y la directiva de
restablecimiento de contraseña.
15. Una vez que especifique la configuración deseada, haga clic en Guardar.
Una vez que se guardan los cambios, los desarrolladores podrán crear cuentas nuevas e iniciar sesión en el
portal para desarrolladores con Azure Active Directory B2C.
Registro de una cuenta de desarrollador con Azure Active Directory

B2C
1. Para registrar una cuenta de desarrollador con Azure Active Directory B2C, abra una nueva ventana del
explorador y vaya al portal para desarrolladores. Haga clic en el botón Registrarse.
2. Elija registrarse con Azure Active Directory B2C.
3. Se le redirigirá a la directiva de registro que configuró en la sección anterior. Elija registrarse con la dirección
de correo electrónico o una de sus cuentas sociales existentes.
NOTE
Si Azure Active Directory B2C es la única opción habilitada en la pestaña Identidades del portal para editores, se le
redirigirá a la directiva de registro de forma directa.
Una vez completado el registro, se le redirigirá de nuevo al portal para desarrolladores. Ahora ya inició
sesión en el portal para desarrolladores de la instancia del servicio API Management.
Pasos siguientes
Introducción a Azure Active Directory B2C
Azure Active Directory B2C: Marco de directiva extensible
Uso de una cuenta Microsoft como proveedor de identidades en Azure Active Directory B2C
Uso de una cuenta de Google como proveedor de identidades en Azure Active Directory B2C
Uso de una cuenta de LinkedIn como proveedor de identidades en Azure Active Directory B2C
Uso de una cuenta de Facebook como proveedor de identidades en Azure Active Directory B2C
Delegación de registros de usuario y suscripciones a
producto
La delegación le permite usar su sitio web actual para controlar el inicio de sesión y la suscripción de los
desarrolladores, así como sus suscripciones a productos, en contraposición al uso de la funcionalidad integrada en
el portal para desarrolladores. Esto habilita su sitio web como propietario de los datos de usuario para poder
realizar la validación de estos pasos de forma personalizada.
Disponibilidad
IMPORTANT
Delegación de inicios de sesión y suscripciones de desarrolladores

Para delegar el inicio de sesión y la suscripción para desarrolladores al sitio web existente, deberá crear un punto
de conexión de delegación especial en su sitio. Debe actuar como un punto de entrada para cualquier solicitud de
este tipo iniciada desde el portal para desarrolladores de API Management.
El flujo de trabajo final será el siguiente:
1. El desarrollador hace clic en el enlace de inicio de sesión o de suscripción que se encuentra en el portal para
desarrolladores de API Management.
2. El explorador se redirige al extremo de delegación.
3. Como respuesta, el punto de conexión de delegación se redirige a la interfaz de usuario o la presenta para pedir
al usuario que inicie sesión o se suscriba.
4. Una vez conseguido, se redirige de nuevo al usuario a la página del portal para desarrolladores de API
Management de la que partió.
Para empezar, configuremos primero Administración de API para que dirija las solicitudes a través del extremo de
delegación. En el portal para editores de API Management, haga clic en Seguridad y, a continuación, haga clic en
la pestaña Delegación. Haga clic en la casilla para activar "Delegar inicio de sesión y suscripción".
Determine cuál será la dirección URL del extremo especial de delegación y escríbala en el campo Dirección
URL del extremo de delegación .
En el campo Clave de autenticación de delegación, escriba el secreto que se usará para procesar una firma
suministrada para su comprobación con objeto de garantizar que la solicitud procede efectivamente de Azure
API Management. Puede hacer clic en el botón generar para que API Management genere de forma aleatoria
una clave en su lugar.
Ahora debe crear el extremo de delegación. Este tiene que realizar varias acciones:
1. Recibir una solicitud de la forma siguiente:
http://www.yourwebsite.com/apimdelegation?operation=SignIn&returnUrl={URL de la página de
origen}&salt={string }&sig={string }
Parámetros de consulta en el caso de inicio de sesión o suscripción:

operation: identifica el tipo de solicitud de delegación del que se trata. Solo puede ser SignIn en este
caso.
returnUrl: la dirección URL de la página en la que el usuario hizo clic en un vínculo de suscripción o de
inicio de sesión.
salt: una cadena salt especial que se usa para procesar un hash de seguridad
sig: un hash de seguridad procesado que se comparará con su propio hash procesado
2. Compruebe que la solicitud procede de Azure API Management (opcional, pero especialmente
recomendado por motivos de seguridad).
Procese un hash HMAC -SHA512 de una cadena según los parámetros de consulta returnUrl y salt
(se proporciona código de ejemplo a continuación):
HMAC (salt + '\n' + returnUrl)
Compare el hash procesado anteriormente con el valor del parámetro de consulta sig . Si los dos
hashes coinciden, vaya a paso siguiente; de lo contrario, deniegue la solicitud.
3. Compruebe que ha recibido una solicitud para inicio de sesión/suscripción: el parámetro de consulta
operation se establecerá en "SignIn".
4. Presente al usuario la interfaz de usuario para que inicie sesión o se suscriba.
5. Si el usuario se suscribe, hay que crear la cuenta correspondiente en Administración de API. Cree un usuario
con la API de REST de API Management. Al hacerlo, asegúrese de que el identificador de usuario se
establece en el mismo valor que existe en su almacén de usuario o en un identificador al que pueda realizar
el seguimiento.
6. Cuando el usuario se autentique correctamente:
solicite un token de inicio de sesión único (SSO ) a través de la API de REST de API Management
anexe un parámetro de consulta returnUrl a la URL de SSO que se recibió de la llamada de API
anterior:
por ejemplo, https://customer.portal.azure-api.net/signin-sso?token&returnUrl=/return/url
redirija al usuario a la URL producida anteriormente

Además de la operación SignIn, también puede realizar la administración de cuentas siguiendo los pasos
anteriores y utilizando una de las siguientes operaciones:
ChangePassword
ChangeProfile
CloseAccount
Debe pasar los siguientes parámetros de consulta para las operaciones de administración de cuenta.
operation: identifica qué tipo de solicitud de delegación es (ChangePassword, ChangeProfile o CloseAccount)
userId: el identificador de usuario de la cuenta para administrar
Delegación de suscripciones a productos

La delegación de una suscripción a productos funciona de forma similar a la delegación de inicio de sesión y
suscripción de usuario. El flujo de trabajo final sería el siguiente:
1. El desarrollador selecciona un producto en el portal para desarrolladores de API Management y hace clic en el
botón Suscribir.
2. El explorador se redirige al extremo de delegación.
3. El extremo de delegación realiza los pasos necesarios para la suscripción al producto. Usted es el encargado de
diseñar estos pasos. Pueden implicar la redirección a otra página para solicitar información de facturación, la
formulación de otras preguntas o simplemente el almacenamiento de la información sin que se requiera
ninguna acción del usuario.
Para habilitar la funcionalidad, en la página Delegación, haga clic en Delegar suscripción de productos.
A continuación, asegúrese de que el extremo de delegación realiza las siguientes acciones:
1. Recibir una solicitud de la forma siguiente:
http://www.yourwebsite.com/apimdelegation?operation={operación}&productId={producto al que se
suscribe}&userId={usuario que realiza la solicitud }&salt={cadena }&amp;sig={cadena }
Parámetros de consulta en el caso de suscripción a producto:

operation: identifica el tipo de solicitud de delegación del que se trata. En las solicitudes de suscripción a
producto las opciones válidas son:
"Subscribe": una solicitud para suscribir al usuario a un producto determinado con el id.
especificado (consulte más información a continuación).
"Unsubscribe": una solicitud para cancelar la suscripción de un usuario a un producto.
"Renew": una solicitud para renovar una suscripción (por ejemplo, que esté a punto de expirar).
productId: el id. del producto al que el usuario solicitó suscribirse.
subscriptionId: en Cancelar suscripción y Renovar, el identificador de la suscripción del producto.
userId: el id. del usuario para el que se realiza la solicitud.
2. Compruebe que la solicitud procede de Azure API Management (opcional, pero especialmente
recomendado por motivos de seguridad).
Procesar un hash HMAC -SHA512 de una cadena en función de los parámetros de consulta
productId, userId y salt:
HMAC (salt + '\n' + productId + '\n' + userId)
Compare el hash procesado anteriormente con el valor del parámetro de consulta sig . Si los dos
hashes coinciden, vaya a paso siguiente; de lo contrario, deniegue la solicitud.
3. Procese cualquier suscripción a producto en función del tipo de operación solicitada en operation; por
ejemplo, facturación, preguntas adicionales, etc.
4. Tras la correcta suscripción del usuario al producto por su parte, suscriba al usuario al producto de API
Management llamando a la API de REST para las suscripciones.
Ejemplo de código
Estos ejemplos de código enseñan cómo:
Tomar la clave de validación de delegación, que se establece en la pantalla de delegación del portal del
publicador
Crear un HMAC que, después, se usa para validar la firma, probando la validez del valor de returnUrl que se
pasó.
El mismo código funciona para productId y userId con pequeñas modificaciones.
Código C# para generar el hash de returnUrl
using System.Security.Cryptography;
string key = "delegation validation key";

string returnUrl = "returnUrl query parameter";
string salt = "salt query parameter";
string signature;
using (var encoder = new HMACSHA512(Convert.FromBase64String(key)))
{
signature = Convert.ToBase64String(encoder.ComputeHash(Encoding.UTF8.GetBytes(salt + "\n" + returnUrl)));
// change to (salt + "\n" + productId + "\n" + userId) when delegating product subscription
// compare signature to sig query parameter
}
Código NodeJS para generar el hash de returnUrl
var crypto = require('crypto');
var key = 'delegation validation key';

var returnUrl = 'returnUrl query parameter';
var salt = 'salt query parameter';
var hmac = crypto.createHmac('sha512', new Buffer(key, 'base64'));

var digest = hmac.update(salt + '\n' + returnUrl).digest();
// change to (salt + "\n" + productId + "\n" + userId) when delegating product subscription
// compare signature to sig query parameter
var signature = digest.toString('base64');
Pasos siguientes
Para más información acerca de la delegación, vea el siguiente vídeo:
Configuración de notificaciones y plantillas de correo
electrónico en Azure API Management
Administración de API ofrece la posibilidad de configurar notificaciones de eventos específicos, así como plantillas
de correo electrónico que se usan para comunicarse con los administradores y desarrolladores de una instancia de
API Management. Este artículo muestra cómo configurar las notificaciones de los eventos disponibles y ofrece
información general sobre la configuración de plantillas de correo electrónico que se usan para estos eventos.
Requisitos previos
Si no tiene una instancia del servicio API Management, realice el inicio rápido siguiente: Creación de una instancia
de Azure API Management.
Disponibilidad
IMPORTANT
Configuración de notificaciones
1. Seleccione su instancia de API MANAGEMENT.
2. Haga clic en Notificaciones para ver las notificaciones disponibles.
Se puede configurar la siguiente lista de eventos para notificaciones.

Solicitudes de suscripción (se requiere aprobación) : los destinatarios y usuarios de correo
electrónico especificados recibirán notificaciones por correo electrónico sobre solicitudes de
suscripción de productos de API que requieran aprobación.
Nuevas suscripciones : los destinatarios y usuarios de correo electrónico especificados recibirán
notificaciones por correo electrónico sobre nuevas suscripciones de productos de API.
Solicitudes de la galería de aplicaciones : los destinatarios y usuarios de correo electrónico
especificados recibirán notificaciones por correo electrónico cuando se envíen nuevas aplicaciones a
la galería de aplicaciones.
CCO : los destinatarios y usuarios de correo electrónico especificados recibirán copias carbón ocultas
de todos los correos electrónicos enviados a los desarrolladores.
Nuevo problema o comentario : los destinatarios y usuarios de correo electrónico especificados
recibirán notificaciones por correo electrónico cuando se envíe un nuevo problema o comentario en
el portal para desarrolladores.
Cerrar mensaje de cuenta : los destinatarios y usuarios de correo electrónico especificados
recibirán notificaciones por correo electrónico cuando se cierre una cuenta.
Aproximación al límite de cuota de suscripción : los siguientes destinatarios y usuarios de
correo electrónico recibirán notificaciones por correo electrónico cuando el uso de la suscripción se
acerque a la cuota de uso.
En cada evento, se pueden especificar destinatarios con el cuadro de texto de dirección de correo
electrónico o seleccionar usuarios de una lista.
3. Para especificar las direcciones de correo electrónico a las que se van a enviar notificaciones, especifíquelas
en el cuadro de texto de dirección de correo electrónico. Si tiene varias direcciones de correo electrónico,
sepárelas con comas.
4. Presione Agregar.
Plantillas Configurar notificación

API Management proporciona plantillas de notificación para los mensajes de correo electrónico que se envían
durante la administración y el uso del servicio. Se incluyen las siguientes plantillas de correo electrónico.
Envío de la galería de aplicaciones aprobado
Carta de despedida del desarrollador
Notificación de aproximación del límite de cuota del desarrollador
Invitación a un usuario
Nuevo comentario agregado a un problema
Nuevo problema recibido
Nueva suscripción activada
Confirmación de suscripción renovada
Rechazo de la solicitud de suscripción
Solicitud de suscripción recibida
Estas plantillas se pueden modificar tal como se desee.
Para ver y configurar las plantillas de correo electrónico para la instancia de API Management, haga clic en
Plantillas de notificaciones.
Cada plantilla de correo electrónico tiene un asunto en texto sin formato y una definición del cuerpo en formato
HTML. Cada elemento se puede personalizar según se desee.
La lista Parámetros contiene una lista de parámetros que, al insertarlos en el asunto o en el cuerpo, se
reemplazarán por el valor designado cuando se envíe el correo electrónico. Para insertar un parámetro, sitúe el
cursor en donde desee que vaya el parámetro y haga clic en la flecha a la izquierda del nombre del parámetro.
NOTE
Los parámetros no se reemplazan por valores reales al obtener la vista previa o enviar una prueba.
Para guardar los cambios efectuados en la plantilla de correo electrónico, haga clic en Guardar o, si desea
cancelarlos, haga clic en Descartar.
Procedimiento para autorizar a las cuentas de
desarrollador para que usen OAuth 2.0 en Azure API
Management
Muchas API admiten OAuth 2.0 para proteger la API y garantizar que solo usuarios válidos obtengan acceso y que,
además, solo puedan tener acceso a los recursos para los que estén autorizados. Para usar la consola interactiva
para desarrolladores de la Azure API Management, el servicio permite configurar la instancia del servicio para que
funcione con la API habilitada para OAuth 2.0.
Requisitos previos
En esta guía se explica cómo configurar la instancia del servicio Administración de API para que use la autorización
OAuth 2.0 con las cuentas de desarrollador, pero no se explica cómo configurar un proveedor de OAuth 2.0.
Aunque los proveedores de OAuth 2.0 tienen configuraciones diferentes, los pasos son similares y se precisa la
misma información para configurar OAuth 2.0 en la instancia del servicio Administración de API. Este tema
muestra ejemplos donde Azure Active Directory actúa como proveedor de OAuth 2.0.
NOTE
Para obtener más información sobre cómo configurar OAuth 2.0 con Azure Active Directory, consulte el ejemplo de WebApp-
GraphAPI-DotNet.
Disponibilidad
IMPORTANT
Configurar un servidor de autorización OAuth 2.0 en Administración de

API
NOTE
Si todavía no ha creado una instancia del servicio API Management, consulte Creación de una instancia del servicio API
Management.
1. Haga clic en la pestaña OAuth 2.0 en el menú de la izquierda y haga clic en +Agregar.
2. Escriba un nombre y una descripción opcional en los campos Nombre y Descripción.
NOTE
Estos campos sirven para identificar el servidor de autorización OAuth 2.0 en la instancia del servicio Administración
de API y los valores que contienen no proceden del servidor OAuth 2.0.
3. Escriba la URL de la página de registro de cliente. En esta página, los usuarios pueden crear y
administrar sus cuentas. Puede variar en función del proveedor de OAuth 2.0. La URL de la página de
registro de cliente señala a la página que los usuarios pueden utilizar para crear y configurar sus propias
cuentas para proveedores de OAuth 2.0 que admiten la administración de usuarios de las cuentas. Algunas
organizaciones no configuran ni usan esta funcionalidad, aunque la admita el proveedor de OAuth 2.0. Si el
proveedor de OAuth 2.0 no tiene configurada la administración de usuarios de las cuentas, especifique aquí
una URL de marcador de posición, por ejemplo, la URL de su empresa o una URL como
https://placeholder.contoso.com .
4. La siguiente sección del formulario contiene la configuración de Authorization grant types (Tipos de
concesión de autorización), Authorization endpoint URL (URL del punto de conexión de autorización) y
Authorization request method (Método de solicitud de autorización).
Active las casillas de los tipos de concesión de autorización que desee. Código de autorización se
especifica de forma predeterminada.
Escriba la URL del extremo de autorización. En Azure Active Directory, esta URL será similar a la
siguiente, donde se reemplaza <client_id> por el identificador de cliente que identifica la aplicación en el
servidor OAuth 2.0.
https://login.microsoftonline.com/<client_id>/oauth2/authorize
El Método de solicitud de autorización especifica cómo se envía la solicitud de autorización al servidor

OAuth 2.0. El valor predeterminado es GET .
5. A continuación, debe especificar URL del punto de conexión de token, Métodos de autenticación de
cliente, Método de envío de tokens de acceso y Ámbito predeterminado.
En un servidor OAuth 2.0 de Azure Active Directory, la URL del punto de conexión de token tendrá el
formato siguiente, donde <TenantID> tiene el formato de yourapp.onmicrosoft.com .
https://login.microsoftonline.com/<TenantID>/oauth2/token
Los valores predeterminados para Métodos de autenticación de cliente y Método de envío de tokens
de acceso son Básico y Encabezado de autorización respectivamente. Estos valores se configuran en
esta sección del formulario, junto con el Ámbito predeterminado.
6. La sección Credenciales de cliente contiene el Id. de cliente y el Secreto del cliente que se obtienen
durante los procesos de creación y configuración del servidor OAuth 2.0. Al especificar el Id. de cliente y el
Secreto del cliente, se genera el uri de redirección para el código de autorización. Con este URI se
configura la URL de respuesta en la configuración del servidor OAuth 2.0.
Si Authorization grant types (Tipos de concesión de autorización) se establece en Resource owner
password (Contraseña de propietario de recursos), las credenciales se especifican con la sección Resource
owner password credentials (Credenciales de contraseña de propietario de recursos). De no ser así, puede
dejarse en blanco.
Cuando complete el formulario, haga clic en Crear para guardar la configuración del servidor de
autorización OAuth 2.0 de API Management. Cuando se guarda la configuración del servidor, pueden
configurarse las API para que usen estos valores, conforme a la sección siguiente.
Configurar una API para que use la autorización de usuario OAuth 2.0
1. Haga clic en API en el menú API Management de la izquierda.
2. Haga clic en el nombre de la API deseada y haga clic en Configuración. Desplácese hasta la sección
Seguridad y, a continuación, active la casilla de OAuth 2.0.
3. Seleccione el Servidor de autorización que quiera en la lista desplegable y haga clic en Guardar.
Probar la autorización de usuario OAuth 2.0 en el portal para
desarrolladores
Tras configurar el servidor de autorización OAuth 2.0 y las API para que usen dicho servidor, puede probarlo. Para
ello, vaya al portal para desarrolladores y llame a una API. Haga clic en Portal para desarrolladores en el menú
superior de la página Introducción de la instancia de Azure API Management.
Haga clic en API en el menú superior y seleccione API eco.
NOTE
Si solamente tiene una API configurada o visible en su cuenta, al hacer clic en API irá directamente a las operaciones de dicha
API.
Seleccione la operación Recurso GET, haga clic en Abrir consola y seleccione Código de autorización en la lista
desplegable.
Al seleccionar Código de autorización , se abre una ventana emergente con el formulario de suscripción del
proveedor de OAuth 2.0. En este ejemplo, Azure Active Directory ha proporcionado el formulario de suscripción.
NOTE
Si ha deshabilitado los elementos emergentes, el explorador le solicitará que los habilite. Cuando los habilite, seleccione
Código de autorización de nuevo y se mostrará el formulario de suscripción.
Tras iniciar sesión, los Encabezados de solicitud se rellenan con el encabezado Authorization : Bearer que
autoriza la solicitud.
Llegado a este punto, puede configurar los valores que desea para los demás parámetros y enviar la solicitud.
Pasos siguientes
Para obtener más información acerca del uso de OAuth 2.0 y Administración de API, vea el siguiente vídeo y el
artículoque lo acompaña.
Establecimiento o modificación de directivas de
La definición de la directiva es un documento XML que describe una secuencia de declaraciones de entrada y de
salida. El XML se puede editar directamente en la ventana de definición. También puede seleccionar una directiva
predefinida de la lista que se proporciona a la derecha de la ventana de directiva. Las instrucciones aplicables al
ámbito actual están habilitadas y resaltadas. Al hacer clic en una declaración habilitada, se agregará el XML
correspondiente en la ubicación del cursor en la vista de definición.
Para obtener más información sobre directivas, consulte Directivas de Azure API Management.
Establecimiento o modificación de directivas

Para establecer o modificar una directiva, siga estos pasos:
1. Inicie sesión en Azure Portal en https://portal.azure.com.
3. Haga clic en la pestaña API.
4. Seleccione una de las API que haya importado previamente.

5. Seleccione la pestaña Diseño.
6. Seleccione una operación en la que desee aplicar la directiva. Si desea aplicar la directiva a todas las
operaciones, seleccione Todas las operaciones.
7. Seleccione el icono </> (editor de código) en la sección Procesamiento de entrada o Procesamiento
de salida.
8. Pegue el código de la directiva que desee en uno de los bloques adecuados.
<policies>
<inbound>
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Configuración del ámbito

Las directivas se pueden configurar globalmente o en el ámbito de un producto, una API o una operación. Para
comenzar a configurar una directiva, se debe seleccionar en primer lugar el ámbito en el que se debe aplicar.
Los ámbitos de la directiva se evalúan en el orden siguiente:
1. Ámbito global
2. Ámbito del producto
3. Ámbito de la API
4. Ámbito de la operación
Las instrucciones dentro de las directivas se evalúan según la ubicación del elemento base , si existe. Una
directiva global no tiene una directiva principal y el uso del elemento <base> en ella no surte efecto.
Para ver las directivas en el ámbito actual en el editor de directivas, haga clic en Recalcular la directiva en vigor
del ámbito seleccionado.
Ámbito global
El ámbito global se configura para todas las API de su instancia de APIM.
1. Inicie sesión en Azure Portal y vaya a la instancia de APIM.
2. Haga clic en Todas las API.
3. Haga clic en el icono de triángulo.

4. Seleccione Editor de código.
5. Agregue o modifique directivas.
Los cambios se propagan inmediatamente a la puerta de enlace de API Management.
Ámbito del producto
El ámbito del producto está configurado para el producto seleccionado.
1. Haga clic en Productos.
2. Seleccione el producto en el que desea aplicar las directivas.

3. Haga clic en Directivas.
Ámbito de la API
El ámbito de la API está configurado para todas las operaciones de la API seleccionada.
1. Seleccione la API en la que desea aplicar directivas.

Ámbito de la operación
El ámbito de la operación está configurado para la operación seleccionada.
1. Seleccione una API.
2. Seleccione la operación en la que desea aplicar directivas.
Pasos siguientes
Vea también los siguientes temas relacionados:
Expresiones de las directivas de API Management
Este artículo describe la sintaxis de expresiones de directiva C# 7. Cada expresión tiene acceso a la variable de
contexto proporcionada de forma implícita y a un subconjunto permitido de tipos de .NET Framework.
Para obtener más información:
Vea cómo proporcionar información de contexto al servicio back-end. Use las directivas Establecer el
parámetro de cadena de consulta y Establecer encabezado HTTP para proporcionar esta información.
Vea cómo utilizar la directiva de validación de JWT para preautorizar el acceso a operaciones según
notificaciones de token.
Vea cómo se utiliza un seguimiento de API Inspector para ver cómo se evalúan las directivas y los resultados
de las evaluaciones.
Vea cómo usar expresiones con las directivas Obtener de caché y Almacenar en caché para configurar el
almacenamiento en caché de la respuesta de API Management. Defina una duración que coincida con el
almacenamiento en caché de la respuesta del servicio back-end especificado por la directiva Cache-Control
del servicio back-end.
Vea cómo realizar el filtrado de contenido. Quite elementos de datos de la respuesta recibida desde el
servicio back-end mediante las directivas Flujo de control y Establecer cuerpo.
Para descargar las declaraciones de directiva, vaya a api-management-samples/policies en el repositorio de
GitHub.
Sintaxis
Las expresiones de declaración única se incluyen en @(expression) , donde expression es una instrucción de
expresión bien formada de C#.
Las expresiones de múltiples declaraciones se incluyen en @{expression} . Todas las rutas de código de las
expresiones de múltiples declaraciones deben terminar con una declaración return .
Ejemplos
@(true)
@((1+1).ToString())
@("Hi There".Length)
@(Regex.Match(context.Response.Headers.GetValueOrDefault("Cache-Control",""), @"max-age=(?
<maxAge>\d+)").Groups["maxAge"]?.Value)
@(context.Variables.ContainsKey("maxAge") ? int.Parse((string)context.Variables["maxAge"]) : 3600)
@{
string value;
if (context.Request.Headers.TryGetValue("Authorization", out value))
{
return Encoding.UTF8.GetString(Convert.FromBase64String(value));
}
else
{
return null;
}
}
Uso
Las expresiones pueden utilizarse como valores de atributos o valores de texto en cualquier directiva de API
Management, a menos que la referencia de la directiva especifique lo contrario.
IMPORTANT
Al utilizar expresiones de directiva, solo hay una verificación limitada de estas cuando se define la directiva. La puerta de
enlace ejecuta las expresiones en tiempo de ejecución, y las excepciones generadas por las expresiones de directiva
generan un error en tiempo de ejecución.
Tipos de .NET framework que se permiten en expresiones de

directiva
En la tabla siguiente se enumeran los tipos de .NET Framework que se permiten en las expresiones de directiva
y sus miembros.
TYPE MIEMBROS COMPATIBLES
Newtonsoft.Json.Formatting Todo
Newtonsoft.Json.JsonConvert SerializeObject, DeserializeObject
Newtonsoft.Json.Linq.Extensions Todo
Newtonsoft.Json.Linq.JArray Todo
Newtonsoft.Json.Linq.JConstructor Todo
Newtonsoft.Json.Linq.JContainer Todo
Newtonsoft.Json.Linq.JObject Todo
Newtonsoft.Json.Linq.JProperty Todo
Newtonsoft.Json.Linq.JRaw Todo
Newtonsoft.Json.Linq.JToken Todo
Newtonsoft.Json.Linq.JTokenType Todo
Newtonsoft.Json.Linq.JValue Todo
System.Array Todo
System.BitConverter Todo
System.Boolean Todo
System.Byte Todo
System.Char Todo
System.Collections.Generic.Dictionary<TKey, TValue> Todo
System.Collections.Generic.HashSet<T> Todo
System.Collections.Generic.ICollection<T> Todo
System.Collections.Generic.IDictionary<TKey, TValue> Todo
System.Collections.Generic.IEnumerable<T> Todo
System.Collections.Generic.IEnumerator<T> Todo
System.Collections.Generic.IList<T> Todo
System.Collections.Generic.IReadOnlyCollection<T> Todo
System.Collections.Generic.IReadOnlyDictionary<TKey, Todo
TValue>
System.Collections.Generic.ISet<T> Todo
System.Collections.Generic.KeyValuePair<TKey, TValue> Todo
System.Collections.Generic.List<T> Todo
System.Collections.Generic.Queue<T> Todo
System.Collections.Generic.Stack<T> Todo
System.Convert Todo
System.DateTime (Constructor), Add, AddDays, AddHours, AddMilliseconds,

AddMinutes, AddMonths, AddSeconds, AddTicks, AddYears,
Date, Day, DayOfWeek, DayOfYear, DaysInMonth, Hour,
IsDaylightSavingTime, IsLeapYear, MaxValue, Millisecond,
Minute, MinValue, Month, Now, Parse, Second, Subtract,
Ticks, TimeOfDay, Today, ToString, UtcNow, Year
System.DateTimeKind UTC
System.DateTimeOffset Todo
System.Decimal Todo
System.Double Todo
System.Exception Todo
System.Guid Todo
System.Int16 Todo
System.Int32 Todo
System.Int64 Todo
System.IO.StringReader Todo
System.IO.StringWriter Todo
System.Linq.Enumerable Todo
System.Math Todo
System.MidpointRounding Todo
System.Net.WebUtility Todo
System.Nullable Todo
System.Random Todo
System.SByte Todo
System.Security.Cryptography.AsymmetricAlgorithm Todo
System.Security.Cryptography.CipherMode Todo
System.Security.Cryptography.HashAlgorithm Todo
System.Security.Cryptography.HashAlgorithmName Todo
System.Security.Cryptography.HMAC Todo
System.Security.Cryptography.HMACMD5 Todo
System.Security.Cryptography.HMACSHA1 Todo
System.Security.Cryptography.KeyedHashAlgorithm Todo
System.Security.Cryptography.MD5 Todo
System.Security.Cryptography.Oid Todo
System.Security.Cryptography.PaddingMode Todo
System.Security.Cryptography.RNGCryptoServiceProvider Todo
System.Security.Cryptography.RSA Todo
System.Security.Cryptography.RSAEncryptionPadding Todo
System.Security.Cryptography.RSASignaturePadding Todo
System.Security.Cryptography.SHA1 Todo
System.Security.Cryptography.SHA1Managed Todo
System.Security.Cryptography.SymmetricAlgorithm Todo
System.Security.Cryptography.X509Certificates.PublicKey Todo
System.Security.Cryptography.X509Certificates.RSACertificat Todo
eExtensions
System.Security.Cryptography.X509Certificates.X500Distingu NOMBRE
ishedName
System.Security.Cryptography.X509Certificates.X509Certifica Todo
te
System.Security.Cryptography.X509Certificates.X509Certifica Todo
te2
System.Security.Cryptography.X509Certificates.X509Content Todo
Type
System.Security.Cryptography.X509Certificates.X509NameTy Todo
pe
System.Single Todo
System.String Todo
System.StringComparer Todo
System.StringComparison Todo
System.StringSplitOptions Todo
System.Text.Encoding Todo
System.Text.RegularExpressions.Capture Index, Length, Value.
System.Text.RegularExpressions.CaptureCollection Count, Item.
System.Text.RegularExpressions.Group Captures, Success.
System.Text.RegularExpressions.GroupCollection Count, Item.
System.Text.RegularExpressions.Match Empty, Groups, Result.
System.Text.RegularExpressions.Regex (Constructor), IsMatch, Match, Matches, Replace, Unescape,

Split
System.Text.RegularExpressions.RegexOptions Todo
System.Text.StringBuilder Todo
System.TimeSpan Todo
System.TimeZone Todo
System.TimeZoneInfo.AdjustmentRule Todo
System.TimeZoneInfo.TransitionTime Todo
System.TimeZoneInfo Todo
System.Tuple Todo
System.UInt16 Todo
System.UInt32 Todo
System.UInt64 Todo
System.Uri Todo
System.UriPartial Todo
System.Xml.Linq.Extensions Todo
System.Xml.Linq.XAttribute Todo
System.Xml.Linq.XCData Todo
System.Xml.Linq.XComment Todo
System.Xml.Linq.XContainer Todo
System.Xml.Linq.XDeclaration Todo
System.Xml.Linq.XDocument Todos, excepto: Carga
System.Xml.Linq.XDocumentType Todo
System.Xml.Linq.XElement Todo
System.Xml.Linq.XName Todo
System.Xml.Linq.XNamespace Todo
System.Xml.Linq.XNode Todo
System.Xml.Linq.XNodeDocumentOrderComparer Todo
System.Xml.Linq.XNodeEqualityComparer Todo
System.Xml.Linq.XObject Todo
System.Xml.Linq.XProcessingInstruction Todo
System.Xml.Linq.XText Todo
System.Xml.XmlNodeType Todo
Variable de contexto
Una variable denominada context está disponible implícitamente en todas las expresiones de directiva. Sus
miembros proporcionan información relativa a \request . Todos los miembros de context son de solo lectura.
MÉTODOS, PROPIEDADES Y VALORES DE PARÁMETRO

VARIABLE DE CONTEX TO ADMITIDOS
context API: IApi
Implementación
Transcurrido: TimeSpan: intervalo de tiempo entre el valor de

marca de tiempo y la hora actual
LastError
operación
Producto
Solicitud
RequestId: Guid: identificador único de la solicitud
Respuesta
Suscripción
Marca de tiempo: DateTime: punto en el tiempo en que se

recibió la solicitud
Tracing: bool - indica si el seguimiento está activado o

desactivado
User
Variables: IReadOnlyDictionary<cadena, objeto>
void Trace(message: cadena)
context.Api Id: cadena
IsCurrentRevision: bool
Name: cadena
Path: cadena
Revision: cadena
ServiceUrl: IUrl
Version: cadena
context.Deployment Region: cadena
ServiceName: cadena
Certificates: IReadOnlyDictionary<cadena, X509Certificate2>

context.LastError Source: cadena
Reason: cadena
Message: cadena
Scope: cadena
Section: cadena
Path: cadena
PolicyId: cadena
Para obtener más información sobre context.LastError,

consulte Error handling in API Management policies (Control
de errores en directivas de API Management).
context.Operation Id: cadena
Method: cadena
Name: cadena
UrlTemplate: cadena
context.Product Apis: IEnumerable<IApi>
ApprovalRequired: bool
Groups: IEnumerable<IGroup>
Id: cadena
Name: cadena
State: enum ProductState {NotPublished, Published}
SubscriptionLimit: int?
SubscriptionRequired: bool
context.Request Cuerpo: IMessageBody o null si la solicitud no tiene un

cuerpo.
Certificate:
System.Security.Cryptography.X509Certificates.X509Certifica
te2
Encabezados: IReadOnlyDictionary<cadena, cadena[]>
IpAddress: cadena
MatchedParameters: IReadOnlyDictionary<cadena, cadena>
Method: cadena
OriginalUrl: IUrl
Url: IUrl
string headerName: cadena

context.Request.Headers.GetValueOrDefault(headerName:
string, defaultValue: string) defaultValue: cadena
Devuelve valores de encabezado de solicitud separados por

comas o defaultValue , si no se encuentra el encabezado.
context.Response Cuerpo: IMessageBody
Encabezados: IReadOnlyDictionary<cadena, cadena[]>
StatusCode: int
StatusReason: cadena
string headerName: cadena

context.Response.Headers.GetValueOrDefault(headerName:
string, defaultValue: string) defaultValue: cadena
Devuelve valores de encabezado de respuesta separados por

comas o defaultValue , si no se encuentra el encabezado.
context.Subscription CreatedTime: Datetime
EndDate: DateTime?
Id: cadena
Key: cadena
Name: cadena
PrimaryKey: cadena
SecondaryKey: cadena
StartDate: DateTime?
context.User Email: cadena
FirstName: cadena
Groups: IEnumerable<IGroup>
Id: cadena
Identities: IEnumerable<IUserIdentity>
LastName: cadena
Note: cadena
RegistrationDate: Datetime
IApi Id: cadena
Name: cadena
Path: cadena
Protocols: IEnumerable<cadena>
ServiceUrl: IUrl
SubscriptionKeyParameterNames:
ISubscriptionKeyParameterNames
IGroup Id: cadena
Name: cadena
IMessageBody As<T>(preserveContent: bool = false): Donde T: cadena,

JObject, JToken, JArray, XNode, XElement, XDocument
Los métodos context.Request.Body.As<T> y

context.Response.Body.As<T> se usan para leer los
cuerpos de un mensaje de respuesta y solicitud en un tipo
T especificado. De forma predeterminada, el método usa la
secuencia de cuerpo del mensaje original y lo presenta como
no disponible tras la devolución. Para evitar este resultado
haciendo que el método procese una copia de la secuencia
del cuerpo, establezca el parámetro preserveContent en
true . Vaya aquí para ver un ejemplo.
IUrl Host: cadena
Path: cadena
Port: int
Consultar IReadOnlyDictionary<cadena, cadena[]>
QueryString: cadena
Scheme: cadena
IUserIdentity Id: cadena
Provider: cadena
ISubscriptionKeyParameterNames Header: cadena
Query: cadena
string IUrl.Query.GetValueOrDefault(queryParameterName: queryParameterName: cadena

string, defaultValue: string)
defaultValue: cadena
Devuelve valores de parámetro de consulta separados por

comas o defaultValue , si no se encuentra el parámetro.
T context.Variables.GetValueOrDefault<T>(variableName: variableName: cadena

string, defaultValue: T)
defaultValue: T
Devuelve el valor de la variable convertido al tipo T o

defaultValue si no se encuentra la variable.
Este método produce una excepción si el tipo especificado

no coincide con el tipo real de la variable devuelta.
BasicAuthCredentials AsBasic(input: esta cadena) input: cadena
Si el parámetro de entrada contiene un valor válido de

encabezado de solicitud de autorización de autenticación
básica HTTP, el método devuelve un objeto de tipo
BasicAuthCredentials ; en caso contrario, el método
devuelve nulo.
bool TryParseBasic(input: esta cadena, result: input: cadena

BasicAuthCredentials de salida)
resultado: out BasicAuthCredentials
Si el parámetro de entrada contiene un valor válido de

autorización de autenticación básica HTTP en el encabezado
de solicitud, el método devuelve true y el parámetro de
resultado contiene un valor del tipo
BasicAuthCredentials ; en caso contrario, el método
devuelve false .
BasicAuthCredentials Password: cadena
UserId: cadena
Jwt AsJwt(input: esta cadena) input: cadena
Si el parámetro de entrada contiene un valor de token JWT

válido, el método devuelve un objeto de tipo Jwt ; en caso
contrario, el método devuelve null .
bool TryParseJwt(input: esta cadena, result: Jwt de salida) input: cadena
resultado: JWT de salida
Si el parámetro de entrada contiene un valor de token JWT

válido, el método devuelve true y el parámetro de
resultado contiene un valor de tipo Jwt ; en caso contrario,
el método devuelve false .
Jwt Algorithm: cadena
Audience: IEnumerable<cadena>
Claims: IReadOnlyDictionary<cadena, cadena[]>
ExpirationTime: DateTime?
Id: cadena
Issuer: cadena
IssuedAt: DateTime?
NotBefore: DateTime?
Subject: cadena
Type: cadena
cadena Jwt.Claims.GetValueOrDefault(claimName: cadena, claimName: cadena

defaultValue: cadena)
defaultValue: cadena
Devuelve valores de notificación separados por comas o

defaultValue , si no se encuentra el encabezado.
byte[] Encrypt(input: this byte[], alg: string, key:byte[], input: texto no cifrado que se va a cifrar
iv:byte[])
alg: nombre de un algoritmo de cifrado simétrico
key: clave de cifrado
iv: vector de inicialización
Devuelve cifrado el texto no cifrado.
byte[] Encrypt(entrada: este byte[], alg: input: texto no cifrado que se va a cifrar
System.Security.Cryptography.SymmetricAlgorithm)
alg: algoritmo de cifrado

byte[] Encrypt(entrada: este byte[], alg: input: texto no cifrado que se va a cifrar
System.Security.Cryptography.SymmetricAlgorithm,
key:byte[], iv:byte[]) alg: algoritmo de cifrado
byte[] Decrypt(input: this byte[], alg: string, key:byte[], input: texto cifrado que se va a descifrar
iv:byte[])
alg: nombre de un algoritmo de cifrado simétrico
Devuelve texto no cifrado.
byte[] Decrypt(entrada: este byte[], alg: input: texto cifrado que se va a descifrar
System.Security.Cryptography.SymmetricAlgorithm)
alg: algoritmo de cifrado
byte[] Decrypt(entrada: este byte[], alg: input: texto cifrado que se va a descifrar
System.Security.Cryptography.SymmetricAlgorithm,
key:byte[], iv:byte[]) alg: algoritmo de cifrado
bool VerifyNoRevocation(input: this Realiza una validación de la cadena X.509 sin comprobar el
System.Security.Cryptography.X509Certificates.X509Certifica estado de revocación de los certificados.
te2)
input - certificate object
Devuelve true si la validación es correcta; false si hay

un error.
Pasos siguientes
En la Referencia de directivas se muestra una lista completa de declaraciones de directivas y su
configuración
Almacenamiento en caché personalizado en Azure
API Management
El servicio Azure API Management integra compatibilidad para el almacenamiento en caché de respuestas HTTP
mediante el uso de la dirección URL como clave. La clave se puede modificar por los encabezados de solicitud
con las propiedades vary-by . Esto es útil para almacenar en caché las respuestas HTTP completas (también
conocidas como representaciones), pero a veces resulta útil almacenar en caché solo una parte de una
representación. Las nuevas directivas cache-lookup-value y cache-store-value permiten almacenar y recuperar
fragmentos arbitrarios de datos desde las definiciones de directiva. Esta capacidad también agrega valor a la
directiva send-request previamente introducida porque ahora se puede almacenar en caché las respuestas desde
servicios externos.
Arquitectura
El servicio API Management usa una caché de datos compartida por inquilino que, cuando escale verticalmente
a varias unidades, seguirá obteniendo acceso a los mismos datos en caché. Sin embargo, cuando se trabaja con
una implementación de varias regiones son memorias caché independientes dentro de cada una de las regiones.
Es importante no tratar la memoria caché como un almacén de datos, donde está el único origen de información.
Sin embargo, si ya lo hizo y más adelante decide aprovechar las ventajas de la implementación en varias
regiones, es posible que los clientes con los usuarios que viajan puedan perder el acceso a los datos almacenados
en caché.
Almacenamiento en caché de fragmentos

Hay algunos casos donde las respuestas que se devuelven contienen parte de datos que es costoso determinar y
todavía siguen actualizadas durante un tiempo razonable. Como ejemplo, piense en un servicio creado por una
línea aérea que ofrece información relacionada con las reservas de vuelos, estado del vuelo, etc. Si el usuario es
miembro del programa de puntos de la compañía aérea, tendría además información relativa a su estado actual y
a las millas acumuladas. Esta información relacionada con el usuario se puede almacenar en un sistema
diferente, pero quizá sea deseable incluirlo en las respuestas devueltas sobre las reservas y el estado de los
vuelos. Esto puede hacerse mediante un proceso denominado almacenamiento en caché de fragmentos. La
representación principal puede devolverse desde el servidor de origen mediante algún tipo de token para indicar
donde se insertará la información relacionada con el usuario.
Considere la siguiente respuesta JSON de una API de back-end.
{
"airline" : "Air Canada",
"flightno" : "871",
"status" : "ontime",
"gate" : "B40",
"terminal" : "2A",
"userprofile" : "$userprofile$"
}
Y el recurso secundario en /userprofile/{userid} que es como sigue,
{ "username" : "Bob Smith", "Status" : "Gold" }

Para determinar la información de usuario adecuada que se va a incluir, API Management tiene que identificar
quién es el usuario final. Este mecanismo depende de la implementación. Por ejemplo, estamos usando la
notificación Subject de un token JWT .
<set-variable
name="enduserid"
value="@(context.Request.Headers.GetValueOrDefault("Authorization","").Split(' ')[1].AsJwt()?.Subject)" />
API Management almacena el valor enduserid en una variable de contexto para su uso posterior. El siguiente
paso es determinar si una solicitud anterior ya ha recuperado la información de usuario y la ha almacenado en la
memoria caché. Para ello, API Management utiliza la directiva cache-lookup-value .
<cache-lookup-value
key="@("userprofile-" + context.Variables["enduserid"])"
variable-name="userprofile" />
Si no hay ninguna entrada en la memoria caché que se corresponda con el valor de clave, no se creará la variable
de contexto userprofile . API Management comprueba el éxito de la búsqueda mediante la directiva de flujo de
control choose .
<choose>
<when condition="@(!context.Variables.ContainsKey("userprofile"))">

</when>
</choose>
Si la variable de contexto userprofile no existe, API Management tendrá que realizar una solicitud HTTP para
recuperarla.
<send-request
mode="new"
response-variable-name="userprofileresponse"
timeout="10"
ignore-error="true">

<set-url>@(new Uri(new Uri("https://apimairlineapi.azurewebsites.net/UserProfile/"),
(string)context.Variables["enduserid"]).AbsoluteUri)
</set-url>
<set-method>GET</set-method>
</send-request>
API Management usa enduserid para construir la dirección URL en el recurso del perfil de usuario. Una vez que
API Management tenga la respuesta, extrae el texto del cuerpo de la respuesta y lo almacena en una variable de
contexto.
<set-variable
name="userprofile"
value="@(((IResponse)context.Variables["userprofileresponse"]).Body.As<string>())" />
Para evitar que API Management realice esta solicitud HTTP de nuevo, cuando el mismo usuario realiza otra
solicitud, puede especificar que se almacenar el perfil de usuario en la memoria caché.
<cache-store-value
value="@((string)context.Variables["userprofile"])" duration="100000" />
API Management almacena el valor en la memoria caché con la misma clave con la que lo intentó recuperar
originalmente. La duración que API Management elige para almacenar el valor debe basarse en la frecuencia de
los cambios de la información y en lo tolerantes que son los usuarios con la información sin actualizar.
Es importante tener en cuenta que la recuperación desde la caché sigue siendo una solicitud de red fuera del
proceso y posiblemente pueda agregar decenas de milisegundos a la solicitud. Las ventajas se derivan de
determinar que la información de perfil de usuario tarda más que eso, debido a que se necesitan realizar
consultas en la base de datos o agregar información de varios back-end.
El último paso del proceso consiste en actualizar la respuesta devuelta con la información de perfil de usuario.


<find-and-replace
from='"$userprofile$"'
to="@((string)context.Variables["userprofile"])" />
Puede elegir incluir las comillas como parte del token para que incluso cuando no se produzca el reemplazo, la
respuesta siga siendo un JSON válido.
Una vez que se combinan todos estos pasos, el resultado final es una directiva similar a la siguiente.
<policies>
<inbound>

<set-variable
name="enduserid"
value="@(context.Request.Headers.GetValueOrDefault("Authorization","").Split(' ')
[1].AsJwt()?.Subject)" />


<cache-lookup-value

<choose>
<when condition="@(!context.Variables.ContainsKey("userprofile"))">

<send-request
mode="new"
response-variable-name="userprofileresponse"
timeout="10"

<set-url>@(new Uri(new Uri("https://apimairlineapi.azurewebsites.net/UserProfile/"),
(string)context.Variables["enduserid"]).AbsoluteUri)</set-url>
</send-request>


<set-variable
name="userprofile"
value="@(((IResponse)context.Variables["userprofileresponse"]).Body.As<string>())" />


<cache-store-value
value="@((string)context.Variables["userprofile"])"
duration="100000" />
</when>
</choose>
<base />
</inbound>
<outbound>

<find-and-replace
from='"$userprofile$"'
to="@((string)context.Variables["userprofile"])" />
<base />
</outbound>
</policies>
Este enfoque de almacenamiento en caché se utiliza principalmente en los sitios web donde se compone HTML
en el servidor para que se pueda representar como una sola página. También puede ser útil en las API donde los
clientes no puedan realizar almacenamiento en caché de HTTP del lado cliente o sea deseable que la
responsabilidad no recaiga en el cliente.
Este mismo tipo de almacenamiento en caché también puede realizarse en los servidores web de back-end con
un servidor de Caché en Redis; sin embargo, el uso del servicio Administración de API para realizar este trabajo
resulta útil cuando los fragmentos en caché proceden de servidores back-end distintos a los de las respuestas
principales.
Control de versiones transparente

Es una práctica común que se admitan al mismo tiempo varias versiones de implementación distintas de una
API. Por ejemplo, admitir diferentes entornos (desarrollo, prueba, producción, etc.) o versiones anteriores de la
API para dar tiempo a los consumidores de la API a migrar a versiones más recientes.
Un método para tratar eso, en lugar de requerir a los desarrolladores de cliente que cambien las direcciones URL
de /v1/customers a /v2/customers , es almacenar en los datos de perfil del cliente la versión de la API que
quieren usar y llamar a la dirección URL adecuada de back-end. Para determinar la dirección URL correcta de
back-end a fin de llamar a un cliente determinado, es necesario consultar algunos datos de configuración. Al
almacenar en caché estos datos de configuración, API Management puede minimizar la reducción del
rendimiento al realizar esta búsqueda.
El primer paso consiste en determinar el identificador usado para configurar la versión deseada. En este ejemplo,
decidí asociar la versión con la clave de suscripción del producto.
<set-variable name="clientid" value="@(context.Subscription.Key)" />
Después, API Management hace una búsqueda en la caché para ver si ya recuperó la versión de cliente deseada.
<cache-lookup-value
key="@("clientversion-" + context.Variables["clientid"])"
variable-name="clientversion" />
A continuación, comprueba si no la encontró en la memoria caché.
<choose>
<when condition="@(!context.Variables.ContainsKey("clientversion"))">
Si API Management no la encontró, la recupera.
<send-request
mode="new"
response-variable-name="clientconfiguresponse"
timeout="10"
<set-url>@(new Uri(new Uri(context.Api.ServiceUrl.ToString() + "api/ClientConfig/"),
(string)context.Variables["clientid"]).AbsoluteUri)</set-url>
</send-request>
Extraemos el texto del cuerpo de respuesta de la respuesta.
<set-variable
name="clientversion"
value="@(((IResponse)context.Variables["clientconfiguresponse"]).Body.As<string>())" />
Lo almacenamos en la caché para un uso futuro.
<cache-store-value
key="@("clientversion-" + context.Variables["clientid"])"
value="@((string)context.Variables["clientversion"])"
duration="100000" />
Y finalmente actualizamos la dirección URL de back-end para seleccionar la versión del servicio requerido por el
cliente.
base-url="@(context.Api.ServiceUrl.ToString() + "api/" + (string)context.Variables["clientversion"] +
"/")" />
La directiva completa es la siguiente:
<inbound>
<base />
<set-variable name="clientid" value="@(context.Subscription.Key)" />
<cache-lookup-value key="@("clientversion-" + context.Variables["clientid"])" variable-
name="clientversion" />

<choose>
<when condition="@(!context.Variables.ContainsKey("clientversion"))">
<send-request mode="new" response-variable-name="clientconfiguresponse" timeout="10" ignore-
error="true">
<set-url>@(new Uri(new Uri(context.Api.ServiceUrl.ToString() + "api/ClientConfig/"),
(string)context.Variables["clientid"]).AbsoluteUri)</set-url>
</send-request>

<set-variable name="clientversion"
value="@(((IResponse)context.Variables["clientconfiguresponse"]).Body.As<string>())" />

<cache-store-value key="@("clientversion-" + context.Variables["clientid"])"
value="@((string)context.Variables["clientversion"])" duration="100000" />
</when>
</choose>
<set-backend-service base-url="@(context.Api.ServiceUrl.ToString() + "api/" +
(string)context.Variables["clientversion"] + "/")" />
</inbound>
Permitir a los consumidores de la API controlar de forma transparente la versión de back-end a la que acceden
los clientes sin tener que actualizar y volver a implementar los clientes es una solución elegante que soluciona
muchos problemas de control de versiones de la API.
Aislamiento de inquilinos
En implementaciones grandes multiinquilino algunas compañías crean grupos independientes de inquilinos en
distintas implementaciones del hardware de back-end. Esto minimiza el número de clientes que se ven afectados
por un problema de hardware en el back-end. También permite que nuevas versiones de software se
implementen en etapas. Lo ideal es que esta arquitectura de back-end sea transparente para los usuarios de las
API. Esto puede lograrse de manera similar con el control de versiones transparente porque se basa en la misma
técnica de manipular la dirección URL de back-end mediante el estado de configuración por clave de API.
En lugar de devolver una versión preferida de la API para cada clave de la suscripción, debe devolver un
identificador que relacione un inquilino con el grupo de hardware asignado. Este identificador se puede usar para
construir la dirección URL apropiada de back-end.
Resumen
La libertad de utilizar la caché de Administración de API de Azure para almacenar cualquier tipo de datos
permite un acceso eficaz a los datos de configuración, lo que puede afectar a la manera de procesar una solicitud
entrante. También puede usarse para almacenar fragmentos de datos que pueden aumentar las respuestas
devueltas desde una API de back-end.
Supervisión de las API con Azure API Management,
Event Hubs y Moesif
El servicio Administración de API proporciona muchas capacidades para mejorar el procesamiento de solicitudes
de HTTP enviadas a la API HTTP. Sin embargo, la existencia de las solicitudes y respuestas es transitoria. Se realiza
la solicitud y fluye a través del servicio Administración de API a la API de back-end. La API procesa la solicitud y se
pasa una respuesta al consumidor de API. El servicio API Management mantiene algunas estadísticas importantes
acerca de las API que se muestran en el panel de Azure Portal, pero aparte de eso, los detalles desaparecen.
Mediante la directiva log-to-eventhub del servicio API Management, puede enviar los detalles de la solicitud y la
respuesta a un centro de eventos de Azure. Existen diversos motivos por los que puede desear generar eventos de
mensajes HTTP que se envían a las API. Algunos ejemplos incluyen traza de auditoría de las actualizaciones,
análisis de uso, alertas de excepción e integraciones de terceros.
Este artículo muestra cómo capturar el mensaje de solicitud y respuesta de HTTP completo, enviarlo a un centro
de eventos y, a continuación, retransmitir ese mensaje a un servicio que proporciona servicios de registro y
supervisión de HTTP.
¿Por qué se envían desde el servicio Administración de API?

Es posible escribir middleware HTTP que se puede conectar a los marcos API HTTP para capturar solicitudes y
respuestas de HTTP e introducirlas en sistemas de registro y supervisión. El inconveniente de este enfoque es que
el middleware HTTP debe integrarse en la API de back-end y debe coincidir con la plataforma de la API. Si hay
varias API, todas deben implementar el middleware. A menudo existen motivos por los que no se pueden
actualizar las API de back-end.
El usp del servicio Azure API Management para la integración con la infraestructura de registro proporciona una
solución centralizada e independiente de la plataforma. También es escalable, en parte debido a las capacidades de
replicación geográfica de Azure API Management.
¿Por qué se envía a un Centro de eventos de Azure?

Es razonable preguntar por qué crear una directiva que es específica de Azure Event Hubs Hay muchos lugares
diferentes donde puede ser conveniente registrar mis solicitudes. ¿Por qué no simplemente enviar las solicitudes
directamente al destino final? Es una opción. Sin embargo, al realizar solicitudes de registro desde un servicio API
Management, es necesario tener en cuenta cómo afectarán los mensajes de registro al rendimiento de la API. Para
manejar los aumentos graduales de la carga puede aumentar las instancias disponibles de los componentes del
sistema o aprovechar las ventajas de la replicación geográfica. Sin embargo, picos de tráfico cortos pueden hacer
que las solicitudes se retrasen si las solicitudes a la infraestructura de registro empiezan a ralentizarse debido a la
carga.
Azure Event Hubs está diseñado para la entrada de grandes volúmenes de datos, con capacidad para tratar con un
número mucho mayor de eventos que el número de solicitudes de HTTP que procesan la mayoría de las API. El
centro de eventos actúa como un tipo de búfer sofisticado entre el servicio API Management y la infraestructura
que almacena y procesa los mensajes. Esto garantiza que no se verá afectado el rendimiento de la API debido a la
infraestructura de registro.
Una vez que los datos se han pasado a un centro de eventos, se conservan y esperan a que los consumidores del
centro de eventos los procese. Al centro de eventos no le importa cómo se procesa, simplemente se ocupa de
asegurarse de que el mensaje se entregue correctamente.
Event Hubs ofrece la posibilidad de transmitir eventos a varios grupos de consumidores. Esto permite que
sistemas diferentes procesen los eventos. Esto permite muchos escenarios de integración sin agregar retrasos en
el procesamiento de la solicitud de API dentro del servicio Administración de API, ya que solo es necesario
generar un evento.
Una directiva para enviar mensajes de aplicación/http

Un Centro de eventos acepta datos de eventos como una cadena simple. El contenido de esa cadena es decisión
suya. Para poder empaquetar una solicitud HTTP y enviarla a Event Hubs, es necesario formatear la cadena con la
información de solicitud o respuesta. En situaciones como esta, si hay un formato existente que podamos reusar, es
posible que no necesitemos escribir nuestro propio código de análisis. Inicialmente consideré el uso de HAR para
enviar solicitudes y respuestas de HTTP. Sin embargo, este formato está optimizado para almacenar una secuencia
de solicitudes HTTP en un formato basado en JSON. Contenía un número de elementos obligatorios que
agregaba una complejidad innecesaria para el escenario de pasar el mensaje HTTP a través del cable.
Una opción alternativa era usar el tipo de soporte físico application/http , como se describe en la especificación
HTTP RFC 7230. Este tipo de soporte físico usa el mismo formato que se usa para enviar realmente mensajes de
HTTP a través del cable, pero el mensaje completo se puede colocar en el cuerpo de otra solicitud de HTTP. En
nuestro caso, el cuerpo se usará como mensaje para enviarlo a Event Hubs. Convenientemente, hay un analizador
en las bibliotecas de Microsoft ASP.NET Web API 2.2 Cliente que puede analizar este formato y convertirlo a
HttpRequestMessage nativo y objetos HttpResponseMessage .
Para poder crear este mensaje, se deben aprovechar las expresiones de directiva basadas en C# en Azure API
Management. A continuación se proporciona la directiva que envía un mensaje de solicitud HTTP a Azure Event
Hubs.
<log-to-eventhub logger-id="conferencelogger" partition-id="0">

@{
var requestLine = string.Format("{0} {1} HTTP/1.1\r\n",
context.Request.Method,
context.Request.Url.Path + context.Request.Url.QueryString);
var body = context.Request.Body?.As<string>(true);

if (body != null && body.Length > 1024)
{
body = body.Substring(0, 1024);
}
var headers = context.Request.Headers

.Where(h => h.Key != "Authorization" && h.Key != "Ocp-Apim-Subscription-Key")
.Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ", h.Value)))
.ToArray<string>();
var headerString = (headers.Any()) ? string.Join("\r\n", headers) + "\r\n" : string.Empty;
return "request:" + context.Variables["message-id"] + "\n"

+ requestLine + headerString + "\r\n" + body;
}
</log-to-eventhub>
Declaración de directiva
Hay algunas cosas específicas que merece la pena mencionar acerca de esta expresión de directiva. La directiva
log-to-eventhub tiene un atributo denominado logger-id que hace referencia al nombre del registrador que se ha
creado en el servicio API Management. Los detalles de cómo configurar un registrador del centro de eventos en el
servicio API Management pueden encontrarse en el documento Cómo registrar eventos en Azure Event Hubs en
Azure API Management. El segundo atributo es un parámetro opcional que indica a Event Hubs en qué partición
almacenar el mensaje. Event Hubs usa particiones para habilitar la escalabilidad y requiere dos como mínimo. La
entrega ordenada de mensajes solo se garantiza dentro de una partición. Si no se indica al centro de eventos en
qué partición desea colocar el mensaje, usa un algoritmo round-robin para distribuir la carga. Sin embargo, eso
puede hacer que algunos de nuestros mensajes no se procesen en el orden correcto.
Particiones
Para garantizar que nuestros mensajes se entregan a los consumidores en orden y aprovechar la capacidad de
distribución de carga de las particiones, elegí enviar mensajes de solicitud de HTTP a una partición y los mensajes
de respuesta de HTTP a una segunda partición. Esto garantiza una distribución equilibrada de la carga y se puede
tener la seguridad de que todas las solicitudes y todas las respuestas se consumirán en orden. Es posible que una
respuesta se consuma antes de la solicitud correspondiente, pero como esto no es un problema porque tenemos
un mecanismo diferente para correlacionar las solicitudes a las respuestas y sabemos que las solicitudes van
siempre antes las respuestas.
Cargas de HTTP
Después de crear el valor requestLine , se comprueba si se debe truncar el cuerpo de la solicitud. El cuerpo de la
solicitud se trunca a solo 1024. Este valor podría aumentarse; sin embargo, los mensajes individuales del centro de
eventos están limitados a 256 KB, por lo que es probable que algunos cuerpos de los mensajes HTTP no quepan
en un único mensaje. Al realizar el registro y análisis, una cantidad significativa de información puede derivarse
simplemente de la línea de solicitud de HTTP y los encabezados. Además, muchas solicitudes de API devuelven
solo cuerpos pequeños, por lo que la pérdida de valor de la información debido al truncamiento de cuerpos
grandes es bastante mínima en comparación con la reducción de los costos de almacenamiento, transferencia y
transformación para mantener todo el contenido del cuerpo. Una nota final acerca del procesamiento del cuerpo
es que tenemos que pasar true al método As<string>() porque podemos leer el contenido del cuerpo, pero
queremos que la API de back-end pueda leerlo también. Al pasar true a este método, hacemos que el cuerpo se
almacene en la búfer para que se pueda leer una segunda vez. Es importante tenerlo en cuenta si tiene una API
que carga archivos grandes o usa el sondeo largo. En estos casos, es mejor evitar totalmente la lectura del cuerpo.
Encabezados HTTP
Los encabezados HTTP pueden transferirse al formato del mensaje con un formato simple de par clave/valor.
Hemos decidido eliminar ciertos campos de seguridad confidenciales para evitar la pérdida innecesaria de
información de credenciales. No es probable que se usen claves de API y otras credenciales para los análisis. Si
deseamos realizar el análisis en el usuario y el producto específico que usa, podríamos obtenerlo del objeto
context y agregarlo al mensaje.
Metadatos del mensaje

Cuando se crea el mensaje completo para enviarlo al Centro de eventos, la primera línea no es realmente parte del
mensaje application/http . La primera línea son metadatos adicionales que incluyen si el mensaje es un mensaje
de solicitud o de respuesta y un identificador de mensaje que se usa para correlacionar las solicitudes y las
respuestas. El identificador del mensaje se crea mediante otra directiva que tiene este aspecto:
<set-variable name="message-id" value="@(Guid.NewGuid())" />
Se podría haber creado el mensaje de solicitud, almacenarlo en una variable hasta que se devuelva la respuesta y,
después, simplemente enviar la solicitud y la respuesta como un solo mensaje. Sin embargo, al enviar la solicitud y
la respuesta de forma independiente y usar un identificador de mensaje para correlacionar las dos, obtenemos un
poco más flexibilidad en el tamaño de mensaje, la capacidad de aprovechar varias particiones al tiempo que se
mantiene el orden de los mensajes y la solicitud aparecerá antes en nuestro panel de registro. También puede
haber algunos escenarios donde nunca se envíe una respuesta válida al centro de eventos, posiblemente debido a
un error de solicitud irrecuperable en el servicio API Management, pero aún tendremos un registro de la solicitud.
La directiva para enviar el mensaje de respuesta HTTP es parecida a la solicitud; por tanto, la configuración de
directiva completa tiene el siguiente aspecto:
<policies>
<inbound>
<set-variable name="message-id" value="@(Guid.NewGuid())" />
@{
var requestLine = string.Format("{0} {1} HTTP/1.1\r\n",
context.Request.Url.Path +
context.Request.Url.QueryString);
var body = context.Request.Body?.As<string>(true);

{
}
var headers = context.Request.Headers

.Where(h => h.Key != "Authorization" && h.Key != "Ocp-Apim-Subscription-Key")
.Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ", h.Value)))
.ToArray<string>();
return "request:" + context.Variables["message-id"] + "\n"

+ requestLine + headerString + "\r\n" + body;
}
</log-to-eventhub>
</inbound>
<backend>
<forward-request follow-redirects="true" />
</backend>
<outbound>
@{
var statusLine = string.Format("HTTP/1.1 {0} {1}\r\n",
context.Response.StatusCode,
context.Response.StatusReason);
var body = context.Response.Body?.As<string>(true);

{
}
var headers = context.Response.Headers

.Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ",
h.Value)))
.ToArray<string>();
return "response:" + context.Variables["message-id"] + "\n"

+ statusLine + headerString + "\r\n" + body;
}
</log-to-eventhub>
</outbound>
</policies>
La directiva set-variable crea un valor que sea accesible por la directiva log-to-eventhub en la sección
<inbound> y la sección <outbound> .
Recepción de eventos de Event Hubs

Se reciben eventos del Centro de eventos de Azure mediante el protocolo AMQP. El equipo de Service Bus de
Microsoft hizo que las bibliotecas cliente disponibles para facilitar los eventos de consumo. Existen dos enfoques
diferentes admitidos, uno se está un Consumidor directo y la otra es emplear la clase EventProcessorHost .
Ejemplos de estos dos enfoques pueden encontrarse en la Guía de programación de Event Hubs. La versión
abreviada de las diferencias es que Direct Consumer proporciona un control total y EventProcessorHost realiza
parte del trabajo de fontanería por usted, pero hace determinadas suposiciones sobre cómo procesará los eventos.
EventProcessorHost
En este ejemplo, se usa EventProcessorHost por motivos de simplicidad; sin embargo es posible que no sea la
mejor opción para este escenario concreto. EventProcessorHost realiza el trabajo duro de asegurarse de que no
tiene que preocuparse acerca de problemas de subprocesamiento dentro de una clase de procesador de eventos
concreto. Sin embargo, en nuestro escenario, simplemente estamos convirtiendo el mensaje a otro formato y lo
pasamos a otro servicio con un método asincrónico. No es necesario actualizar el estado compartido y, por tanto,
no hay riesgo de problemas de subprocesamiento. Para la mayoría de los escenarios, EventProcessorHost es
probablemente la mejor opción y es ciertamente la opción más fácil.
IEventProcessor
El concepto central al usar EventProcessorHost es crear una implementación de la interfaz IEventProcessor que
contenga el método ProcessEventAsync . La esencia de ese método se muestra aquí:
async Task IEventProcessor.ProcessEventsAsync(PartitionContext context, IEnumerable<EventData> messages)

{
foreach (EventData eventData in messages)

{
_Logger.LogInfo(string.Format("Event received from partition: {0} - {1}",
context.Lease.PartitionId,eventData.PartitionKey));
try
{
var httpMessage = HttpMessage.Parse(eventData.GetBodyStream());
await _MessageContentProcessor.ProcessHttpMessage(httpMessage);
}
catch (Exception ex)
{
_Logger.LogError(ex.Message);
}
}
... checkpointing code snipped ...
}
Se pasa una lista de objetos EventData al método y realizamos la iteración en esa lista. Se analizan los bytes de
cada método en un objeto HttpMessage y ese objeto se pasa a una instancia de IHttpMessageProcessor.
HttpMessage
La instancia HttpMessage contiene tres elementos de datos:
public class HttpMessage

{
public Guid MessageId { get; set; }
public bool IsRequest { get; set; }
public HttpRequestMessage HttpRequestMessage { get; set; }
public HttpResponseMessage HttpResponseMessage { get; set; }
... parsing code snipped ...
La instancia HttpMessage contiene un GUID MessageId que nos permite conectar la solicitud de HTTP a la
respuesta de HTTP correspondiente y un valor booleano que identifica si el objeto contiene una instancia de
HttpRequestMessage y HttpResponseMessage. Mediante las clases HTTP integradas de System.Net.Http , puede
aprovechar el código de análisis application/http que se incluye en System.Net.Http.Formatting .
IHttpMessageProcessor
La instancia HttpMessage se reenvía luego a la implementación de IHttpMessageProcessor , que es una interfaz que
se creó para desacoplar la recepción y la interpretación del evento del centro de eventos de Azure y el
procesamiento real de esta.
Reenvío del mensaje HTTP

En este ejemplo, decidí que sería interesante insertar la solicitud HTTP en el análisis de API de Moesif. Moesif es
un servicio basado en la nube que se especializa en análisis y depuración HTTP. Tiene un nivel gratuito, por lo que
resulta fácil probarlo y nos permite ver en tiempo real cómo fluyen las solicitudes de HTTP a través de nuestro
servicio Administración de API.
Las implementación IHttpMessageProcessor tiene este aspecto:
public class MoesifHttpMessageProcessor : IHttpMessageProcessor

{
private readonly string RequestTimeName = "MoRequestTime";
private MoesifApiClient _MoesifClient;
private ILogger _Logger;
private string _SessionTokenKey;
private string _ApiVersion;
public MoesifHttpMessageProcessor(ILogger logger)
{
var appId = Environment.GetEnvironmentVariable("APIMEVENTS-MOESIF-APP-ID",
EnvironmentVariableTarget.Process);
_MoesifClient = new MoesifApiClient(appId);
_SessionTokenKey = Environment.GetEnvironmentVariable("APIMEVENTS-MOESIF-SESSION-TOKEN",
_ApiVersion = Environment.GetEnvironmentVariable("APIMEVENTS-MOESIF-API-VERSION",
_Logger = logger;
}
public async Task ProcessHttpMessage(HttpMessage message)

{
if (message.IsRequest)
{
message.HttpRequestMessage.Properties.Add(RequestTimeName, DateTime.UtcNow);
return;
}
EventRequestModel moesifRequest = new EventRequestModel()

{
Time = (DateTime) message.HttpRequestMessage.Properties[RequestTimeName],
Uri = message.HttpRequestMessage.RequestUri.OriginalString,
Verb = message.HttpRequestMessage.Method.ToString(),
Headers = ToHeaders(message.HttpRequestMessage.Headers),
ApiVersion = _ApiVersion,
IpAddress = null,
Body = message.HttpRequestMessage.Content != null ? System.Convert.ToBase64String(await
message.HttpRequestMessage.Content.ReadAsByteArrayAsync()) : null,
TransferEncoding = "base64"
};
EventResponseModel moesifResponse = new EventResponseModel()

{
Time = DateTime.UtcNow,
Status = (int) message.HttpResponseMessage.StatusCode,
IpAddress = Environment.MachineName,
Headers = ToHeaders(message.HttpResponseMessage.Headers),
Body = message.HttpResponseMessage.Content != null ? System.Convert.ToBase64String(await
message.HttpResponseMessage.Content.ReadAsByteArrayAsync()) : null,
TransferEncoding = "base64"
};
Dictionary<string, string> metadata = new Dictionary<string, string>();

metadata.Add("ApimMessageId", message.MessageId.ToString());
EventModel moesifEvent = new EventModel()

{
Request = moesifRequest,
Response = moesifResponse,
SessionToken = _SessionTokenKey != null ?
message.HttpRequestMessage.Headers.GetValues(_SessionTokenKey).FirstOrDefault() : null,
Tags = null,
UserId = null,
Metadata = metadata
};
Dictionary<string, string> response = await _MoesifClient.Api.CreateEventAsync(moesifEvent);
_Logger.LogDebug("Message forwarded to Moesif");

}
private static Dictionary<string, string> ToHeaders(HttpHeaders headers)

{
IEnumerable<KeyValuePair<string, IEnumerable<string>>> enumerable =
headers.GetEnumerator().ToEnumerable();
return enumerable.ToDictionary(p => p.Key, p => p.Value.GetEnumerator()
.ToEnumerable()
.ToList()
.Aggregate((i, j) => i + ", " + j));
}
}
MoesifHttpMessageProcessor aprovecha las ventajas de una biblioteca de API en C# para Moesif que facilita la
inserción de datos de eventos HTTP en su servicio. Para enviar datos HTTP a Collector API de Moesif, necesita una
cuenta y un identificador de aplicación. Para obtener el identificador de aplicación de Moesif, cree una cuenta en el
sitio web de Moesif y, luego, vaya al menú de la parte superior derecha -> App Setup (Configuración de
aplicación).
Ejemplo completo
El código fuente y las pruebas del ejemplo se encuentran en GitHub. Necesita un servicio API Management, un
centro de eventos conectado y una cuenta de almacenamiento para ejecutar el ejemplo por su cuenta.
El ejemplo es simplemente una aplicación de consola sencilla que realiza escuchas de eventos procedentes del
centro de eventos, los convierte en objetos EventRequestModel y EventResponseModel de Moesif y, luego, los
reenvía a Collector API de Moesif.
En la siguiente imagen animada, puede ver una solicitud realizada a una API en el portal para desarrolladores, la
aplicación de consola que muestra el mensaje que se recibe, procesa y reenvía y, a continuación, la solicitud y
respuesta que se muestran en la secuencia de eventos.
Resumen
El servicio Azure API Management proporciona un lugar ideal para capturar el tráfico HTTP hacia y desde la API.
Azure Event Hubs es una solución altamente escalable y de bajo costo para capturar ese tráfico y colocarlo en
sistemas de procesamiento secundario para registro, supervisión y otros análisis sofisticados. La conexión a
sistemas de supervisión de tráfico de terceros como Moesif se reduce a unas cuantas docenas de líneas de código.
Pasos siguientes
Obtenga más información acerca de Azure Event Hubs
Introducción a Azure Event Hubs
Recepción de mensajes con EventProcessorHost
Guía de programación de Event Hubs
Obtener más información acerca de la integración de API Management y Event Hubs
Cómo registrar eventos en Azure Event Hubs en Azure API Management
Referencia de entidad del registrador
referencia de la directiva log-to-eventhub
Limitación avanzada de solicitudes con Azure API
Management
La posibilidad de limitar las solicitudes entrantes es un rol clave de Azure API Management. Ya sea mediante el
control de la velocidad de solicitudes o de las solicitudes y los datos totales transferidos, Administración de API
permite a los proveedores de API proteger sus API de uso indebido y crear valor para los diferentes niveles de
productos de API.
Limitación basada en producto

Hasta la fecha, las funcionalidades de limitación de velocidad se han circunscrito al ámbito de una suscripción de
producto concreta, que se define en Azure Portal. Resulta útil para que el proveedor de la API aplique límites a los
desarrolladores que inicien sesión para usar su API, pero no ayuda, por ejemplo, a imponer limitaciones a los
usuarios finales individuales de la API. Es posible que un solo usuario de la aplicación del desarrollador consuma
toda la cuota e impida que otros clientes del desarrollador puedan usar la aplicación. Además, es posible que varios
clientes que generen un gran volumen de solicitudes limiten el acceso a los usuarios ocasionales.
Limitación por clave personalizada

Las nuevas directivas rate-limit-by-key y quota-by-key ofrecen una solución más flexible para el control del tráfico.
Estas nuevas directivas permiten definir expresiones para identificar las claves que se usan para realizar un
seguimiento del uso del tráfico. El funcionamiento de esto se ilustra más claramente con un ejemplo.
Limitación por dirección IP

Las siguientes directivas restringen una única dirección IP de cliente a solo 10 llamadas por minuto, con un total de
1 000 000 llamadas y 10 000 kilobytes de ancho de banda al mes.
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.IpAddress)" />
<quota-by-key calls="1000000"
bandwidth="10000"
renewal-period="2629800"
Si todos los clientes en Internet utilizasen una única dirección IP, esta podría ser una forma eficaz de limitar el uso
por usuario. Pero es probable que varios usuarios compartan una única dirección IP pública debido a su acceso a
Internet a través de un dispositivo NAT. A pesar de esto, es posible que para las API que permiten el acceso no
autenticado, IpAddress sea la mejor opción.
Limitación por identidad de usuario

Si se autentica un usuario final, puede generarse una clave de limitación basada en información que identifica de
forma única a ese usuario.
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
En este ejemplo se muestra cómo extraer el encabezado de autorización, se convierte en objeto JWT y se usa el
firmante del token para identificar al usuario y usarlo como clave de limitación de velocidad. Si la identidad del
usuario se almacena en el JWT como una de las otras notificaciones, ese valor podría usarse en su lugar.
Directivas de combinación
Aunque las nuevas directivas de limitación proporcionan más control que las directivas existentes de limitación,
sigue siendo útil combinar ambas capacidades. La limitación por clave de suscripción de producto (Limitar tarifa de
llamadas por suscripción y Establecer cuota de uso por suscripción) es una excelente manera de habilitar la
monetización de una API mediante el cobro por niveles de uso. El control más preciso de poder limitar por usuario
es complementario e impide que el comportamiento de un usuario degrade la experiencia de otro.
Limitación controlada por cliente

Cuando la clave de limitación se define con una expresión de directiva, es el proveedor de la API el que elige el
ámbito de la limitación. Pero puede que un desarrollador desee controlar cómo limita la frecuencia de sus propios
clientes. Esto lo podría habilitar el proveedor de la API introduciendo un encabezado personalizado que permita a
la aplicación cliente del desarrollador comunicar la clave a la API.
renewal-period="60"
counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>
Así se permite a la aplicación cliente del desarrollador elegir cómo se quiere crear la clave de limitación de
velocidad. Los desarrolladores del cliente pueden crear sus propios niveles de velocidad asignando conjuntos de
claves a los usuarios y rotando el uso de claves.
Resumen
Azure API Management ofrece limitación de velocidad y de cuota para proteger y agregar valor al servicio de API.
Las nuevas directivas de limitación con reglas de ámbito personalizadas permiten un control más preciso sobre las
directivas para permitir a los clientes crear aplicaciones aún mejores. Los ejemplos de este artículo muestran el uso
de estas nuevas directivas fabricando claves de limitación de velocidad con direcciones IP de cliente, identidad de
usuario y valores generados por el cliente. Pero hay muchas más partes del mensaje que podrían usarse como, por
ejemplo, agente de usuario, fragmentos de ruta de dirección URL, tamaño del mensaje.
Pasos siguientes
Háganos sus comentarios en la conversación Disqus sobre este tema. Sería estupendo conocer otros posibles
valores de clave que hayan sido una elección lógica en sus escenarios.
Uso de servicios externos del servicio de
administración de API de Azure
Las directivas disponibles en el servicio Azure API Management pueden llevar a cabo una gran variedad de trabajo
útil basado exclusivamente en la solicitud entrante, la respuesta saliente y la información de configuración básica.
Pero la interacción con servicios externos de las directivas de API Management brinda muchas más oportunidades.
Anteriormente ha visto cómo interactuar con el servicio del Centro de eventos de Azure con fines de registro,
supervisión y análisis. En este artículo encontrará las directivas que permiten interactuar con cualquier servicio
externo basado en HTTP. Dichas directivas se pueden usar para desencadenar eventos remotos o recuperar
información que se utiliza para manipular en cierto modo la solicitud y la respuesta originales.
Send-One-Way-Request
Es posible que la interacción externa más sencilla sea el estilo de fire and forget de solicitud que permite que se
notifique a un servicio externo de algún tipo de evento importante. La directiva de flujo de control choose puede
utilizarse para detectar cualquier tipo de condición que le interese. Si se cumple la condición, puede hacer una
solicitud HTTP externa usando la directiva Envío de solicitud unidireccional. Podría tratarse de una solicitud para un
sistema de mensajería como Hipchat o Slack o una API de Correo como SendGrid o MailChimp, o bien para
incidentes de soporte técnico críticos como PagerDuty. Todos estos sistemas de mensajería tienen API HTTP
sencillas que se pueden invocar.
Alerta con Slack
En el siguiente ejemplo puede ver cómo enviar un mensaje a un salón de chat de Slack si el código de estado de
respuesta HTTP es mayor o igual que 500. Un error de intervalo 500 indica un problema con la API de back-end
cuyo cliente no puede resolver por sí mismo. Normalmente requiere algún tipo de intervención por parte de API
Management.
<choose>
<when condition="@(context.Response.StatusCode >= 500)">
<send-one-way-request mode="new">
<set-url>https://hooks.slack.com/services/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</set-url>
<set-method>POST</set-method>
<set-body>@{
return new JObject(
new JProperty("username","APIM Alert"),
new JProperty("icon_emoji", ":ghost:"),
new JProperty("text", String.Format("{0} {1}\nHost: {2}\n{3} {4}\n User: {5}",
context.Request.Url.Path + context.Request.Url.QueryString,
context.Request.Url.Host,
context.Response.StatusReason,
context.User.Email
))
).ToString();
}</set-body>
</send-one-way-request>
</when>
</choose>
Slack tiene la noción de enlaces web entrantes. Al configurar un webhook entrante, Slack genera una dirección
URL especial que permite hacer una sencilla solicitud POST y pasar un mensaje al canal de Slack. El cuerpo JSON
creado se basa en un formato definido por Slack.
¿Es fire and forget lo suficientemente bueno?

Existen ciertos compromisos cuando se usa un estilo de fire and forget de solicitud. Si por algún motivo se produce
un error en la solicitud, este no se notificará. En esta situación concreta, no se garantizan la complejidad de tener un
sistema de informe de errores secundario ni el costo de rendimiento adicional de esperar la respuesta. En aquellos
escenarios donde sea esencial comprobar la respuesta, la directiva send-request constituye una mejor opción.
send-request
La directiva send-request permite usar un servicio externo para realizar funciones complejas de procesamiento y
devolver datos al servicio de Administración de API que pueden usarse para un posterior procesamiento de
directivas.
Autorización de tokens de referencia
Una de las funciones principales de API Management es proteger los recursos de back-end. Si el servidor de
autorización que usa su API crea tokens de JWT como parte de su flujo de OAuth2, igual que hace Azure Active
Directory, puede usar la directiva validate-jwt para comprobar la validez del token. Algunos servidores de
autorización crean lo que se denomina tokens de referencia, que no se pueden verificar sin realizar una devolución
de llamada al servidor de autorización.
Introspección estandarizada
En el pasado, no existía ninguna forma estandarizada de verificar un token de referencia con un servidor de
autorización. Pero IETF publicó un estándar propuesto recientemente, RFC 7662 , que define cómo un servidor de
recursos puede comprobar la validez de un token.
Extracción del token
El primer paso es extraer el token del encabezado de autorización. El formato del valor de encabezado debe constar
del esquema de autorización Bearer , un solo espacio y el token de autorización según RFC 6750.
Desafortunadamente, hay casos donde se omite el esquema de autorización. Para tener esto en cuenta durante el
análisis, API Management divide el valor de encabezado en un espacio y selecciona la última cadena de la matriz
de cadenas devuelta. Esto proporciona una solución alternativa para los encabezados de autorización con formato
incorrecto.
<set-variable name="token" value="@(context.Request.Headers.GetValueOrDefault("Authorization","scheme

param").Split(' ').Last())" />
Realización de la solicitud de validación

Una vez que API Management tiene el token de autorización, API Management puede realizar la solicitud para
validarlo. RFC 7662 llama introspección a este proceso y requiere que establezca POST en un formulario HTML en
el recurso de introspección. El formulario HTML debe contener al menos un par clave-valor con la clave token .
Esta solicitud para el servidor de autorización también debe autenticarse a fin de garantizar que los clientes
malintencionados no puedan rastrear tokens válidos.
<send-request mode="new" response-variable-name="tokenstate" timeout="20" ignore-error="true">
<set-url>https://microsoft-apiappec990ad4c76641c6aea22f566efc5a4e.azurewebsites.net/introspection</set-url>
<set-header name="Authorization" exists-action="override">
<value>basic dXNlcm5hbWU6cGFzc3dvcmQ=</value>
</set-header>
<set-header name="Content-Type" exists-action="override">
<value>application/x-www-form-urlencoded</value>
</set-header>
<set-body>@($"token={(string)context.Variables["token"]}")</set-body>
</send-request>
Comprobación de la respuesta
El atributo response-variable-name sirve para proporcionar acceso a la respuesta devuelta. El nombre definido en
esta propiedad se puede usar como clave en el diccionario context.Variables para acceder al objeto IResponse .
En el objeto de respuesta, puede recuperar el cuerpo, y RFC 7622 indica a API Management que la respuesta debe
ser un objeto JSON que contenga al menos una propiedad denominada active , que es un valor booleano.
Cuando active es true, el token se considera válido.
Notificación de error
Puede usar una directiva <choose> para detectar si el token no es válido y, en caso de no serlo, devolver una
respuesta 401.
<choose>
<when condition="@((bool)((IResponse)context.Variables["tokenstate"]).Body.As<JObject>()["active"] ==
false)">
<return-response response-variable-name="existing response variable">
<set-status code="401" reason="Unauthorized" />
<set-header name="WWW-Authenticate" exists-action="override">
<value>Bearer error="invalid_token"</value>
</set-header>
</return-response>
</when>
</choose>
Según RFC 6750, que describe cómo se deben usar los tokens de bearer , API Management también devuelve un
encabezado WWW-Authenticate con la respuesta 401. WWW -Authenticate está pensado para indicar a un cliente
cómo crear una solicitud debidamente autorizada. Debido a la gran variedad de enfoques posibles con el marco
OAuth2, es difícil comunicar toda la información necesaria. Por fortuna, se están adoptando medidas para enseñar
a los clientes a autorizar debidamente las solicitudes a un servidor de recursos.
Solución final
Al final, obtendrá la siguiente directiva:
<inbound>


</set-header>
</set-header>
</send-request>
<choose>

false)">

</set-header>
</return-response>
</when>
</choose>
<base />
</inbound>
Este ejemplo es solo uno de los muchos que hay sobre cómo puede usarse la directiva send-request para integrar
servicios externos útiles en el proceso de solicitudes y respuestas que fluyen a través del servicio de API
Management.
Composición de respuesta
La directiva send-request se puede emplear para mejorar una solicitud principal a un sistema de back-end, como
vio en el ejemplo anterior, o bien se puede usar como una sustitución íntegra de la llamada de back-end. Gracias a
esta técnica, puede compilar fácilmente recursos compuestos que se agregan desde varios sistemas diferentes.
Creación de un panel
A veces le gustaría exponer información existente en varios sistemas de back-end, por ejemplo, para realizar un
panel. Los KPI proceden de los distintos back-end, pero prefiere no proporcionarles acceso directo y sería mejor si
se pudiera recuperar toda la información en una única solicitud. Es posible que parte de la información de back-
end deba segmentarse, desglosarse y corregirse un poco primero. Poder almacenar en caché ese recurso
compuesto sería útil para reducir la carga de back-end, pues ya sabe que los usuarios tienen la costumbre de
recurrir a la tecla F5 para ver si pueden cambiar sus métricas de déficit de rendimiento.
Emulación del recurso
El primer paso para crear el recurso del panel es configurar una nueva operación en Azure Portal. Se trata de una
operación de marcador de posición usada para configurar una directiva de composición a fin de compilar el
recurso dinámico.
Realización de las solicitudes
Una vez creada la operación,puede configurar una directiva para esa operación en concreto.
El primer paso consiste en extraer los parámetros de consulta de la solicitud entrante, de modo que pueda
reenviarlos al back-end. En este ejemplo, el panel muestra información basada en un período de tiempo y, por
tanto, tiene los parámetros fromDate y toDate . Puede usar la directiva set-variable para extraer la información
de la dirección URL de la solicitud.
<set-variable name="fromDate" value="@(context.Request.Url.Query["fromDate"].Last())">

<set-variable name="toDate" value="@(context.Request.Url.Query["toDate"].Last())">
Una vez que tiene esta información, puede realizar solicitudes a todos los sistemas de back-end. Cada solicitud
construye una nueva dirección URL con la información de los parámetros y llama a su servidor correspondiente y
almacena la respuesta en una variable de contexto.
<send-request mode="new" response-variable-name="revenuedata" timeout="20" ignore-error="true">
<set-url>@($"https://accounting.acme.com/salesdata?from={(string)context.Variables["fromDate"]}&to=
{(string)context.Variables["fromDate"]}")"</set-url>
</send-request>
<send-request mode="new" response-variable-name="materialdata" timeout="20" ignore-error="true">

<set-url>@($"https://inventory.acme.com/materiallevels?from={(string)context.Variables["fromDate"]}&to=
</send-request>
<send-request mode="new" response-variable-name="throughputdata" timeout="20" ignore-error="true">

<set-url>@($"https://production.acme.com/throughput?from={(string)context.Variables["fromDate"]}&to=
</send-request>
<send-request mode="new" response-variable-name="accidentdata" timeout="20" ignore-error="true">

<set-url>@($"https://production.acme.com/accidentdata?from={(string)context.Variables["fromDate"]}&to=
</send-request>
Estas solicitudes se ejecutan en secuencia, que no es lo ideal.

Respuesta
Para construir la respuesta compuesta, puede usar la directiva return-response. El elemento set-body puede usar
una expresión para construir un nuevo elemento JObject con todas las representaciones de componentes
insertadas como propiedades.

<set-status code="200" reason="OK" />
<value>application/json</value>
</set-header>
<set-body>
@(new JObject(new JProperty("revenuedata",((IResponse)context.Variables["revenuedata"]).Body.As<JObject>
()),
new JProperty("materialdata",((IResponse)context.Variables["materialdata"]).Body.As<JObject>
()),
new JProperty("throughputdata",
((IResponse)context.Variables["throughputdata"]).Body.As<JObject>()),
new JProperty("accidentdata",((IResponse)context.Variables["accidentdata"]).Body.As<JObject>
())
).ToString())
</set-body>
</return-response>
Este es el aspecto de la directiva completa:

<policies>
<inbound>
<set-variable name="fromDate" value="@(context.Request.Url.Query["fromDate"].Last())">

<set-variable name="toDate" value="@(context.Request.Url.Query["toDate"].Last())">
<send-request mode="new" response-variable-name="revenuedata" timeout="20" ignore-error="true">

<set-url>@($"https://accounting.acme.com/salesdata?from={(string)context.Variables["fromDate"]}&to=
</send-request>
<send-request mode="new" response-variable-name="materialdata" timeout="20" ignore-error="true">

<set-url>@($"https://inventory.acme.com/materiallevels?from={(string)context.Variables["fromDate"]}&to=
</send-request>
<send-request mode="new" response-variable-name="throughputdata" timeout="20" ignore-error="true">

<set-url>@($"https://production.acme.com/throughput?from={(string)context.Variables["fromDate"]}&to=
</send-request>
<send-request mode="new" response-variable-name="accidentdata" timeout="20" ignore-error="true">

<set-url>@($"https://production.acme.com/accidentdata?from={(string)context.Variables["fromDate"]}&to=
</send-request>

<set-status code="200" reason="OK" />
<value>application/json</value>
</set-header>
<set-body>
@(new JObject(new JProperty("revenuedata",
((IResponse)context.Variables["revenuedata"]).Body.As<JObject>()),
new JProperty("materialdata",
((IResponse)context.Variables["materialdata"]).Body.As<JObject>()),
new JProperty("throughputdata",
((IResponse)context.Variables["throughputdata"]).Body.As<JObject>()),
new JProperty("accidentdata",
((IResponse)context.Variables["accidentdata"]).Body.As<JObject>())
).ToString())
</set-body>
</return-response>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
</policies>
En la configuración de la operación del marcador de posición, puede establecer el recurso del panel para que se
almacene en caché durante al menos una hora.
Resumen
El servicio de administración de API de Azure proporciona directivas flexibles que se pueden aplicar de forma
selectiva al tráfico HTTP y permite la composición de servicios de back-end. Si desea mejorar la puerta de enlace
de la API con funciones de alerta, comprobación, capacidades de validación o crear nuevos recursos compuestos
basados en varios servicios de back-end, la directiva send-request y otras relacionadas ofrecen todo un mundo de
posibilidades.
Cómo usar valores con nombre en las directivas de
En API Management, las directivas constituyen una funcionalidad eficaz del sistema que permite a Azure Portal
cambiar el comportamiento de la API mediante la configuración. Las directivas son una colección de declaraciones
que se ejecutan secuencialmente en la solicitud o respuesta de una API. Las instrucciones de las directivas se
pueden crear con valores de texto literal, expresiones de directiva y valores con nombre.
Cada instancia del servicio de API Management tiene una colección de propiedades de pares clave-valor, que se
denominan valores con nombre y que son globales para la instancia del servicio. Estos valores con nombre se
pueden usar para administrar valores de cadena constantes en todas las directivas y la configuración de API. Cada
propiedad puede tener también los siguientes atributos:
ATRIBUTO TYPE DESCRIPCIÓN
Display name string Cadena alfanumérica que se usa para

hacer referencia a la propiedad en las
directivas.
Value string El valor de la propiedad. No puede estar

vacío ni contener solo espacios en
blanco.
Secret boolean Determina si el valor es secreto y si se

debe cifrar.
Tags matriz de cadena Etiquetas opcionales que, cuando se

proporcionan, pueden usarse para filtrar
la lista de propiedades.
Los valores de propiedad pueden contener cadenas literales y expresiones de directiva. Por ejemplo, el valor de
ExpressionProperty es una expresión de directiva que devuelve una cadena que contiene la fecha y la hora
actuales. La propiedad ContosoHeaderValue está marcada como secreta, por lo que no se muestra su valor.
NOMBRE VALOR SECRET ETIQUETAS
ContosoHeader TrackingId False Contoso
ContosoHeaderValue •••••••••••••••••••••• True Contoso
ExpressionProperty @(DateTime.Now.ToString()) False
Incorporación y edición de una propiedad

2. Seleccione Valores con nombre.
3. Presione +Agregar.
Los campos Nombre y Valor son necesarios. Si el valor de esta propiedad es un secreto, marque la casilla
Este valor es un secreto. Escriba una o varias etiquetas opcionales que le ayuden a organizar los valores con
nombre y haga clic en Guardar.
Una vez creada la propiedad, es posible editarla haciendo clic en ella. Si cambia el nombre de propiedad, las
directivas que hagan referencia a esa propiedad se actualizarán automáticamente para utilizar el nuevo nombre.
Para obtener información sobre cómo editar una propiedad mediante la API de REST, consulte Edit a property
using the REST API(Edición de una propiedad mediante la API de REST).
Eliminación de una propiedad

Para eliminar una propiedad, haga clic en Delete (Eliminar) junto a la propiedad que se va a eliminar.
IMPORTANT
Si se hace referencia a la propiedad mediante alguna directiva, podrá eliminarla correctamente hasta que quite la propiedad
de todas las directivas que la utilicen.
Para obtener información sobre cómo eliminar una propiedad mediante la API de REST, consulte Delete a
property using the REST API(Eliminación de una propiedad mediante la API de REST).
Búsqueda y filtrado de valores con nombre

En la pestaña Valores con nombre se incluyen las funcionalidades de búsqueda y filtrado que le ayudan a
administrar los valores con nombre. Para filtrar la lista de propiedades por el nombre de la propiedad, escriba un
término de búsqueda en el cuadro de texto Search property (Buscar propiedad) . Para mostrar todos los
valores con nombre, borre el cuadro de texto Search property (Buscar propiedad) y pulse la tecla Entrar.
Para filtrar la lista de propiedades por valores de etiqueta, escriba una o varias etiquetas en el cuadro de texto
Filtrar por etiquetas . Para mostrar todos los valores con nombre, borre el cuadro de texto Filtrar por etiquetas
y pulse la tecla Entrar.
Uso de una propiedad

Para utilizar una propiedad en una directiva, coloque el nombre de la propiedad dentro de un par doble de llaves
(como {{ContosoHeader}} ), de la misma forma que se muestra en el ejemplo siguiente:
<set-header name="{{ContosoHeader}}" exists-action="override">

<value>{{ContosoHeaderValue}}</value>
</set-header>
En este ejemplo, ContosoHeader se utiliza como el nombre de un encabezado en una directiva set-header , y
ContosoHeaderValue se utiliza como valor de ese encabezado. Cuando esta directiva se evalúa durante una solicitud
o responde a la pasarela de API Management, {{ContosoHeader}} y {{ContosoHeaderValue}} se reemplazan por
sus respectivos valores de propiedad.
Los valores con nombre se pueden utilizar como atributo completo o como valores de elemento (tal como se
muestra en el ejemplo anterior), pero también se pueden insertar o combinar con parte de una expresión de texto
literal, como en el ejemplo siguiente: <set-header name = "CustomHeader{{ContosoHeader}}" ...>
Los valores con nombre también pueden contener expresiones de directiva. En el ejemplo siguiente, se utiliza la
propiedad ExpressionProperty .
<set-header name="CustomHeader" exists-action="override">

<value>{{ExpressionProperty}}</value>
</set-header>
Cuando esta directiva se evalúa, se reemplaza {{ExpressionProperty}} por su valor: @(DateTime.Now.ToString()) .

Puesto que el valor es una expresión de directiva, la expresión se evalúa y la directiva continúa con su ejecución.
Puede probarlo en el portal para desarrolladores si llama a una operación que tenga dentro de su ámbito una
directiva con valores con nombre. En el ejemplo siguiente, se llama a una operación con las dos directivas
set-header de ejemplo anteriores con valores con nombre. Tenga en cuenta que la respuesta contiene dos
encabezados personalizados que se han configurado mediante directivas con valores con nombre.
Si busca en el seguimiento de API Inspector una llamada que incluya las dos directivas de ejemplo anteriores con
valores con nombre, verá las dos directivas set-header con los valores de propiedad insertados, así como la
evaluación de la expresión de directiva para la propiedad que la contiene.
Aunque los valores de propiedad pueden contener expresiones de directiva, no pueden contener otros valores con
nombre. Si se utiliza texto que contiene una referencia de propiedad para un valor de propiedad, como
Property value text {{MyProperty}} , esa referencia de propiedad no se reemplazará y se incluirá como parte del
valor de la propiedad.
Pasos siguientes
Obtenga más información sobre cómo trabajar con directivas
Referencia de directiva
Directivas de restricción de acceso de API
Management
En este tema se proporciona una referencia para las siguientes directivas de API Management. Para obtener más
información sobre cómo agregar y configurar directivas, consulte Directivas en Administración de API.

Activar encabezado HTTP : aplica la existencia o el valor de un encabezado HTTP.
Limitar la frecuencia de llamadas por suscripción : evita los picos de uso de la API limitando la frecuencia de
llamadas, por suscripción.
Limitar la frecuencia de llamadas por clave : evita los picos de uso de la API limitando la frecuencia de llamadas,
por clave.
Restringir IP de autor de llamada : filtra (permite/deniega) las llamadas de direcciones IP específicas o de
intervalos de direcciones.
Establecer cuota de uso por suscripción : le permite aplicar un volumen de llamadas renovables o permanentes
o una cuota de ancho de banda por suscripción.
Establecer cuota de uso por clave : le permite aplicar un volumen de llamadas renovables o permanentes o una
cuota de ancho de banda por clave.
Validar JWT : aplica la existencia y la validez de un JWT extraído de un encabezado HTTP especificado o un
parámetro de consulta especificado.
Activar encabezado HTTP

Usa la directiva check-header para exigir que una solicitud tenga un encabezado HTTP especificado. Si lo desea,
puede comprobar si el encabezado tiene un valor específico o un intervalo de valores permitidos. Si el resultado de
la comprobación es negativo, la directiva finaliza el procesamiento de la solicitud y devuelve el mensaje de error y
el código de estado HTTP que especifica.
Instrucción de la directiva
<check-header name="header name" failed-check-httpcode="code" failed-check-error-message="message" ignore-

case="true">
<value>Value1</value>
<value>Value2</value>
</check-header>
Ejemplo
<check-header name="Authorization" failed-check-httpcode="401" failed-check-error-message="Not authorized"

ignore-case="false">
<value>f6dc69a089844cf6b2019bae6d36fac8</value>
</check-header>
Elementos
NOMBRE DESCRIPCIÓN OBLIGATORIO
check-header Elemento raíz. Sí
value Valor del encabezado HTTP permitido. Sin

Cuando se especifican varios elementos
de valor, el resultado de la
comprobación se considera positivo en
caso de coincidencia con cualquiera de
los valores.
Atributos
NOMBRE DESCRIPCIÓN OBLIGATORIO VALOR PREDETERMINADO
failed-check-error-message Mensaje de error que se Sí N/D

devuelve en el cuerpo de la
respuesta HTTP si el
encabezado no existe o tiene
un valor no válido. Los
caracteres especiales de este
mensaje deben incluir los
caracteres de escape
correctos.
failed-check-httpcode Código de estado HTTP que Sí N/D

se devuelve si el encabezado
no existe o tiene un valor no
válido.
header-name Nombre del encabezado Sí N/D

HTTP que hay que
comprobar.
ignore-case Puede establecerse en True o Sí N/D

False. Si se establece en True,
se omite la presencia de
mayúsculas/minúsculas
cuando el valor del
encabezado se compara con
el conjunto de valores
aceptables.
Uso
Esta directiva puede usarse en las siguientes secciones y ámbitos de directiva.
Secciones de la directiva: entrante y saliente
Ámbitos de la directiva: global, producto, API, operación
Limitar la tasa de llamadas por suscripción

La directiva rate-limit evita los picos de uso de la API según suscripción limitando la tasa de llamadas a un
número especificado por un período de tiempo establecido. Cuando se desencadena esta directiva, el autor de la
llamada recibe un código de estado de respuesta 429 Too Many Requests .
IMPORTANT
Esta directiva se puede usar una sola vez por documento de directiva.
Las expresiones de directiva no se pueden usar en ninguno de los atributos de esta directiva.
Cau t i on
Debido a la naturaleza distribuida de la arquitectura de limitación, el límite de velocidad nunca es completamente

preciso. La diferencia entre la cantidad configurada y la cantidad real de solicitudes permitidas varía según el
volumen y la velocidad de la solicitud, la latencia del servidor y otros factores.
<rate-limit calls="number" renewal-period="seconds">

<api name="API name" id="API id" calls="number" renewal-period="seconds" />
<operation name="operation name" id="operation id" calls="number" renewal-period="seconds" />
</api>
</rate-limit>
Ejemplo
<policies>
<inbound>
<base />
<rate-limit calls="20" renewal-period="90" />
</inbound>
<outbound>
<base />
</outbound>
</policies>
Elementos
set-limit Elemento raíz. Sí
api Agregue uno o varios de estos Sin

elementos para imponer un límite de
tasa de llamadas a las API del producto.
Los límites de tasa de llamadas a la API
y al producto se aplican de forma
independiente. Se puede hacer
referencia a la API a través de name o
id . Si se proporcionan ambos
atributos, id se usará y name se
omitirá.
operación Agregue uno o varios de estos Sin

elementos para imponer un límite de
tasa de llamadas a las operaciones de
una API. Los límites de tasa de llamadas
se aplican de forma independiente a la
API, a la operación y al producto. Se
puede hacer referencia a la operación a
través de name o id . Si se
proporcionan ambos atributos, id se
usará y name se omitirá.
Atributos
Nombre Nombre de la API a la que se Sí N/D

va a aplicar un límite de tasa.
calls Número total máximo de Sí N/D

llamadas permitidas durante
el intervalo de tiempo
especificado en
renewal-period .
renewal-period Período de tiempo en Sí N/D

segundos tras el cual se
restablece la cuota.
Uso
Secciones de la directiva: inbound (entrada)
Ámbitos de la directiva: producto
Limitar la tasa de llamadas por clave

IMPORTANT
Esta característica no está disponible en el nivel Consumo de API Management.
La directiva rate-limit-by-key evita los picos de uso de la API según clave limitando la tasa de llamadas a un
número especificado por un período de tiempo establecido. La clave puede tener un valor de cadena arbitrario y
normalmente se proporciona mediante una expresión de directiva. Puede agregarse una condición de incremento
opcional para especificar qué solicitudes se deben contar para este límite. Cuando se desencadena esta directiva, el
autor de la llamada recibe un código de estado de respuesta 429 Too Many Requests .
Para obtener más información y ver ejemplos de esta directiva, consulte Limitación avanzada de solicitudes con
Cau t i on
Debido a la naturaleza distribuida de la arquitectura de limitación, el límite de velocidad nunca es completamente

preciso. La diferencia entre la cantidad configurada y la cantidad real de solicitudes permitidas varía según el
volumen y la velocidad de la solicitud, la latencia del servidor y otros factores.
<rate-limit-by-key calls="number"
renewal-period="seconds"
increment-condition="condition"
counter-key="key value" />
Ejemplo
En el ejemplo siguiente, la clave del límite de velocidad se establece según la dirección IP del autor de la llamada.
<policies>
<inbound>
<base />
renewal-period="60"
increment-condition="@(context.Response.StatusCode == 200)"
counter-key="@(context.Request.IpAddress)"/>
</inbound>
<outbound>
<base />
</outbound>
</policies>
Elementos
set-limit Elemento raíz. Sí
Atributos
calls Número total máximo de Sí N/D

llamadas permitidas durante
especificado en
renewal-period .
counter-key Clave que se usa para la Sí N/D

directiva de límite de tasa.
increment-condition Expresión booleana que Sin N/D

especifica si la solicitud se
debe contar para la cuota (
true ).

Uso
Secciones de la directiva: entrante
Restringir IP de autor de llamada

La directiva ip-filter filtra (permite/deniega) llamadas de direcciones IP específicas o de intervalos de
direcciones.
<ip-filter action="allow | forbid">
<address>address</address>
<address-range from="address" to="address" />
</ip-filter>
Ejemplo
En el siguiente ejemplo, la directiva solo permite solicitudes provenientes de la única dirección IP o rango de
direcciones IP especificadas.
<ip-filter action="allow">
<address>13.66.201.169</address>
<address-range from="13.66.140.128" to="13.66.140.143" />
</ip-filter>
Elementos
ip-filter Elemento raíz. Sí
address Especifica la dirección IP única por la Es necesario al menos un elemento

que filtrar. address o address-range .
address-range from="address" Especifica un intervalo de direcciones IP Es necesario al menos un elemento

to="address" por el que filtrar. address o address-range .
Atributos
address-range Un intervalo de direcciones Obligatorio cuando se utiliza N/D

from="address" IP a las que permitir o el elemento address-range
to="address" denegar el acceso. .
ip-filter action="allow | Especifica si se deben Sí N/D

forbid" permitir o no las llamadas
para los intervalos y
direcciones IP especificados.
Uso
Establecer cuota de uso por suscripción

La directiva quota aplica un volumen de llamadas o una cuota de ancho de banda renovables o permanentes por
suscripción.
IMPORTANT
Esta directiva se puede usar una sola vez por documento de directiva.
Las expresiones de directiva no se pueden usar en ninguno de los atributos de esta directiva.
<quota calls="number" bandwidth="kilobytes" renewal-period="seconds">

<api name="API name" id="API id" calls="number" renewal-period="seconds" />
<operation name="operation name" id="operation id" calls="number" renewal-period="seconds" />
</api>
</quota>
Ejemplo
<policies>
<inbound>
<base />
<quota calls="10000" bandwidth="40000" renewal-period="3600" />
</inbound>
<outbound>
<base />
</outbound>
</policies>
Elementos
quota Elemento raíz. Sí
api Agregue uno o varios de estos Sin

elementos para imponer una cuota de
llamadas a las API del producto. Las
cuotas de llamada de API y de producto
se aplican de forma independiente. Se
puede hacer referencia a la API a través
de name o id . Si se proporcionan
ambos atributos, id se usará y name
se omitirá.
operación Agregue uno o varios de estos Sin

elementos para imponer una cuota de
llamadas a las operaciones de una API.
Las cuotas de llamadas de API,
operación y producto se aplican de
forma independiente. Se puede hacer
referencia a la operación a través de
name o id . Si se proporcionan
ambos atributos, id se usará y name
se omitirá.
Atributos
Nombre Nombre de la API u Sí N/D

operación a la que se aplica
la cuota.
bandwidth Número total máximo de Debe especificarse calls , N/D

kilobytes permitidos durante bandwidth o ambos.
especificado en
renewal-period .
calls Número total máximo de Debe especificarse calls , N/D

llamadas permitidas durante bandwidth o ambos.
especificado en
renewal-period .

Uso
Ámbitos de la directiva: producto
Establecer cuota de uso por clave

IMPORTANT
Esta característica no está disponible en el nivel Consumo de API Management.
La directiva quota-by-key aplica un volumen de llamadas o una cuota de ancho de banda por clave renovables o
permanentes. La clave puede tener un valor de cadena arbitrario y normalmente se proporciona mediante una
expresión de directiva. Puede agregarse una condición de incremento opcional para especificar qué solicitudes se
cuentan para esta cuota. Si varias directivas incrementan el mismo valor de clave, se incrementa solo una vez por
solicitud. Cuando se alcanza el límite de llamadas, el autor de la llamada recibe un código de estado de respuesta
403 Forbidden .
Para obtener más información y ver ejemplos de esta directiva, consulte Limitación avanzada de solicitudes con
<quota-by-key calls="number"
bandwidth="kilobytes"
renewal-period="seconds"
increment-condition="condition"
counter-key="key value" />
Ejemplo
En el ejemplo siguiente, la clave de la cuota se establece según la dirección IP del autor de la llamada.
<policies>
<inbound>
<base />
<quota-by-key calls="10000" bandwidth="40000" renewal-period="3600"
increment-condition="@(context.Response.StatusCode >= 200 && context.Response.StatusCode
< 400)"
</inbound>
<outbound>
<base />
</outbound>
</policies>
Elementos
quota Elemento raíz. Sí
Atributos
bandwidth Número total máximo de Debe especificarse calls , N/D

kilobytes permitidos durante bandwidth o ambos.
especificado en
renewal-period .
calls Número total máximo de Debe especificarse calls , N/D

llamadas permitidas durante bandwidth o ambos.
especificado en
renewal-period .
counter-key Clave que se usa para la Sí N/D

directiva de cuota.
increment-condition Expresión booleana que Sin N/D

especifica si la solicitud se
debe contar para la cuota (
true ).

Uso
Validación de JWT
La directiva validate-jwt aplica la existencia y la validez de un JWT extraído de un encabezado HTTP o un
parámetro de consulta especificados.
IMPORTANT
La directiva validate-jwt requiere que la notificación registrada exp se incluya en el token de JWT, a menos que se
especifique el atributo require-expiration-time y se establezca en false . La directiva validate-jwt es compatible con
los algoritmos de firma HS256 y RS256. En el caso de HS256, la clave debe proporcionarse en línea dentro de la directiva con
el formato de codificación Base64. En el caso de RS256, la clave debe proporcionarse a través de un punto de conexión de
configuración OpenID. La directiva validate-jwt admite tokens cifrados con claves simétricas que utilicen los siguientes
algoritmos de cifrado: A128CBC-HS256, A192CBC-HS384 y A256CBC-HS512.
<validate-jwt
header-name="name of http header containing the token (use query-parameter-name attribute if the token is
passed in the URL)"
failed-validation-httpcode="http status code to return on failure"
failed-validation-error-message="error message to return on failure"
token-value="expression returning JWT token as a string"
require-expiration-time="true|false"
require-scheme="scheme"
require-signed-tokens="true|false"
clock-skew="allowed clock skew in seconds"
output-token-variable-name="name of a variable to receive a JWT object representing successfully validated
token">
<issuer-signing-keys>
<key>base64 encoded signing key</key>

</issuer-signing-keys>
<decryption-keys>
<key>base64 encoded signing key</key>

</decryption-keys>
<audiences>
<audience>audience string</audience>

</audiences>
<issuers>
<issuer>issuer string</issuer>

</issuers>
<required-claims>
<claim name="name of the claim as it appears in the token" match="all|any" separator="separator character
in a multi-valued claim">
<value>claim value as it is expected to appear in the token</value>

</claim>

</required-claims>
<openid-config url="full URL of the configuration endpoint, e.g. https://login.constoso.com/openid-
configuration" />
<zumo-master-key id="key identifier">key value</zumo-master-key>
</validate-jwt>
Ejemplos
Validación de tokens simple
<validate-jwt header-name="Authorization" require-scheme="Bearer">
<key>{{jwt-signing-key}}</key> 
<audiences>
<audience>@(context.Request.OriginalUrl.Host)</audience> 
</audiences>
<issuers>
<issuer>http://contoso.com/</issuer>
</issuers>
</validate-jwt>
Validación de tokens de Azure Active Directory

<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-
configuration" />
<audiences>
<audience>25eef6e4-c905-4a07-8eb4-0d08d5df8b3f</audience>
</audiences>
<required-claims>
<claim name="id" match="all">
<value>insert claim here</value>
</claim>
</required-claims>
</validate-jwt>
Validación de tokens de Azure Active Directory B2C

<openid-config url="https://login.microsoftonline.com/tfp/contoso.onmicrosoft.com/b2c_1_signin/v2.0/.well-
known/openid-configuration" />
<audiences>
<audience>d313c4e4-de5f-4197-9470-e509a2f0b806</audience>
</audiences>
<required-claims>
<claim name="id" match="all">
<value>insert claim here</value>
</claim>
</required-claims>
</validate-jwt>
Autorización de acceso a las operaciones según las notificaciones de tokens

En este ejemplo se muestra cómo usar la directiva de validación de JWT para autorizar el acceso a operaciones
según el valor de las notificaciones de token.
<validate-jwt header-name="Authorization" require-scheme="Bearer" output-token-variable-name="jwt">
<key>{{jwt-signing-key}}</key> 
<audiences>
<audience>@(context.Request.OriginalUrl.Host)</audience>
</audiences>
<issuers>
<issuer>contoso.com</issuer>
</issuers>
<required-claims>
<claim name="group" match="any">
<value>finance</value>
<value>logistics</value>
</claim>
</required-claims>
</validate-jwt>
<choose>
<when condition="@(context.Request.Method == "POST" && !
((Jwt)context.Variables["jwt"]).Claims["group"].Contains("finance"))">
<return-response>
<set-status code="403" reason="Forbidden" />
</return-response>
</when>
</choose>
Validación de tokens de Azure Mobile Services
<validate-jwt header-name="x-zumo-auth" failed-validation-httpcode="401" failed-validation-error-

message="Unauthorized. Supplied access token is invalid.">
<issuers>
<issuer>urn:microsoft:windows-azure:zumo</issuer>
</issuers>
<audiences>
<audience>Facebook</audience>
</audiences>
<zumo-master-key id="0">insert key here</zumo-master-key>
</validate-jwt>
Elementos
ELEMENTO DESCRIPCIÓN OBLIGATORIO
validate-jwt Elemento raíz. Sí
audiences Contiene una lista de notificaciones de Sin

audiencia aceptables que pueden estar
presentes en el token. Si existen varios
valores de audiencia, se prueban los
valores uno a uno hasta que se agoten
todos (en cuyo caso no se superará la
validación) o hasta que se obtenga un
resultado positivo con alguno. Debe
especificarse al menos una audiencia.
issuer-signing-keys Lista de las claves de seguridad con Sin

codificación Base64 que se utilizan para
validar los tokens firmados. Si existen
varias claves de seguridad, se prueban
las claves una a una hasta que se
agoten todas (en cuyo caso no se
superará la validación) o hasta que una
sea correcta (lo que es útil para la
sustitución de tokens). Los elementos
de clave tienen un atributo id
opcional que se utiliza para compararlo
con la notificación kid .
decryption-keys Una lista de claves con codificación Sin

Base64 que se usan para descifrar los
tokens. Si existen varias claves de
seguridad, se prueba cada clave hasta
que se agoten todas (en cuyo caso no
se superará la validación) o hasta que
una sea correcta. Los elementos de
clave tienen un atributo id opcional
que se utiliza para compararlo con la
notificación kid .
issuers Lista de entidades de seguridad Sin

aceptables que emitieron el token. Si
existen varios valores de emisor, se
prueban los valores uno a uno hasta
que se agoten todos (en cuyo caso no
se superará la validación) o hasta que se
obtenga un resultado positivo con
alguno.
openid-config Elemento que se usa para especificar un Sin

punto de conexión de configuración
OpenID compatible desde el que se
puedan obtener las claves y el emisor
de la firma.
required-claims Contiene una lista de las notificaciones Sin

que se espera que estén presentes en el
token para que se considere válido.
Cuando el atributo match está
establecido en all , todos los valores
de notificación de la directiva deben
estar presentes en el token para que la
validación se efectúe correctamente.
Cuando el atributo match está
establecido en any , debe haber al
menos una notificación en el token para
que la validación se efectúe
correctamente.
zumo-master-key Clave maestra para los tokens que Sin

emite Azure Mobile Services.
Atributos
clock-skew Intervalo de tiempo. Utilice Sin 0 segundos

esta opción para especificar
la diferencia máxima de
tiempo esperado entre los
relojes del sistema del
emisor del token y la
instancia de API
Management.
failed-validation-error- Mensaje de error que se Sin El mensaje de error

message devuelve en el cuerpo de predeterminado depende del
respuesta HTTP si el problema de validación, por
elemento JWT no pasa la ejemplo, la notificación de la
validación. Los caracteres ausencia del elemento JWT.
especiales de este mensaje
deben incluir los caracteres
de escape correctos.
failed-validation-httpcode Código de estado HTTP que Sin 401

se devuelve si el elemento
JWT no pasa la validación.
header-name El nombre del encabezado Se debe especificar uno de N/D

HTTP que contiene el token. header-name ,
query-parameter-name o
token-value .
nombre del parámetro de Nombre del parámetro de Se debe especificar uno de N/D
consulta consulta que contiene el header-name ,
token. query-parameter-name o
token-value .
token-value Expresión que devuelve una Se debe especificar uno de N/D

cadena que contiene el header-name ,
token JWT. query-parameter-name o
token-value .
id El atributo id del elemento Sin N/D

key le permite especificar
la cadena que se comparará
con la notificación kid del
token (si existe) para
averiguar qué clave debe
usarse para validar la firma.
match El atributo match del Sin todas

elemento claim especifica
si todos los valores de
notificación de la directiva
deben estar presentes en el
token para que la validación
se efectúe correctamente.
Los valores posibles son:
- all : todos los valores de

notificación de la directiva
deben estar presentes en el
token para que la validación
se efectúe correctamente.
- any : al menos un valor

de notificación debe estar
presente en el token para
que la validación se efectúe
correctamente.
require-expiration-time Booleano. Especifica si es Sin true

necesaria una notificación de
expiración en el token.
require-scheme El nombre del token de Sin N/D

esquema; por ejemplo,
"Bearer". Cuando se
establece este atributo, la
directiva se asegurará de
que ese esquema
especificado esté presente
en el valor del encabezado
de la autorización.
require-signed-tokens Booleano. Especifica si un Sin true

token debe estar firmado.
separator String. Especifica el Sin N/D

separador (por ejemplo: ",")
que se va a usar para extraer
un conjunto de valores de
una notificación con varios
valores.
url Dirección URL de punto de Sí N/D

conexión de configuración
de OpenID desde donde se
pueden obtener los
metadatos de configuración
de OpenID. La respuesta
debe ser acorde a las
especificaciones definidas en
la dirección URL:
https://openid.net/specs/openid-
connect-discovery-
1_0.html#ProviderMetadata
. En Azure Active Directory,
utilice la dirección URL
https://login.microsoftonline.com/{tenant-
name}/.well-known/openid-configuration
y sustituya tenant-name por
el nombre del inquilino de
directorio, por ejemplo,
contoso.onmicrosoft.com .
output-token-variable-name String. Nombre de la variable Sin N/D

de contexto que recibirá el
valor del token como un
objeto de tipo Jwt tras la
validación correcta del token.
Uso
Pasos siguientes
Directivas avanzadas de API Management
Flujo de control: aplica condicionalmente instrucciones de directiva basadas en los resultados de la evaluación
de expresiones booleanas.
Reenviar solicitud : reenvía la solicitud al servicio back-end.
Limitar la simultaneidad: evita que las directivas delimitadas las ejecute simultáneamente un número de
solicitudes mayor que el especificado.
Registro en centro de eventos: envía mensajes en el formato especificado a un centro de eventos definido por
una entidad de registrador.
Mock response (Simular respuesta): anula la ejecución de la canalización y devuelve la respuesta ficticia
Reintentar : reintenta ejecutar las instrucciones de directiva adjuntas, si y hasta que se cumple la condición. La
ejecución se repite en los intervalos de tiempo especificados y hasta el número de reintentos indicado.
Devolver respuesta : anula la ejecución de la canalización y devuelve la respuesta especificada directamente al
llamador.
Enviar solicitud unidireccional : envía una solicitud a la dirección URL especificada sin esperar una respuesta.
Enviar solicitud : envía una solicitud a la dirección URL especificada.
Establecer el proxy HTTP: permite enrutar las solicitudes reenviadas a través de un proxy HTTP.
Establecer método de solicitud : le permite cambiar el método HTTP de una solicitud.
Establecimiento de código de estado: cambia el código de estado HTTP al valor especificado.
Establecimiento de variable: conserva un valor en una variable context con nombre para su posterior acceso.
Seguimiento: agrega una cadena a la salida de API Inspector.
Espera: espera a que se completen las directivas adjuntas de envío de solicitud, obtención del valor de caché o
flujo de control antes de continuar.
Flujo de control
La directiva choose aplica las declaraciones de directiva adjuntas en función del resultado de la evaluación de las
expresiones booleanas, de forma similar a una estructura if-then-else o de conmutador en un lenguaje de
programación.
Declaración de la directiva
<choose>
<when condition="Boolean expression | Boolean constant">
<!— one or more policy statements to be applied if the above condition is true -->
</when>
<when condition="Boolean expression | Boolean constant">
<!— one or more policy statements to be applied if the above condition is true -->
</when>
<otherwise>
<!— one or more policy statements to be applied if none of the above conditions are true -->
</otherwise>
</choose>
La directiva de flujo de control debe contener al menos un elemento <when/> . El elemento <otherwise/> es
opcional. Las condiciones de los elementos <when/> se evalúan en orden de aparición dentro de la directiva. Se
aplicarán las declaraciones de directivas adjuntas en el primer elemento <when/> cuyo atributo de condición sea
igual a true . Las directivas incluidas dentro del elemento <otherwise/> , si está presente, se aplicarán si todos los
atributos de condición del elemento <when/> son false .
Ejemplos
Ejemplo
En el ejemplo siguiente se muestra una directiva set-variable y dos directivas de flujo de control.
La directiva de establecimiento de variable se encuentra en la sección de entrada y crea una variable de contexto
booleana isMobile que se establece en true si el encabezado de la solicitud User-Agent contiene el texto iPad o
iPhone .
La primera directiva de flujo de control se encuentra también en la sección de entrada y aplica condicionalmente
una de las dos directivas de establecimiento del parámetro de cadena de consulta dependiendo del valor de la
variable de contexto isMobile .
La segunda directiva de flujo de control se encuentra en la sección de salida y aplica la directiva de onversión de
XML a JSON solo cuando isMobile está establecida en true .
<policies>
<inbound>
<set-variable name="isMobile" value="@(context.Request.Headers["User-Agent"].Contains("iPad") ||
context.Request.Headers["User-Agent"].Contains("iPhone"))" />
<base />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<bool>("isMobile"))">
<set-query-parameter name="mobile" exists-action="override">
<value>true</value>
</set-query-parameter>
</when>
<otherwise>
<set-query-parameter name="mobile" exists-action="override">
<value>false</value>
</otherwise>
</choose>
</inbound>
<outbound>
<base />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<bool>("isMobile"))">
<xml-to-json kind="direct" apply="always" consider-accept-header="false"/>
</when>
</choose>
</outbound>
</policies>
Ejemplo
En este ejemplo se muestra cómo filtrar contenido quitando elementos de datos de la respuesta recibida del
servicio back-end al usar el producto Starter . Para ver una demostración de la configuración y el uso de esta
directiva, consulte el Episodio 177 de Cloud Cover: More API Management Features with Vlad Vinogradsky (Más
características de API Management con Vlad Vinogradsky) y avance hasta el minuto 34:30. Empiece en el minuto
31:50 para ver una introducción a la API de previsión de Dark Sky empleada en esta demostración.

<choose>
<when condition="@(context.Response.StatusCode == 200 && context.Product.Name.Equals("Starter"))">
<set-body>@{
var response = context.Response.Body.As<JObject>();
foreach (var key in new [] {"minutely", "hourly", "daily", "flags"}) {
response.Property (key).Remove ();
}
return response.ToString();
}
</set-body>
</when>
</choose>
Elementos
choose Elemento raíz. Sí
when La condición que se va a usar para las Sí

partes if o ifelse de la directiva
choose . Si la directiva choose tiene
varias secciones when , se evalúan de
forma secuencial. Una vez que la
instancia de condition de un
elemento when se evalúa en true , ya
no se evalúan más condiciones when .
otherwise Contiene el fragmento de código de Sin

directiva que se utilizará si ninguna de
las condiciones when se evalúan como
true .
Atributos
ATRIBUTO DESCRIPCIÓN OBLIGATORIO
condition="Constante booleana | La expresión o constante booleana que Sí

Constante booleana" se evalúa cuando se evalúa la
declaración de la directiva when que la
contiene.
Uso
Secciones de la directiva: inbound, outbound, backend, on-error
Ámbitos de la directiva: todos los ámbitos
Reenvío de solicitud
La directiva forward-request reenvía la solicitud entrante al servicio back-end especificado en el contexto de la
solicitud. La dirección URL del servicio back-end se especifica en la configuración de la API y se puede cambiar
mediante la directiva de establecimiento del servicio back-end.
NOTE
Si quita los resultados de esta directiva en la solicitud no se reenviarán al servicio back-end, y las directivas de la sección de
salida se evaluarán inmediatamente tras la finalización correcta de las directivas en la sección de entrada.
<forward-request timeout="time in seconds" follow-redirects="true | false" buffer-request-body="true | false"

/>
Ejemplos
Ejemplo
La siguiente directiva de nivel de API reenvía todas las solicitudes de API al servicio back-end con un intervalo de
tiempo de expiración de 60 segundos.


<policies>
<inbound>
<base/>
</inbound>
<backend>
<forward-request timeout="60"/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Ejemplo
Esta directiva de nivel de operación utiliza el elemento base para heredar la directiva de back-end del ámbito de
nivel de API principal.


<policies>
<inbound>
<base/>
</inbound>
<backend>
<base/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Ejemplo
Esta directiva de nivel de operación reenvía explícitamente todas las solicitudes al servicio back-end con un tiempo
de espera de 120 y no hereda la directiva de back-end de nivel de API principal.
<policies>
<inbound>
<base/>
</inbound>
<backend>

</backend>
<outbound>
<base/>
</outbound>
</policies>
Ejemplo
Esta directiva de nivel de operación no reenvía solicitudes al servicio back-end.

<policies>
<inbound>
<base/>
</inbound>
<backend>

</backend>
<outbound>
<base/>
</outbound>
</policies>
Elementos
forward-request Elemento raíz. Sí
Atributos
ATRIBUTO DESCRIPCIÓN OBLIGATORIO VALOR PREDETERMINADO
timeout="entero" La cantidad de tiempo en Sin None

segundos de espera a que el
servicio back-en devuelva
los encabezados de
respuesta HTTP antes de
que se genere un error de
tiempo de expiración. El
valor mínimo es 0segundos.
Puede que los valores
mayores de 240 segundos
no se respeten dado que la
infraestructura de red
subyacente puede eliminar
las conexiones inactivas
después de este tiempo.
follow-redirects="true | false" Especifica si la puerta de Sin false

enlace sigue los
redireccionamientos desde el
servicio back-end o si estos
se devuelven al autor de la
llamada.
buffer-request-body="true | Cuando se establece en Sin false

false" "true", la solicitud se
almacena en búfer y se
volverá a usar al reintentar.
Uso
Secciones de la directiva: back-end
Limitar la simultaneidad
La directiva limit-concurrency evita que las directivas delimitadas ejecuten en un momento dado un número de
solicitudes mayor que el especificado. Al superar ese número, las nuevas solicitudes producirán un error
inmediatamente con el código de estado de 429 Demasiadas solicitudes.
<limit-concurrency key="expression" max-count="number">

<!— nested policy statements -->
</limit-concurrency>
Ejemplos
Ejemplo
En el ejemplo siguiente se muestra cómo limitar el número de solicitudes que se reenvían a un back-end en
función del valor de una variable de contexto.
<policies>
<inbound>…</inbound>
<backend>
<limit-concurrency key="@((string)context.Variables["connectionId"])" max-count="3">
<limit-concurrency/>
</backend>
<outbound>…</outbound>
</policies>
Elementos
límite de simultaneidad Elemento raíz. Sí
Atributos
key Una cadena. Expresión que Sí N/D

se permite. Especifica el
ámbito de la simultaneidad.
Puede compartirse entre
varias directivas.
número máximo Un entero. Especifica el Sí N/D

número máximo de
solicitudes que se pueden
especificar en la directiva.
Uso
Registro en centro de eventos

La directiva log-to-eventhub envía mensajes en el formato especificado a un centro de eventos definido por una
entidad del registrador. Como su nombre indica, la directiva se usa para guardar información de contexto de
respuesta o solicitud que se ha seleccionado para su análisis en línea o sin conexión.
NOTE
Para obtener una guía paso a paso acerca de cómo configurar un centro de eventos y eventos de registro, consulte Cómo
registrar eventos de API Management con Azure Event Hubs.
<log-to-eventhub logger-id="id of the logger entity" partition-id="index of the partition where messages are
sent" partition-key="value used for partition assignment">
Expression returning a string to be logged
</log-to-eventhub>
Ejemplo
Puede utilizar cualquier cadena como valor que se registrará en Event Hubs. En este ejemplo, la fecha y hora, el
nombre del servicio de implementación, el identificador de solicitud, la dirección IP y el nombre de la operación de
todas las llamadas entrantes se registran en el registrador del centro de eventos con el identificador
contoso-logger .
<policies>
<inbound>
<log-to-eventhub logger-id ='contoso-logger'>
@( string.Join(",", DateTime.UtcNow, context.Deployment.ServiceName, context.RequestId,
context.Request.IpAddress, context.Operation.Name) )
</log-to-eventhub>
</inbound>
<outbound>
</outbound>
</policies>
Elementos
log-to-eventhub Elemento raíz. El valor de este elemento Sí

es la cadena que sirve para iniciar sesión
en su centro de eventos.
Atributos
logger-id El identificador del registrador Sí

registrado con el servicio API
Management.
partition-id Especifica el índice de la partición desde Opcional. Este atributo no se puede

donde se envían los mensajes. utilizar cuando se usa partition-key .
partition-key Especifica el valor utilizado para la Opcional. Este atributo no se puede

asignación de partición cuando se utilizar cuando se usa partition-id .
envían mensajes.
Uso
Similar respuesta
mock-response , como el nombre indica, se utiliza para simular las API y las operaciones. Se anula la ejecución de la
canalización normal y devuelve una respuesta simulada al llamador. La directiva siempre trata de devolver las
respuestas de mayor fidelidad. Prefiere ejemplos de contenido de respuesta, siempre que estén disponibles.
Genera las respuestas de ejemplo a partir de esquemas, cuando se proporcionan esquemas y no ejemplos. Si no se
encuentran ni ejemplos ni esquemas, se devuelven las respuestas sin contenido.
<mock-response status-code="code" content-type="media type"/>
Ejemplos

<mock-response/>

<mock-response status-code='200' content-type='application/json'/>
Elementos
mock-response Elemento raíz. Sí
Atributos
status-code Especifica el código de Sin 200

estado de la respuesta y se
utiliza para seleccionar el
ejemplo o el esquema
correspondientes.
content-type Especifica el valor de Sin None

encabezado de la respuesta
Content-Type y se utiliza
para seleccionar el ejemplo o
el esquema
correspondientes.
Uso
Secciones de la directiva: entrante, saliente y en caso de error
Reintento
La directiva retry ejecuta sus directivas secundarias una vez y después vuelve a tratar de ejecutarla hasta que el
elemento condition del reintento pasa a ser false o se agota el número correspondiente al elemento count del
reintento.
<retry
condition="boolean expression or literal"
count="number of retry attempts"
interval="retry interval in seconds"
max-interval="maximum retry interval in seconds"
delta="retry interval delta in seconds"
first-fast-retry="boolean expression or literal">

</retry>
Ejemplo
En el siguiente ejemplo de solicitud, el reenvío de solicitud se vuelve a intentar hasta diez veces usando un
algoritmo exponencial de reintentos. Como first-fast-retry se ha establecido en false, todos los reintentos
quedan sujetos al algoritmo exponencial de reintentos.
<retry
condition="@(context.Response.StatusCode == 500)"
count="10"
interval="10"
max-interval="100"
delta="10"
first-fast-retry="false">
<forward-request buffer-request-body="true" />
</retry>
Elementos
retry Elemento raíz. Puede contener cualquier Sí

otra directiva como elemento
secundario.
Atributos
condition Expresión o literal booleanos Sí N/D

que especifican si los
reintentos se deben detener
( false ) o continuar ( true
).
count Número positivo que Sí N/D

especifica el número máximo
de reintentos que deben
realizarse.
interval Número positivo en Sí N/D

segundos que especifica el
intervalo de espera entre los
reintentos.
max-interval Número positivo en Sin N/D

intervalo máximo de espera
entre los reintentos. Se
utiliza para implementar un
algoritmo exponencial de
reintentos.
delta Número positivo en Sin N/D

incremento del intervalo de
espera. Se usa para
implementar los algoritmos
lineales y exponenciales de
reintentos.
first-fast-retry Si se establece en true , el Sin false

primer reintento se lleva a
cabo inmediatamente.
NOTE
Cuando solamente se especifica interval , los reintentos se llevan a cabo a intervalos fijos. Cuando solamente se
especifican interval y delta , se utiliza el algoritmo de reintentos de intervalo lineal, en el que el tiempo de espera entre
reintentos se calcula según la siguiente fórmula: interval + (count - 1)*delta . Cuando se especifican interval ,
max-interval y delta , se aplica un algoritmo de reintentos de intervalo exponencial, en el que el tiempo de espera
entre los reintentos aumenta exponencialmente desde el valor de interval al valor de max-interval según la siguiente
fórmula: min(interval + (2^count - 1) * random(delta * 0.8, delta * 1.2), max-interval) .
Uso
Esta directiva puede usarse en las siguientes secciones y ámbitos de directiva. Tenga en cuenta que esta directiva
heredará las restricciones de uso de directivas secundarias.
Devolución de respuesta
La directiva return-response anula la ejecución de la canalización y devuelve una respuesta personalizada o
predeterminada al autor de la llamada. La respuesta predeterminada es 200 OK sin cuerpo. La respuesta
personalizada se puede especificar mediante declaraciones de directiva o variable de contexto. Cuando se
especifican ambas, las declaraciones de la directiva modifican la respuesta que se encuentra en la variable de
contexto antes de devolverla al autor de la llamada.
<return-response response-variable-name="existing context variable">

<set-header/>
<set-body/>
<set-status/>
</return-response>
Ejemplo
<return-response>
<set-status code="401" reason="Unauthorized"/>
</set-header>
</return-response>
Elementos
return-response Elemento raíz. Sí
set-header Una declaración de directiva set-header. Sin
set-body Una declaración de directiva set-body. Sin
set-status Una declaración de directiva set-status. Sin

Atributos
response-variable-name Nombre de la variable de contexto a la Opcional.

que se hace referencia, por ejemplo,
desde una directiva send-request de
canal de subida y que contiene un
objeto Response .
Uso
Envío de solicitud unidireccional

La directiva send-one-way-request envía la solicitud proporcionada a la dirección URL especificada sin esperar una
respuesta.
<send-one-way-request mode="new | copy">

<url>...</url>
<method>...</method>
<header name="" exists-action="override | skip | append | delete">...</header>
<body>...</body>
<authentication-certificate thumbprint="thumbprint" />
Ejemplo
Esto es un ejemplo de cómo usar la directiva send-one-way-request para enviar un mensaje a un salón de chat de
Slack cuando el código de respuesta HTTP es mayor o igual que 500. Si desea más información sobre este
ejemplo, consulte Uso de servicios externos del servicio Azure API Management.
<choose>
<set-body>@{
return new JObject(
context.User.Email
))
).ToString();
}</set-body>
</when>
</choose>
Elementos
send-one-way-request Elemento raíz. Sí
url Dirección URL de la solicitud. No si mode=copy; de lo contrario, sí.
method Método HTTP usado en la solicitud. No si mode=copy; de lo contrario, sí.
encabezado Encabezado de la solicitud. Utilice varios Sin

elementos de encabezado si hay varios
encabezados de solicitud.
Cuerpo Cuerpo de la solicitud. Sin
authentication-certificate Certificado usado para la autenticación Sin

de cliente
Atributos
mode="cadena" Determina si se trata de una Sin Nuevo

solicitud nueva o de una
copia de la solicitud actual.
En el modo de salida,
mode=copy no inicializa el
cuerpo de la solicitud.
Nombre Especifica el nombre del Sí N/D

encabezado que se va a
establecer.
exists-action Especifica la acción que se Sin override

debe realizar cuando ya se
ha especificado un
encabezado. Este atributo
debe tener uno de los
siguientes valores:
- override: sustituye el valor

del encabezado existente.
- skip: no sustituye el valor
- append: anexa el valor al
encabezado existente.
- delete: quita el encabezado
de la solicitud.
Cuando se establece en
override , si se inscriben
varias entradas con el mismo
nombre, se establece el
encabezado de acuerdo con
todas ellas (que se
inscribirán varias veces); solo
los valores mostrados se
establecerán en el resultado.
Uso
Envío de solicitud
La directiva send-request envía la solicitud proporcionada a la dirección URL que se ha especificado, aunque no
espera más del valor de tiempo de espera establecido.
<send-request mode="new|copy" response-variable-name="" timeout="60 sec" ignore-error

="false|true">
<set-url>...</set-url>
<set-method>...</set-method>
<set-header name="" exists-action="override|skip|append|delete">...</set-header>
<set-body>...</set-body>
<authentication-certificate thumbprint="thumbprint" />
</send-request>
Ejemplo
En este ejemplo se muestra una forma de comprobar un token de referencia con un servidor de autorización. Si
desea más información sobre este ejemplo, consulte Uso de servicios externos del servicio Azure API
Management.
<inbound>


</set-header>
</set-header>
</send-request>
<choose>

false)">

<return-response>
</set-header>
</return-response>
</when>
</choose>
<base />
</inbound>
Elementos
send-request Elemento raíz. Sí
url Dirección URL de la solicitud. No si mode=copy; de lo contrario, sí.
method Método HTTP usado en la solicitud. No si mode=copy; de lo contrario, sí.
encabezado Encabezado de la solicitud. Utilice varios Sin

elementos de encabezado si hay varios
encabezados de solicitud.
Cuerpo Cuerpo de la solicitud. Sin
authentication-certificate Certificado usado para la autenticación Sin

de cliente
Atributos
mode="cadena" Determina si se trata de una Sin Nuevo

solicitud nueva o de una
copia de la solicitud actual.
En el modo de salida,
mode=copy no inicializa el
cuerpo de la solicitud.
response-variable- El nombre de la variable de Sí N/D

name="cadena" contexto que va a recibir un
objeto de respuesta. Si la
variable no existe, se creará
tras la ejecución correcta de
la directiva y se podrá
acceder a ella a través de la
colección
context.Variable .
timeout="entero" Intervalo de tiempo de Sin 60

espera en segundos antes
de que se produzca un error
de la llamada a la dirección
URL.
ignore-error Si es true y la solicitud tiene Sin false

como resultado un error:
- Si se especificó response-
variable-name, contendrá un
valor nulo.
- Si no se especificó
response-variable-name, no
se actualizará
context.Request.

establecer.

ha especificado un
siguientes valores:

de la solicitud.
varias entradas con el mismo
nombre, se establece el
encabezado de acuerdo con
todas ellas (que se
Uso
Establecer proxy HTTP

La directiva proxy le permite enrutar las solicitudes reenviadas a los back-ends a través de un proxy HTTP. Solo se
admite HTTP (no HTTPS ) entre la puerta de enlace y el proxy. Solo autenticación básica y NTLM.
<proxy url="http://hostname-or-ip:port" username="username" password="password" />
Ejemplo
Observe el uso de propiedades como valores de nombre de usuario y contraseña para evitar almacenar
información confidencial en el documento de directiva.
<proxy url="http://192.168.1.1:8080" username={{username}} password={{password}} />
Elementos
proxy Elemento raíz Sí

Atributos
url="string" Dirección URL del proxy en Sí N/D

forma de http://host:port.
username="string" Nombre de usuario que se Sin N/D

usará para la autenticación
con el servidor proxy.
password="string" Contraseña que se usará Sin N/D

para la autenticación con el
servidor proxy.
Uso
Establecimiento de método de solicitud

La directiva set-method le permite cambiar el método de solicitud de HTTP para una solicitud.
<set-method>METHOD</set-method>
Ejemplo
En este ejemplo, donde se usa la directiva set-method , se ilustra cómo enviar un mensaje a un salón de chat de
Slack cuando el código de respuesta HTTP es mayor o igual que 500. Si desea más información sobre este
ejemplo, consulte Uso de servicios externos del servicio Azure API Management.
<choose>
<set-body>@{
return new JObject(
context.User.Email
))
).ToString();
}</set-body>
</when>
</choose>
Elementos
set-method Elemento raíz. El valor del elemento Sí

especifica el método HTTP.
Uso
Secciones de la directiva: entrante y en caso de error
Establecimiento de código de estado

La directiva set-status establece el código de estado HTTP en el valor especificado.
<set-status code="" reason=""/>
Ejemplo
En este ejemplo se muestra cómo devolver una respuesta 401 si el token de autorización no es válido. Si desea
más información, consulte Uso de servicios externos del servicio Azure API Management.
<choose>
false)">
</set-header>
</return-response>
</when>
</choose>
Elementos
set-status Elemento raíz. Sí
Atributos
code="entero" Código de estado HTTP que Sí N/D

se devuelve.
reason="cadena" Una descripción del motivo Sí N/D

por el que se devuelve el
código de estado.
Uso
Secciones de la directiva: saliente, back-end y en caso de error
Establecimiento de variable
La directiva set-variable declara una variable de contexto y le asigna un valor que se especifica mediante una
expresión o un literal de cadena. Si la expresión contiene un valor literal, se convertirá en una cadena y el tipo del
valor será System.String .
<set-variable name="variable name" value="Expression | String literal" />
Ejemplo
En el ejemplo siguiente se muestra una directiva de establecimiento de variable en la sección de entrada. Esta
directiva de establecimiento de variable crea una variable de contexto booleana de isMobile que se establece en
true si el encabezado de la solicitud User-Agent contiene el texto iPad o iPhone .
<set-variable name="IsMobile" value="@(context.Request.Headers["User-Agent"].Contains("iPad") ||

context.Request.Headers["User-Agent"].Contains("iPhone"))" />
Elementos
set-variable Elemento raíz. Sí
Atributos
Nombre El nombre de la variable. Sí
value El valor de la variable. Puede ser una Sí

expresión o un valor literal.
Uso
Tipos permitidos
Las expresiones usadas en la directiva set-variable deben devolver uno de los siguientes tipos básicos.
System.Boolean
System.SByte
System.Byte
System.UInt16
System.UInt32
System.UInt64
System.Int16
System.Int32
System.Int64
System.Decimal
System.Single
System.Double
System.Guid
System.String
System.Char
System.DateTime
System.TimeSpan
System.Byte?
System.UInt16?
System.UInt32?
System.UInt64?
System.Int16?
System.Int32?
System.Int64?
System.Decimal?
System.Single?
System.Double?
System.Guid?
System.String?
System.Char?
System.DateTime?
Seguimiento
La directiva trace agrega una cadena a la salida de API Inspector. La directiva se ejecutará solamente cuando se
desencadena el seguimiento, es decir, cuando el encabezado de solicitud Ocp-Apim-Trace está presente y
establecido en true , y cuando el encabezado de solicitud Ocp-Apim-Subscription-Key está presente y contiene una
clave válida asociada a la cuenta de administrador.
<trace source="arbitrary string literal">


</trace>
Elementos
trace Elemento raíz. Sí
Atributos
de origen Literal de cadena que resulta Sí N/D

significativo para el visor de
seguimiento y especifica el
origen del mensaje.
Uso
Espera
La directiva wait ejecuta sus directivas secundarias inmediatas en paralelo y espera a que se completen todas o
una de ellas para finalizar. La directiva de espera puede tener las directivas de envío de solicitud, obtención del
valor de caché y flujo de control como directivas secundarias inmediatas.
<wait for="all|any">

</wait>
Ejemplo
En el ejemplo siguiente hay dos directivas choose que son directivas secundarias inmediatas de la directiva wait .
Cada una de estas directivas choose se ejecuta en paralelo. Cada directiva choose intenta recuperar un valor
almacenado en memoria caché. Si se produce un error de memoria caché, se llama a un servicio back-end para que
proporcione el valor. En este ejemplo la directiva wait no se completa hasta que lo han hecho todas sus directivas
secundarias inmediatas, ya que el atributo for está establecido en all . Las variables de contexto (
execute-branch-one , value-one , execute-branch-two y value-two ) quedan fuera del ámbito de esta directiva de
ejemplo.
<wait for="all">
<choose>
<when condition="@((bool)context.Variables["execute-branch-one="])">
<cache-lookup-value key="key-one" variable-name="value-one" />
<choose>
<when condition="@(!context.Variables.ContainsKey("value-one="))">
<send-request mode="new" response-variable-name="value-one">
<set-url>https://backend-one</set-url>
</send-request>
</when>
</choose>
</when>
</choose>
<choose>
<when condition="@((bool)context.Variables["execute-branch-two="])">
<cache-lookup-value key="key-two" variable-name="value-two" />
<choose>
<when condition="@(!context.Variables.ContainsKey("value-two="))">
<send-request mode="new" response-variable-name="value-two">
<set-url>https://backend-two</set-url>
</send-request>
</when>
</choose>
</when>
</choose>
</wait>
Elementos
wait Elemento raíz. Solo puede contener Sí

como elementos secundarios a las
directivas send-request ,
cache-lookup-value y choose .
Atributos
for Determina si la directiva Sin todas

wait espera a que se
hayan completado todas las
directivas secundarias
inmediatas o solo una. Los
valores permitidos son:
- all : espera a que se

hayan completado todas las
directivas secundarias
inmediatas.
- any: espera a que se haya
completado cualquier
directiva secundaria
inmediata. En cuanto se
completa la primera, la
directiva wait también se
completa y finaliza la
ejecución de cualquier otra
directiva secundaria
inmediata.
Uso
Secciones de la directiva: entrante, saliente y back-end
Pasos siguientes
Directivas de autenticación de Azure API
Management
Autenticar con opción básica : autenticar con un servicio de back-end mediante la autenticación básica.
Autenticar con certificado de cliente : autenticar con un servicio de back-end mediante certificados de
cliente.
Autenticar con identidad administrada: autenticar con una identidad administrada para el servicio API
Management.
Autenticación con Basic

Use la directiva authentication-basic para realizar la autenticación con un servicio de back-end mediante
autenticación Básica. Esta directiva establece eficazmente el encabezado de autorización HTTP en el valor
correspondiente a las credenciales proporcionadas en la directiva.
<authentication-basic username="username" password="password" />
Ejemplo
<authentication-basic username="testuser" password="testpassword" />
Elementos
authentication-basic Elemento raíz. Sí
Atributos
username Especifica el nombre de Sí N/D

usuario de la credencial
básica.
password Especifica la contraseña de Sí N/D

usuario de la credencial
básica.
Uso
Autenticación Básica
Use la directiva authentication-certificate para realizar la autenticación con un servicio de back-end mediante un
certificado de cliente. El certificado se debe instalar primero en API Management y se identifica mediante su huella
digital.
<authentication-certificate thumbprint="thumbprint" certificate-id="resource name"/>
Ejemplos
En este ejemplo, el certificado de cliente se identifica mediante su huella digital.
<authentication-certificate thumbprint="CA06F56B258B7A0D4F2B05470939478651151984" />
En este ejemplo, el certificado de cliente se identifica mediante el nombre de recurso.
<authentication-certificate certificate-id="544fe9ddf3b8f30fb490d90f" />
Elementos
authentication-certificate Elemento raíz. Sí
Atributos
thumbprint La huella digital del thumbprint o N/D

certificado de cliente. certificate-id debe estar
presente.
certificate-id Nombre del recurso de thumbprint o N/D

certificado. certificate-id debe estar
presente.
Uso
Autenticación con una identidad administrada

Use la directiva authentication-managed-identity para autenticarse con un servicio de back-end mediante la
identidad administrada del servicio de API Management. Esta directiva usa eficazmente la identidad administrada
para obtener un token de acceso de Azure Active Directory para acceder al recurso especificado.
<authentication-managed-identity resource="resource" output-token-variable-name="token-variable" ignore-

error="true|false"/>
Ejemplo
<authentication-managed-identity resource="https://graph.windows.net" output-token-variable-name="test-access-

token" ignore-error="true" />
Elementos
authentication-managed-identity Elemento raíz. Sí
Atributos
resource String. URI del identificador Sí N/D

de aplicación de la API web
de destino (recurso seguro)
en Azure Active Directory.
output-token-variable-name String. Nombre de la variable Sin N/D

de contexto que recibirá el
valor del token como un tipo
de objeto string .
ignore-error Booleano. Si se establece en Sin false

true , la canalización de
directivas seguirá
ejecutándose incluso si no se
obtiene un token de acceso.
Uso
Pasos siguientes
Directivas de almacenamiento en caché de API
Management
Directivas de almacenamiento en caché

Directivas de almacenamiento en caché de respuesta
Get from cache: realiza una búsqueda en caché y devuelve una respuesta en caché válida cuando está
disponible.
Store to cache (Almacenar en la caché): almacena en caché la respuesta de acuerdo con la configuración
de control de caché especificada.
Directivas de almacenamiento en caché de valores
Obtener valor de caché : recupere un elemento almacenado en caché por clave.
Almacenar valor en caché : almacene un elemento en la memoria caché por clave.
Quitar valor de caché; quita un elemento de la memoria caché por clave.
Get from cache

Use la directiva cache-lookup para realizar una consulta en la caché y devolver una respuesta en caché válida
cuando esté disponible. Esta directiva se puede aplicar en aquellos casos en los que el contenido de respuesta
permanezca estático durante un período de tiempo. El almacenamiento en caché de respuesta reduce el ancho de
banda y los requisitos de procesamiento impuestos sobre el servidor web de back-end y disminuye la latencia
percibida por los consumidores de API.
NOTE
Esta directiva debe tener una directiva Store to cache (Almacenar en la caché) correspondiente.
<cache-lookup vary-by-developer="true | false" vary-by-developer-groups="true | false" caching-type="prefer-

external | external | internal" downstream-caching-type="none | private | public" must-revalidate="true |
false" allow-private-response-caching="@(expression to evaluate)">


<vary-by-header>Authorization</vary-by-header>

<vary-by-header>header name</vary-by-header>

<vary-by-query-parameter>parameter name</vary-by-query-parameter>

</cache-lookup>
Ejemplos
Ejemplo
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-
type="none" must-revalidate="true" caching-type="internal" >
<vary-by-query-parameter>version</vary-by-query-parameter>
</cache-lookup>
</inbound>
<outbound>
<cache-store duration="seconds" />
<base />
</outbound>
</policies>
Ejemplo de uso de expresiones de directiva

En este ejemplo se muestra cómo configurar la duración del almacenamiento en caché de respuesta de API
Management para que coincida con el almacenamiento en caché de respuesta del servicio de back-end
especificado por la directiva Cache-Control del servicio de back-end. Para ver una demostración de la
configuración y el uso de esta directiva, consulte el Episodio 177 de Cloud Cover: More API Management
Features with Vlad Vinogradsky (Más características de API Management con Vlad Vinogradsky) y avance hasta
el minuto 25:25.



<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="public"
must-revalidate="true" >
</cache-lookup>

<cache-store duration="@{
var header = context.Response.Headers.GetValueOrDefault("Cache-Control","");
var maxAge = Regex.Match(header, @"max-age=(?<maxAge>\d+)").Groups["maxAge"]?.Value;
return (!string.IsNullOrEmpty(maxAge))?int.Parse(maxAge):300;
}"
/>
Para obtener más información, consulte Policy expressions (Expresiones de política) y Context variable (Variable
de contexto).
Elementos
cache-lookup Elemento raíz. Sí
vary-by-header Inicia el almacenamiento en caché de Sin

respuestas por valor del encabezado
especificado, por ejemplo, Accept,
Accept-Charset, Accept-Encoding,
Accept-Language, Authorization,
Expect, From, Host, If-Match.
vary-by-query-parameter Inicia el almacenamiento en caché de Sin

las respuestas por valor de los
parámetros de consulta especificados.
Permite introducir uno o varios
parámetros. Utilice el punto y coma
como separador. Si no se especifica
ninguno, se usan todos los parámetros
de consulta.
Atributos
allow-private-response- Cuando se establece en Sin false

caching true , permite el
almacenamiento en caché
de las solicitudes que
contienen un encabezado de
autorización.
caching-type Elija entre los siguientes Sin prefer-external

valores del atributo:
- internal para usar la
caché de API Management
integrada,
- external para usar la
caché externa tal como se
describe en Uso de una
memoria caché de Redis
externa en Azure API
Management,
- prefer-external para
usar la caché externa si está
configurada o, en caso
contrario, la caché interna.
downstream-caching-type Este atributo debe Sin None

establecerse en uno de los
siguientes valores.
- none: no se permite el
de bajada.
- private: se permite el
de bajada privado.
- public: se permite el
de bajada privado y
compartido.
must-revalidate Cuando el almacenamiento Sin true

en caché de bajada está
habilitado, este atributo
activa o desactiva la
directiva de control de caché
must-revalidate en las
respuestas de puerta de
enlace.
vary-by-developer Se establece en true para Sí False

almacenar en caché las
respuestas por clave de
suscripción.
vary-by-developer-groups Se establece en true para Sí False

almacenar en caché las
respuestas por grupo de
usuarios.
Uso
Store to cache (Almacenar en la caché)

La directiva cache-store almacena en caché las respuestas según la configuración de caché especificada. Esta
directiva se puede aplicar en aquellos casos en los que el contenido de respuesta permanezca estático durante un
período de tiempo. El almacenamiento en caché de respuesta reduce el ancho de banda y los requisitos de
procesamiento impuestos sobre el servidor web de back-end y disminuye la latencia percibida por los
consumidores de API.
NOTE
Esta directiva debe tener una directiva Get from cache correspondiente.
<cache-store duration="seconds" />
Ejemplos
Ejemplo
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="true | false" vary-by-developer-groups="true | false" downstream-
caching-type="none | private | public" must-revalidate="true | false">
<vary-by-query-parameter>parameter name</vary-by-query-parameter> 
</cache-lookup>
</inbound>
<outbound>
<base />
<cache-store duration="3600" />
</outbound>
</policies>
Ejemplo de uso de expresiones de directiva

En este ejemplo se muestra cómo configurar la duración del almacenamiento en caché de respuesta de API
Management para que coincida con el almacenamiento en caché de respuesta del servicio de back-end
especificado por la directiva Cache-Control del servicio de back-end. Para ver una demostración de la
configuración y el uso de esta directiva, consulte el Episodio 177 de Cloud Cover: More API Management
Features with Vlad Vinogradsky (Más características de API Management con Vlad Vinogradsky) y avance hasta
el minuto 25:25.



<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="public"
must-revalidate="true" >
</cache-lookup>

<cache-store duration="@{
var header = context.Response.Headers.GetValueOrDefault("Cache-Control","");
var maxAge = Regex.Match(header, @"max-age=(?<maxAge>\d+)").Groups["maxAge"]?.Value;
return (!string.IsNullOrEmpty(maxAge))?int.Parse(maxAge):300;
}"
/>
Para obtener más información, consulte Policy expressions (Expresiones de política) y Context variable (Variable
de contexto).
Elementos
cache-store Elemento raíz. Sí
Atributos
duration Período de vida de las Sí N/D

entradas almacenadas en
caché, especificado en
segundos.
Uso
Esta directiva puede usarse en las siguientes secciones y ámbitos de las directivas.
Secciones de la directiva: outbound
Get value from cache (Obtener valor de la caché)

Use la directiva cache-lookup-value para realizar la búsqueda en la caché por clave y devolver un valor
almacenado en caché. La clave puede tener un valor de cadena arbitrario y normalmente se proporciona
mediante una expresión de directiva.
NOTE
Esta directiva debe tener una directiva Store value in cache (Almacenar valor en la caché) correspondiente.
<cache-lookup-value key="cache key value"

default-value="value to use if cache lookup resulted in a miss"
variable-name="name of a variable looked up value is assigned to"
caching-type="prefer-external | external | internal" />
Ejemplo
Para más información y ver ejemplos de esta directiva, consulte Custom caching in Azure API Management
(Almacenamiento en caché personalizado en Azure API Management).
<cache-lookup-value
Elementos
cache-lookup-value Elemento raíz. Sí
Atributos

integrada,
Management,
default-value Un valor que se asignará a Sin null

la variable si la búsqueda de
la clave de caché da lugar a
un error. Si no se especifica
este atributo, se asigna
null .
key Valor de clave de caché para Sí N/D

usar en la búsqueda.
variable-name Nombre de la variable de Sí N/D

contexto a la que se
asignará el valor buscado si
la búsqueda tiene éxito. Si se
produce un error de
búsqueda, se asignará a la
variable el valor del atributo
default-value o null , si
se omite el atributo
default-value .
Uso
Store value in cache (Almacenar valor en la caché)

La directiva cache-store-value realiza el almacenamiento en caché mediante una clave. La clave puede tener un
valor de cadena arbitrario y normalmente se proporciona mediante una expresión de directiva.
NOTE
Esta directiva debe tener una directiva Get from cache (Obtener de la caché) correspondiente.
<cache-store-value key="cache key value" value="value to cache" duration="seconds" caching-type="prefer-
external | external | internal" />
Ejemplo
Para más información y ver ejemplos de esta directiva, consulte Custom caching in Azure API Management
(Almacenamiento en caché personalizado en Azure API Management).
<cache-store-value
value="@((string)context.Variables["userprofile"])" duration="100000" />
Elementos
cache-store-value Elemento raíz. Sí
Atributos

integrada,
Management,
duration El valor se almacenará en la Sí N/D

caché según el valor de
duración proporcionado,
especificado en segundos.
key La clave de caché con la que Sí N/D

se almacenará el valor.
value El valor que se almacenará Sí N/D

en la caché.
Uso
Remove value from cache (Quitar valor de la caché )
La directiva cache-remove-value elimina un elemento almacenado en caché identificado por su clave. La clave
puede tener un valor de cadena arbitrario y normalmente se proporciona mediante una expresión de directiva.
<cache-remove-value key="cache key value" caching-type="prefer-external | external | internal" />
Ejemplo
<cache-remove-value key="@("userprofile-" + context.Variables["enduserid"])"/>
Elementos
cache-remove-value Elemento raíz. Sí
Atributos

integrada,
Management,
key La clave del valor Sí N/D

anteriormente almacenado
en caché que se quitará de
la memoria caché.
Uso
Pasos siguientes
Directivas entre dominios de API Management

Permitir llamadas entre dominios : permite que la API sea accesible desde los clientes basados en explorador de
Adobe Flash y Microsoft Silverlight.
CORS : agrega soporte de uso compartido de recursos entre orígenes (CORS ) a una operación o a una API
para permitir llamadas entre dominios desde clientes basados en explorador.
JSONP : agrega JSON con soporte de relleno (JSONP ) a una operación o a una API para permitir llamadas
entre dominios desde clientes basados en explorador de JavaScript.
Allow cross-domain calls (Permitir llamadas entre dominios)

Use la directiva cross-domain para que la API sea accesible desde Adobe Flash y clientes basados en explorador de
Microsoft Silverlight.
Declaración de directiva
<cross-domain>
<!-Policy configuration is in the Adobe cross-domain policy file format,
see https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html-->
</cross-domain>
Ejemplo
<cross-domain>
<cross-domain>
<allow-http-request-headers-from domain='*' headers='*' />
</cross-domain>
</cross-domain>
Elementos
entre dominios Elemento raíz. Los elementos Sí

secundarios deben ajustarse a la
especificación de archivos de directivas
entre dominios de Adobe.
Uso
CORS
La directiva cors agrega compatibilidad con el uso compartido de recursos entre orígenes (CORS ) a una
operación o a una API para permitir llamadas entre dominios desde clientes basados en explorador.
CORS permite a un explorador y a un servidor interactuar y determinar si se permiten o no solicitudes específicas
entre orígenes (por ejemplo, llamadas XMLHttpRequests realizadas desde JavaScript en una página web a otros
dominios). Esto permite más flexibilidad que si solo se permiten solicitudes del mismo origen, pero es más seguro
que permitir todas las solicitudes entre orígenes.
<cors allow-credentials="false|true">
<allowed-origins>
<origin>origin uri</origin>
</allowed-origins>
<allowed-methods preflight-result-max-age="number of seconds">
<method>http verb</method>
</allowed-methods>
<allowed-headers>
<header>header name</header>
</allowed-headers>
<expose-headers>
<header>header name</header>
</expose-headers>
</cors>
Ejemplo
En este ejemplo se muestra cómo admitir solicitudes preparatorias, como aquellas con encabezados o métodos
personalizados distintos de GET y POST. Para admitir encabezados personalizados y verbos HTTP adicionales, use
las secciones allowed-methods y allowed-headers tal como se muestra en el ejemplo siguiente.
<cors allow-credentials="true">
<allowed-origins>

<origin>http://localhost:8080/</origin>
<origin>http://example.com/</origin>
</allowed-origins>
<allowed-methods preflight-result-max-age="300">
<method>GET</method>
<method>POST</method>
<method>PATCH</method>
<method>DELETE</method>
</allowed-methods>
<allowed-headers>

<header>x-zumo-installation-id</header>
<header>x-zumo-application</header>
<header>x-zumo-version</header>
<header>x-zumo-auth</header>
<header>content-type</header>
<header>accept</header>
</allowed-headers>
<expose-headers>

<header>x-zumo-installation-id</header>
<header>x-zumo-application</header>
</expose-headers>
</cors>
Elementos
cors Elemento raíz. Sí N/D
allowed-origins Contiene elementos Sí N/D

origin que describen los
orígenes permitidos para las
solicitudes entre dominios.
allowed-origins puede
contener un único elemento
origin que especifica *
para permitir cualquier
origen, o uno o varios
elementos origin que
contienen un identificador
URI.
origin El valor puede ser * para Sí Si se omite el puerto en un

permitir todos los orígenes o identificador URI, se usa el
un identificador URI que puerto 80 para HTTP y el
especifica un único origen. El puerto 443 para HTTPS.
URI debe incluir un
esquema, un host y un
puerto.
allowed-methods Este elemento es necesario si Sin Si esta sección no está

se permiten métodos presente, se admiten GET y
distintos de GET o POST. POST.
Contiene elementos
method que especifican los
verbos HTTP admitidos.
method Especifica un verbo HTTP. Al menos un elemento N/D

method es necesario si la
sección allowed-methods
está presente.
allowed-headers Este elemento contiene Sin N/D

elementos header que
especifican los nombres de
los encabezados que pueden
incluirse en la solicitud.
expose-headers Este elemento contiene Sin N/D

elementos header que
especifican los nombres de
los encabezados a los que
tendrá acceso el cliente.
encabezado Especifica un nombre de Al menos un elemento N/D

encabezado. header es necesario en
allowed-headers o
expose-headers si está
presente la sección.
Atributos
allow-credentials El encabezado Sin false

Access-Control-Allow-
Credentials
de la respuesta preparatoria
se establecerá en el valor de
este atributo e influirá en la
posibilidad de que el cliente
pueda enviar credenciales en
solicitudes entre dominios.
preflight-result-max-age El encabezado Sin 0

Access-Control-Max-Age
de la respuesta preparatoria
se establecerá en el valor de
este atributo e influirá en la
posibilidad de que el agente
del usuario pueda almacenar
en caché la respuesta
preparatoria.
Uso
JSONP
La directiva jsonp agrega JSON con compatibilidad con relleno (JSONP ) a una operación o a una API para
permitir llamadas entre dominios desde clientes basados en explorador de JavaScript. JSONP es un método
utilizado en los programas JavaScript para solicitar datos desde un servidor en un dominio diferente. JSONP
sortea la limitación exigida por la mayoría de los exploradores web donde el acceso a las páginas web debe estar
en el mismo dominio.
<jsonp callback-parameter-name="callback function name" />
Ejemplo
<jsonp callback-parameter-name="cb" />
Si llama al método sin el parámetro de devolución de llamada ?cb=XXX, devolverá JSON sin formato (sin un
envoltorio de llamada de función).
Si agrega el parámetro de devolución de llamada ?cb=XXX , devolverá un resultado JSONP, envolviendo los
resultados JSON originales en torno a la función de devolución de llamada como XYZ('<json result goes here>');
.
Elementos
jsonp Elemento raíz. Sí

Atributos
callback-parameter-name La llamada de función de Sí N/D

JavaScript entre dominios
prefijada con el nombre de
dominio completo en donde
reside la función.
Uso
Esta directiva puede usarse en las siguientes secciones y ámbitos de las directivas.
Secciones de la directiva: outbound
Pasos siguientes
Directivas de transformación de API Management
Convertir JSON a XML : convierte el cuerpo de solicitud o respuesta de JSON a XML.
Convertir XML a JSON : convierte el cuerpo de solicitud o respuesta de XML a JSON.
Buscar y reemplazar la cadena en el cuerpo : encuentra una subcadena de solicitud o de respuesta y la
reemplaza por una subcadena diferente.
Enmascarar URL en el contenido : reescribe (enmascara) vínculos en el cuerpo de respuesta para que
apunten al vínculo equivalente a través de la puerta de enlace.
Establecer el servicio back-end : cambia el servicio back-end para una solicitud entrante.
Establecer cuerpo -establece el cuerpo del mensaje para las solicitudes entrantes y salientes.
Establecer encabezado HTTP : asigna un valor a un encabezado de respuesta o de solicitud existente o
agrega un nuevo encabezado de este tipo.
Establecer el parámetro de cadena de consulta : agrega, reemplaza el valor o elimina el parámetro de la
cadena de consulta de la solicitud.
URL de reescritura : convierte una URL de solicitud de su forma pública a la forma esperada por el servicio
web.
Transformar XML mediante una XSLT: aplica una transformación de XSL al XML del cuerpo de la solicitud o
respuesta.
Conversión de JSON a XML

La directiva json-to-xml convierte un cuerpo de solicitud o respuesta de JSON a XML.
<json-to-xml apply="always | content-type-json" consider-accept-header="true | false" parse-date="true |

false"/>
Ejemplo
<policies>
<inbound>
<base />
</inbound>
<outbound>
<base />
<json-to-xml apply="always" consider-accept-header="false" parse-date="false"/>
</outbound>
</policies>
Elementos
json-to-xml Elemento raíz. Sí
Atributos
apply El atributo debe establecerse Sí N/D

en uno de los siguientes
valores.
- always: indica que se debe

aplicar la conversión
siempre.
- content-type-json:
especifica que solo se debe
realizar la conversión si el
encabezado Content-Type
indica la presencia de JSON.
consider-accept-header El atributo debe establecerse Sin true

valores.
- true: especifica que se

debe aplicar la conversión si
se solicita JSON en el
encabezado de aceptación
(Accept) de la solicitud.
- false: indica que se debe
aplicar siempre la
conversión.
parse-date Cuando se establece en Sin true

false , los valores de fecha
simplemente se copian
durante la transformación.
Uso
Conversión de XML a JSON

La directiva xml-to-json convierte un cuerpo de solicitud o respuesta de XML a JSON. Esta directiva puede
usarse para modernizar API basadas en servicios web de back-end de solo XML.
<xml-to-json kind="javascript-friendly | direct" apply="always | content-type-xml" consider-accept-

header="true | false"/>
Ejemplo
<policies>
<inbound>
<base />
</inbound>
<outbound>
<base />
<xml-to-json kind="direct" apply="always" consider-accept-header="false" />
</outbound>
</policies>
Elementos
xml-to-json Elemento raíz. Sí
Atributos
kind El atributo debe establecerse Sí N/D

valores.
- javascript-friendly: el
código JSON convertido
presenta un formato
intuitivo para los
desarrolladores de
JavaScript.
- direct: el código JSON
convertido refleja la
estructura del documento
XML original.
apply El atributo debe establecerse Sí N/D

valores.
- always: indica que se debe

realizar la conversión
siempre.
- content-type-XML:
especifica que solo se debe
realizar la conversión si el
encabezado Content-Type
indica la presencia de XML.
consider-accept-header El atributo debe establecerse Sin true

valores.
- true: especifica que se

debe aplicar la conversión si
se solicita XML en el
encabezado de aceptación
(Accept) de la solicitud.
- false: indica que se debe
aplicar siempre la
conversión.
Uso
Buscar y reemplazar la cadena en el cuerpo

La política find-and-replace busca una subcadena de solicitud o de respuesta y la sustituye por otra distinta.
<find-and-replace from="what to replace" to="replacement" />
Ejemplo
<find-and-replace from="notebook" to="laptop" />
Elementos
find-and-replace Elemento raíz. Sí
Atributos
De La cadena que se va a Sí N/D

buscar.
Para La cadena de sustitución. Sí N/D

Especifique una cadena de
reemplazo de longitud cero
para quitar la cadena de
búsqueda.
Uso
Enmascarar URL en el contenido

La directiva redirect-content-urls reescribe (enmascara) los vínculos del cuerpo de la respuesta para que
apunten al vinculo equivalente a través de la puerta de enlace. Utilícela en la sección saliente a fin de rescribir los
vínculos del cuerpo de la respuesta para hacer que apunten a la puerta de enlace. Úsela en la sección entrante para
obtener el resultado opuesto.
NOTE
Esta directiva no cambia los valores de los encabezados, como los Location . Para cambiar los valores del encabezado, use
la directiva set-header.
<redirect-content-urls />
Ejemplo
<redirect-content-urls />
Elementos
redirect-content-urls Elemento raíz. Sí
Uso
Establecer el servicio back-end

Use la directiva set-backend-service a fin de redirigir una solicitud entrante a un back-end distinto al especificado
en la configuración de la API para esa operación. Esta directiva cambia la dirección URL base del servicio back-end
de la solicitud entrante a la especificada en la directiva.
<set-backend-service base-url="base URL of the backend service" />
<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service"
/>
NOTE
Las entidades de back-end pueden administrarse mediante API y PowerShell.
Ejemplo
<policies>
<inbound>
<choose>
<when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2013-05")">
<set-backend-service base-url="http://contoso.com/api/8.2/" />
</when>
<when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2014-03")">
<set-backend-service base-url="http://contoso.com/api/9.1/" />
</when>
</choose>
<base />
</inbound>
<outbound>
<base />
</outbound>
</policies>
En este ejemplo, la directiva del servicio back-end establecida enruta las solicitudes según el valor de versión
pasado en la cadena de consulta a un servicio back-end distinto del especificado en la API.
Inicialmente, la dirección URL base del servicio back-end se obtiene a partir de la configuración de la API. Por ello,
la dirección URL de solicitud
https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdef se convierte en
http://contoso.com/api/10.4/partners/15?version=2013-05&subscription-key=abcdef , donde
http://contoso.com/api/10.4/ se corresponde con la dirección URL del servicio back-end especificada en la
configuración de la API.
Cuando se aplica la instrucción de la directiva <choose>, la dirección URL base del servicio back-end puede volver
a cambiar a http://contoso.com/api/8.2 o http://contoso.com/api/9.1 , en función del valor del parámetro de
consulta de la solicitud de la versión. Por ejemplo, si el valor es "2013-15" , la dirección URL final de la solicitud se
convierte en http://contoso.com/api/8.2/partners/15?version=2013-05&subscription-key=abcdef .
Si se desea aplicar más transformaciones a la solicitud, es posible usar otras directivas de transformación. Por
ejemplo, para quitar el parámetro de consulta de la versión ahora que la solicitud se está enrutando a un back-end
específico de la versión, se puede usar la directiva de establecimiento del parámetro de cadena de consulta para
quitar el atributo de versión, que ahora presenta un carácter redundante.
Ejemplo
<policies>
<inbound>
<set-backend-service backend-id="my-sf-service" sf-partition-
key="@(context.Request.Url.Query.GetValueOrDefault("userId","")" sf-replica-type="primary" />
</inbound>
<outbound>
<base />
</outbound>
</policies>
En este ejemplo, la directiva enruta la solicitud a un back-end de Service Fabric, con la cadena de consulta userId
como la clave de partición y con la réplica principal de la partición.
Elementos
set-backend-service Elemento raíz. Sí
Atributos
base-url Nueva dirección URL base base-url o backend-id N/D

del servicio back-end. deben estar presentes.
backend-id Identificador del back-end al base-url o backend-id N/D

que se va a enrutar. (Las deben estar presentes.
entidades de back-end se
administran mediante API y
PowerShell).
sf-partition-key Solo se aplica cuando el Sin N/D

back-end es un servicio de
Service Fabric y se especifica
con "backend-id". Se usa
para resolver una partición
específica desde el servicio
de resolución de nombres.
sf-replica-type Solo se aplica cuando el Sin N/D

con "backend-id". Controla
si la solicitud debe ir a la
réplica principal o secundaria
de una partición.
sf-resolve-condition Solo se aplica cuando el Sin N/D

Service Fabric. Condición
que identifica si la llamada al
back-end de Service Fabric
tiene que repetirse con la
nueva resolución.
sf-service-instance-name Solo se aplica cuando el Sin N/D

Service Fabric. Permite
cambiar instancias de
servicio en tiempo de
ejecución.
sf-listener-name Solo se aplica cuando el Sin N/D

con "backend-id". Service
Fabric Reliable Services le
permite crear varios agentes
de escucha en un servicio.
Este atributo se utiliza para
seleccionar un agente de
escucha específico cuando
una instancia de Reliable
Service de back-end tiene
más de un agente de
escucha. Si no se especifica
este atributo, API
Management intentará usar
un agente de escucha sin
nombre. Un agente de
escucha sin nombre es típico
de las instancias de Reliable
Services que tienen un solo
agente de escucha.
Uso
Secciones de la directiva: entrante y back-end
Establecer cuerpo
Utilice la directiva set-body con la finalidad de establecer el cuerpo del mensaje para las solicitudes entrantes y
salientes. Para acceder al cuerpo del mensaje, puede utilizar las propiedades context.Request.Body o
context.Response.Body , según si la directiva se encuentra en la sección entrante o saliente.
IMPORTANT
Tenga en cuenta que, de forma predeterminada, al acceder al cuerpo del mensaje mediante context.Request.Body o
context.Response.Body , se pierde el cuerpo del mensaje original y se debe establecer devolviendo el cuerpo en la
expresión. Para conservar el contenido del cuerpo, establezca el parámetro preserveContent en true al acceder al
mensaje. Si preserveContent está establecido en true y la expresión devuelve un cuerpo distinto, se utiliza el que se
devuelva.
Tenga en cuenta las siguientes consideraciones al utilizar la directiva set-body .
Si usa la directiva set-body para devolver un cuerpo nuevo o actualizado, no hay que establecer preserveContent en
true porque estará especificando explícitamente el nuevo contenido del cuerpo.
No tiene sentido conservar el contenido de una respuesta en la canalización de entrada porque todavía no hay
ninguna respuesta.
De igual modo, no tiene sentido conservar el contenido de una solicitud en la canalización de salida porque la
solicitud ya se ha enviado al servidor en este momento.
Si esta directiva se usa cuando no hay ningún cuerpo de mensaje, por ejemplo, en un GET entrante, se producirá
una excepción.
Para obtener más información, consulte las secciones context.Request.Body , context.Response.Body y IMessage
de la tabla Context variable (Variable de contexto).
<set-body>new body value as text</set-body>
Ejemplos
Ejemplo de texto literal
<set-body>Hello world!</set-body>
Ejemplo de acceso al cuerpo como una cadena. Tenga en cuenta que estamos conservando el cuerpo de la solicitud original para que
resulte accesible más adelante en la canalización.
<set-body>
@{
string inBody = context.Request.Body.As<string>(preserveContent: true);
if (inBody[0] =='c') {
inBody[0] = 'm';
}
return inBody;
}
</set-body>
Ejemplo de acceso al cuerpo como un elemento JObject. Tenga en cuenta que, al no conservar el cuerpo de la solicitud original, el
acceso posterior a él en la canalización producirá una excepción.
<set-body>
@{
JObject inBody = context.Request.Body.As<JObject>();
if (inBody.attribute == <tag>) {
inBody[0] = 'm';
}
return inBody.ToString();
}
</set-body>
Filtro de respuesta según un producto

En este ejemplo se muestra cómo filtrar contenido quitando elementos de datos de la respuesta recibida del
servicio back-end al usar el producto Starter . Para ver una demostración de la configuración y el uso de esta
directiva, consulte el Episodio 177 de Cloud Cover: More API Management Features with Vlad Vinogradsky (Más
características de API Management con Vlad Vinogradsky) y avance hasta el minuto 34:30. Empiece en el minuto
31:50 para ver una introducción a la API de previsión de Dark Sky empleada en esta demostración.

<choose>
<when condition="@(context.Response.StatusCode == 200 && context.Product.Name.Equals("Starter"))">
<set-body>@{
var response = context.Response.Body.As<JObject>();
foreach (var key in new [] {"minutely", "hourly", "daily", "flags"}) {
response.Property (key).Remove ();
}
return response.ToString();
}
</set-body>
</when>
</choose>
Uso de plantillas Liquid con la directiva de establecer cuerpo
La directiva set-body se puede configurar para usar el lenguaje de plantillas Liquid para transformar el cuerpo de
una solicitud o una respuesta. Esto puede resultar muy eficaz si necesita cambiar completamente el formato del
mensaje.
IMPORTANT
La implementación de Liquid que se utiliza en la directiva set-body está configurada en el modo de C#. Esto es
especialmente importante al realizar tareas como el filtrado. Por ejemplo, para usar un filtro de fecha se requiere usar las
mayúsculas y minúsculas de Pascal y el formato de fecha de C#; por ejemplo:
{{body.foo.startDateTime| Date:"yyyyMMddTHH:mm:ddZ"}}
IMPORTANT
Para enlazar correctamente con un cuerpo XML mediante la plantilla Liquid, use una directiva set-header para establecer
que Content-Type sea application/xml, text/xml (o cualquier tipo que termine en +xml); para un cuerpo JSON, debe ser
application/json, texto/json (o cualquier tipo que termine en +json).
Conversión de JSON en SOAP mediante una plantilla Liquid
<set-body template="liquid">
<soap:Envelope xmlns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetOpenOrders>
<cust>{{body.getOpenOrders.cust}}</cust>
</GetOpenOrders>
</soap:Body>
</soap:Envelope>
</set-body>
Transformación de JSON mediante una plantilla Liquid
{
"order": {
"id": "{{body.customer.purchase.identifier}}",
"summary": "{{body.customer.purchase.orderShortDesc}}"
}
}
Elementos
set-body Elemento raíz. Contiene el cuerpo del Sí

texto o una expresión que devuelve un
cuerpo.
properties (Propiedades)
template Se utiliza para cambiar el Sin

modo de creación de
plantillas que ejecutará la
directiva de establecer
cuerpo. Actualmente, el
único valor admitido es:
- liquid: la directiva de
establecer cuerpo usará el
motor de plantillas Liquid
Para acceder a información sobre solicitud y respuesta, la plantilla Liquid puede enlazar a un objeto de contexto
con las siguientes propiedades:
context.
Request.
Url
Method
OriginalMethod
OriginalUrl
IpAddress
MatchedParameters
HasBody
ClientCertificates
Headers
Response.
StatusCode
Method
Headers
Url.
Scheme
Host
Port
Path
Query
QueryString
ToUri
ToString
OriginalUrl.
Scheme
Host
Port
Path
Query
QueryString
ToUri
ToString
Uso
Secciones de la directiva: entrante, saliente y back-end
Establecer encabezado HTTP
La directiva set-header asigna un valor a un encabezado de respuesta o de solicitud existente o agrega un nuevo
encabezado de este tipo.
Inserta una lista de encabezados HTTP en un mensaje HTTP. Cuando se coloca en un proceso entrante, esta
directiva establece los encabezados HTTP para la solicitud que se pasa al servicio de destino. Cuando se coloca en
una canalización saliente, esta directiva establece los encabezados HTTP para la respuesta que se está enviando al
cliente de la puerta de enlace.
<set-header name="header name" exists-action="override | skip | append | delete">

<value>value</value> 
</set-header>
Ejemplos
Ejemplo
<set-header name="some header name" exists-action="override">

<value>20</value>
</set-header>
Reenvío de información contextual al servicio back-end

En este ejemplo se muestra cómo aplicar directivas en el nivel de API para proporcionar información contextual al
servicio back-end. Para ver una demostración de la configuración y el uso de esta directiva, consulte el Episodio
177 de Cloud Cover: More API Management Features with Vlad Vinogradsky (Más características de API
Management con Vlad Vinogradsky) y avance hasta el minuto 10:30. En el minuto 12:10 se realiza una
demostración del llamamiento de una operación en el portal para desarrolladores donde podrá ver la directiva en
funcionamiento.

<set-header name="x-request-context-data" exists-action="override">
<value>@(context.User.Id)</value>
<value>@(context.Deployment.Region)</value>
</set-header>
Para obtener más información, consulte Policy expressions (Expresiones de política) y Context variable (Variable de
contexto).
NOTE
Varios valores de un encabezado se concatenan en una cadena CSV, por ejemplo, headerName: value1,value2,value3 .
Las excepciones incluyen encabezados estandarizados, cuyos valores:
pueden contener comas ( User-Agent , WWW-Authenticate , Proxy-Authenticate ),
pueden contener fechas ( Cookie , Set-Cookie , Warning ),
contienen fechas ( Date , Expires , If-Modified-Since , If-Unmodified-Since , Last-Modified , Retry-After ).
En el caso de esas excepciones, varios valores de encabezado no se concatenarán en una cadena y se pasarán como
encabezados independientes, por ejemplo, User-Agent: value1 User-Agent: value2 User-Agent: value3 .
Elementos
set-header Elemento raíz. Sí
value Especifica el valor del encabezado que Sí

se va a establecer. Para varios
encabezados con el mismo nombre,
agregue más elementos value .

ha especificado un
siguientes valores:

de la solicitud.
varias entradas con el
mismo nombre, se establece
el encabezado de acuerdo
con todas ellas (que se

establecer.
Uso
Establecimiento del parámetro de cadena de consulta

La directiva set-query-parameter agrega o elimina el parámetro de cadena de consulta de la solicitud, o bien
sustituye su valor. Se puede utilizar para pasar parámetros de consulta previstos por el servicio back-end que
tienen carácter opcional o que nunca están presentes en la solicitud.
<set-query-parameter name="param name" exists-action="override | skip | append | delete">
<value>value</value> 
Ejemplos
Ejemplo
<set-query-parameter>
<parameter name="api-key" exists-action="skip">
<value>12345678901</value>
</parameter>

Reenvío de información contextual al servicio back-end

En este ejemplo se muestra cómo aplicar directivas en el nivel de API para proporcionar información contextual al
servicio back-end. Para ver una demostración de la configuración y el uso de esta directiva, consulte el Episodio
177 de Cloud Cover: More API Management Features with Vlad Vinogradsky (Más características de API
Management con Vlad Vinogradsky) y avance hasta el minuto 10:30. En el minuto 12:10 se realiza una
demostración del llamamiento de una operación en el portal para desarrolladores donde podrá ver la directiva en
funcionamiento.

<set-query-parameter name="x-product-name" exists-action="override">
<value>@(context.Product.Name)</value>
Para obtener más información, consulte Policy expressions (Expresiones de política) y Context variable (Variable de
contexto).
Elementos
set-query-parameter Elemento raíz. Sí
value Especifica el valor del parámetro de Sí

consulta que se debe establecer. Para
varios parámetros de consulta con el
mismo nombre, agregue más
elementos value .

especifica un parámetro de
consulta. Este atributo debe
tener uno de los siguientes
valores:

del parámetro de consulta
existente.
existente.
existente.
- delete: quita el parámetro
de consulta de la solicitud.
override , se inscriben
varias entradas con los
resultados del mismo
nombre del parámetro de
consulta que se están
estableciendo de acuerdo
con todas las entradas (que
se inscribirán varias veces);
solo los valores mostrados
se establecerán en el
resultado.

parámetro de consulta que
se debe establecer.
Uso
Secciones de la directiva: entrante y back-end
URL de reescritura
La directiva rewrite-uri convierte una dirección URL de solicitud de su forma pública a la que espera recibir el
servicio web, como se muestra en el siguiente ejemplo.
URL pública: http://api.example.com/storenumber/ordernumber
URL de solicitud: http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&State
Esta directiva se puede utilizar cuando una URL apta para el explorador o para individuos debe
transformarse en el formato de URL que espera el servicio web. Esta directiva solo debe aplicarse al
exponer un formato de URL alternativo, como URL limpias, direcciones URL RESTful y direcciones URL
sencillas o aptas para optimización del motor de búsqueda que son URL puramente estructurales que no
contienen una cadena de consulta, sino solo la ruta del recurso (después del esquema y la autoridad). Este
procedimiento se realiza con fines estéticos, de usabilidad o de optimización del motor de búsqueda (SEO ).
NOTE
Solo puede agregar parámetros de cadena de consulta mediante esta directiva. No puede agregar ningún parámetro de ruta
de plantilla adicional en la URL de reescritura.
<rewrite-uri template="uri template" copy-unmatched-params="true | false" />
Ejemplo
<policies>
<inbound>
<base />
<rewrite-uri template="/v2/US/hardware/{storenumber}&{ordernumber}?City=city&State=state" />
</inbound>
<outbound>
<base />
</outbound>
</policies>

<policies>
<inbound>
<base />
<rewrite-uri template="/put" />
</inbound>
<outbound>
<base />
</outbound>
</policies>


<policies>
<inbound>
<base />
<rewrite-uri template="/put" copy-unmatched-params="false" />
</inbound>
<outbound>
<base />
</outbound>
</policies>

Elementos
rewrite-uri Elemento raíz. Sí
Atributos
template La dirección URL del servicio Sí N/D

web real con cualquier
parámetro de cadena de
consulta. Cuando se usan
expresiones, todo el valor
debe ser una expresión.
copy-unmatched-params Especifica si los parámetros Sin true

de consulta de la solicitud
entrante no presentes en la
plantilla de la dirección URL
original se agregan en la
dirección URL definida por la
plantilla de reescritura
Uso
Transformar XML mediante una XSLT

La directiva Transform XML using an XSLT aplica una transformación XSL al XML del cuerpo de la solicitud o la
respuesta.
<xsl-transform>
<parameter name="User-Agent">@(context.Request.Headers.GetValueOrDefault("User-Agent","non-specified"))
</parameter>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" />
<xsl:param name="User-Agent" />
<xsl:template match="* | @* | node()">
<xsl:copy>
<xsl:if test="self::* and not(parent::*)">
<xsl:attribute name="User-Agent">
<xsl:value-of select="$User-Agent" />
</xsl:attribute>
</xsl:if>
<xsl:apply-templates select="* | @* | node()" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
</xsl-transform>
Ejemplo
<policies>
<inbound>
<base />
</inbound>
<outbound>
<base />
<xsl-transform>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" method="xml" indent="yes" />

<xsl:template match="node()| @*|*">
<xsl:copy>
<xsl:apply-templates select="@* | node()|*" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
</xsl-transform>
</outbound>
</policies>
Elementos
xsl-transform Elemento raíz. Sí
Parámetro Permite definir las variables utilizadas en Sin

la transformación.
xsl:stylesheet Elemento raíz de la hoja de estilo. Todos Sí

los elementos y atributos definidos
dentro de él cumplen la especificación
XSLT estándar.
Uso
Pasos siguientes
Para obtener más información, consulte los temas siguientes:
Plantillas del portal para desarrolladores
Azure API Management le ofrece la posibilidad de personalizar el contenido de las páginas del portal para
desarrolladores mediante un conjunto de plantillas que configuran su contenido. Por medio de la sintaxis
DotLiquid y el editor que prefiera, como DotLiquid for Designers (DotLiquid para diseñadores), y un conjunto
proporcionado de recursos de cadena, recursos de glifo y controles de página localizados, puede disponer de una
gran flexibilidad para configurar el contenido de las páginas como considere oportuno mediante estas plantillas.
Para más información sobre cómo trabajar con plantillas, consulte Cómo personalizar el portal para
desarrolladores de API Management mediante plantillas.
Disponibilidad
IMPORTANT

API
API list
operación
Ejemplos de código
Curl
C#
Java
JavaScript
Objective C
PHP
Python
Ruby
Productos
Product list
Producto
Applications
Application list
Aplicación
Issues
Issue list
Perfil de usuario
Perfil
Subscriptions
Aplicaciones
Update account info
Pages
Sign in
Sign up
Page not found
Pasos siguientes
Referencia de plantilla
Data model reference
Controles de página
Template resources
Plantillas de API en Azure API Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de API en el portal para
desarrolladores.
API list
operación
Ejemplos de código
Curl
C#
Java
JavaScript
Objective C
PHP
Python
Ruby
NOTE
En la siguiente documentación se incluyen plantillas predeterminadas de ejemplo; sin embargo, están sujetas a cambios
debido a mejoras continuas. Puede ver las plantillas predeterminadas en vivo en el portal para desarrolladores; para ello, vaya
hasta a las plantillas individuales que desee. Para más información sobre cómo trabajar con plantillas, consulte Cómo
personalizar el portal para desarrolladores de API Management mediante plantillas.
Disponibilidad
IMPORTANT
API list
La plantilla API list le permite personalizar el cuerpo de la página de lista de API en el portal para desarrolladores.
Plantilla predeterminada
<div class="row">
<h2>{% localized "ApisStrings|PageTitleApis" %}</h2>
</div>
</div>
<div class="row">
{% if apis.size > 0 %}
<ol class="list-unstyled">
{% for api in apis %}
<li>
<h3>
<a href="/docs/services/{{api.id}}">{{api.name}}</a>
</h3>
{{api.description}}
</li>
{% endfor %}
</ol>
{% else %}
{% endif %}
</div>
</div>
Controles
La plantilla API list puede usar los siguientes controles de página.
paging-control
search-control
Modelo de datos
apis Colección de entidades de resumen de Las API visibles para el usuario actual.
API.
Ejemplo de datos de plantilla

{
"apis": [
{
"id": "570275f1b16653124c8f9ba3",
"name": "Basic Calculator",
"description": "Arithmetics is just a call away!"
},
{
"id": "57026e30de15d80041040001",
"name": "Echo API",
"description": null
}
],
"pageTitle": "APIs"
}
Operation
La plantilla Operation le permite personalizar el cuerpo de la página de operación en el portal para
desarrolladores.
<h2>{{api.name}}</h2>
<p>{{api.description }}</p>
<div class="panel">
<h3>{{operation.name}}</h3>
<p>{{operation.description }}</p>
<a class="btn btn-primary" href="{{consoleUrl}}" id="btnOpenConsole" role="button">
Try it
</a>
</div>
<h4>{% localized "Documentation|SectionHeadingRequestUrl" %}</h4>

<div class="panel">
<div class="panel-body">
<label>{{ sampleUrl | escape }}</label>
</div>
</div>
{% if operation.request %}
{% if operation.request.parameters.size > 0 %}
<h4>{% localized "Documentation|SectionHeadingRequestParameters" %}</h4>
<div class="panel">
{% for parameter in operation.request.parameters %}
<div class="row panel-body">
<label>{{parameter.name}}</label>
{% unless parameter.required %}
<span class="text-muted">({% localized "Documentation|FormLabelSubtextOptional"
%})</span>
{% endunless %}
</div>
{{parameter.typeName}}
</div>
{{parameter.description}}
</div>
</div>
{% endfor %}
</div>
{% endif %}
{% if operation.request.headers.size > 0 %}
<h4>{% localized "Documentation|SectionHeadingRequestHeaders" %}</h4>
<div class="panel">
{% for header in operation.request.headers %}
<div class="row panel-body">
<label>{{header.name}}</label>
{%unless header.required %}
<span class="text-muted">({% localized "Documentation|FormLabelSubtextOptional"
%})</span>
{% endunless %}
</div>
{{header.typeName}}
</div>
{{header.description}}
</div>
</div>
{% endfor %}
</div>
{% endif %}
{% if operation.request.description or operation.request.representations.size > 0 %}

<h4>{% localized "Documentation|SectionHeadingRequestBody" %}</h4>
<div class="panel">
{% if operation.request.description %}
<p>{{operation.request.description }}</p>
{% endif %}
{% if operation.request.representations.size > 0 %}
<div role="tabpanel">
<ul class="nav nav-tabs" role="tablist">
{% for representation in operation.request.representations %}
<li role="presentation" {% if forloop.first %}class="active"{% endif %}>
<a href="#requesttab{{forloop.index}}" role="tab" data-toggle="tab">
{{representation.contentType}}
</a>
</li>
{% endfor %}
</ul>
<div class="tab-content tab-content-boxed">
<div id="requesttab{{forloop.index}}" role="tabpanel" class="tab-pane snippet{% if
forloop.first %} active{% endif %}">
{% if representation.sample or representation.schema %}
{% if representation.sample and representation.schema %}
<ul class="nav nav-tabs-borderless" role="tablist">
<li role="presentation" class="active">
<a href="#requesttab{{forloop.index}}sample" role="tab" data-
toggle="tab">Sample</a>
</li>
<li role="presentation">
<a href="#requesttab{{forloop.index}}schema" role="tab" data-
toggle="tab">Schema</a>
</li>
</ul>
{% endif %}
<div class="tab-content">
{% if representation.sample %}
<div id="requesttab{{forloop.index}}sample" role="tabpanel"
class="tab-pane snippet active">
<pre><code class="{{representation.Brush}}">{{
representation.sample | escape }}</code></pre>
</div>
{% endif %}
{% if representation.schema %}
<div id="requesttab{{forloop.index}}schema" role="tabpanel"
class="tab-pane snippet">
representation.schema | escape }}</code></pre>
</div>
{% endif %}
</div>
</div>
{% endif %}
</div>
{% endfor %}
</div>
</div>
{% endif %}
<div class="clearfix"></div>
</div>
{% endif %}
{% endif %}
{% if operation.responses.size > 0 %}
{% for response in operation.responses %}
{% if response.description or response.representations.size > 0 %}
<h4>{% localized "Documentation|SectionHeadingResponse" %} {{response.statusCode}}</h4>
<div class="panel">
{% if response.description %}
<p>{{ response.description }}</p>
{% endif %}
{% if response.representations.size > 0 %}
{% for representation in response.representations %}
<a href="#response{{response.statusCode}}tab{{forloop.index}}" role="tab"
data-toggle="tab">
{{representation.contentType}}
</a>
</li>
{% endfor %}
</ul>
<div class="tab-content tab-content-boxed">
{% for representation in response.representations %}
<div id="response{{response.statusCode}}tab{{forloop.index}}" role="tabpanel"
class="tab-pane snippet{% if forloop.first %} active{% endif %}">
{% if representation.sample or representation.schema %}
{% if representation.sample and representation.schema %}

<ul class="nav nav-tabs-borderless" role="tablist">
<li role="presentation" class="active">
<a
href="#response{{response.statusCode}}tab{{forloop.index}}sample" role="tab" data-toggle="tab">
Sample
</a>
</li>
<li role="presentation">
<a
href="#response{{response.statusCode}}tab{{forloop.index}}schema" role="tab" data-toggle="tab">
Schema
</a>
</li>
</ul>
{% endif %}
<div class="tab-content">
{% if representation.sample %}
<div
id="response{{response.statusCode}}tab{{forloop.index}}sample" role="tabpanel" class="tab-pane snippet
active">
representation.sample | escape }}</code></pre>
</div>
{% endif %}
{% if representation.schema %}
<div
id="response{{response.statusCode}}tab{{forloop.index}}schema" role="tabpanel" class="tab-pane snippet">
representation.schema | escape }}</code></pre>
</div>
{% endif %}
</div>
</div>
{% endif %}
</div>
{% endfor %}
</div>
</div>
{% endif %}
</div>
{% endif %}
{% endfor %}
{% endif %}
<h4>{% localized "Documentation|SectionHeadingCodeSamples" %}</h4>

<h4>{% localized "Documentation|SectionHeadingCodeSamples" %}</h4>
{% for sample in samples %}
<a href="#{{sample.brush}}" aria-controls="{{sample.brush}}" role="tab" data-toggle="tab">
{{sample.title}}
</a>
</li>
{% endfor %}
</ul>
<div class="tab-content tab-content-boxed" title="{% localized
"Documentation|TooltipTextDoubleClickToSelectAll=""" %}">
{% for sample in samples %}
<div role="tabpanel" class="tab-pane tab-content-boxed {% if forloop.first %} active{% endif %}
snippet snippet-resizable" id="{{sample.brush}}" >
<pre><code class="{{sample.brush}}">{% partial sample.template for sample in samples %}</code>
</pre>
</div>
{% endfor %}
</div>
</div>
Controles
La plantilla Operation no permite el uso de ningún control de página.
Modelo de datos
apiId string Identificador de la API actual.
apiName string Nombre de la API.
apiDescription string Descripción de la API.
api Entidad API summary. API actual.
operation operación La operación mostrada actualmente.
sampleUrl string La dirección URL de la operación actual.
operationMenu Operation menu Un menú de operaciones de esta API.
consoleUrl URI El URI del botón Pruébelo.
samples Colección de entidades de código de Los ejemplos de código de la operación

ejemplo. actual...
{
"apiId": "570275f1b16653124c8f9ba3",
"apiName": "Basic Calculator",
"apiDescription": "Arithmetics is just a call away!",
"api": {
"id": "570275f1b16653124c8f9ba3",
"name": "Basic Calculator",
"description": "Arithmetics is just a call away!"
},
"operation": {
"id": "570275f2b1665305c811cf49",
"name": "Add two integers",
"description": "Produces a sum of two numbers.",
"scheme": "https",
"uriTemplate": "calc/add?a={a}&b={b}",
"host": "sdcontoso5.azure-api.net",
"httpMethod": "GET",
"request": {
"description": null,
"headers": [
{
"name": "Ocp-Apim-Subscription-Key",
"description": "Subscription key which provides access to this API. Found in your <a
href='/developer'>Profile</a>.",
"value": "{subscription key}",
"typeName": "string",
"options": null,
"required": true,
"readonly": false
}
],
"parameters": [
{
"name": "a",
"description": "First operand. Default value is <code>51</code>.",
"value": "51",
"options": [
"51"
],
"required": true,
"kind": 1,
"typeName": null
},
{
"name": "b",
"description": "Second operand. Default value is <code>49</code>.",
"value": "49",
"options": [
"49"
],
"required": true,
"kind": 1,
"typeName": null
}
],
"representations": []
},
"responses": []
},
"sampleUrl": "https://sdcontoso5.azure-api.net/calc/add?a={a}&b={b}",
"operationMenu": {
"ApiId": "570275f1b16653124c8f9ba3",
"CurrentOperationId": "570275f2b1665305c811cf49",
"Action": "Operation",
"MenuItems": [
{
"Id": "570275f2b1665305c811cf49",
"Title": "Add two integers",
"HttpMethod": "GET"
},
{
"Id": "570275f2b1665305c811cf4c",
"Title": "Divide two integers",
"HttpMethod": "GET"
},
{
"Id": "570275f2b1665305c811cf4b",
"Id": "570275f2b1665305c811cf4b",
"Title": "Multiply two integers",
"HttpMethod": "GET"
},
{
"Id": "570275f2b1665305c811cf4a",
"Title": "Subtract two integers",
"HttpMethod": "GET"
}
]
},
"consoleUrl": "/docs/services/570275f1b16653124c8f9ba3/operations/570275f2b1665305c811cf49/console",
"samples": [
{
"title": "Curl",
"snippet": null,
"brush": "plain",
"template": "DocumentationSamplesCurl",
"body": "{body}",
"method": "GET",
"scheme": "https",
"path": "/calc/add?a={a}&b={b}",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "C#",
"snippet": null,
"brush": "csharp",
"template": "DocumentationSamplesCsharp",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "Java",
"snippet": null,
"brush": "java",
"template": "DocumentationSamplesJava",
"body": "{body}",
"method": "GET",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "JavaScript",
"snippet": null,
"brush": "xml",
"template": "DocumentationSamplesJs",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "ObjC",
"snippet": null,
"brush": "objc",
"template": "DocumentationSamplesObjc",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
{
"title": "PHP",
"snippet": null,
"brush": "php",
"template": "DocumentationSamplesPhp",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "Python",
"snippet": null,
"brush": "python",
"template": "DocumentationSamplesPython",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
},
{
"title": "Ruby",
"snippet": null,
"brush": "ruby",
"template": "DocumentationSamplesRuby",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"required": true,
"readonly": false
}
],
"parameters": []
}
]
}
Ejemplos de código
Las siguientes plantillas le permiten personalizar el cuerpo de los ejemplos de código individuales en la página de
operación.
Curl
C#
Java
JavaScript
Objective C
PHP
Python
Ruby
Curl
La plantilla DocumentationSamplesCurl le permite personalizar ese ejemplo de código en la sección de
ejemplos de código de la página de operación.
@ECHO OFF
curl -v -X {{method}} "{{scheme}}://{{host}}{{path}}{{query | escape }}"

{% for header in headers -%}
-H "{{ header.name }}: {{ header.value }}"
{% endfor -%}
{% if body -%}
--data-ascii "{{ body | replace:'"','^"' }}"
{% endif -%}
Controles
Las plantillas de ejemplo de código no permiten el uso de ningún control de página.
Modelo de datos
Entidad Code sample.
{
"title": "Curl",
"snippet": null,
"brush": "plain",
"template": "DocumentationSamplesCurl",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
C#
La plantilla DocumentationSamplesCsharp le permite personalizar ese ejemplo de código en la sección de
using System;
using System.Net.Http.Headers;
using System.Text;
using System.Net.Http;
using System.Web;
namespace CSHttpClientSample
{
static class Program
{
static void Main()
{
MakeRequest();
Console.WriteLine("Hit ENTER to exit...");
Console.ReadLine();
}
static async void MakeRequest()

{
var client = new HttpClient();
var queryString = HttpUtility.ParseQueryString(string.Empty);
{% if headers.size > 0 -%}

// Request headers
{% case header.Name -%}
{% when "Accept"%}
client.DefaultRequestHeaders.Accept.Add(MediaTypeWithQualityHeaderValue.Parse("
{{header.value}}"));
{% when "Accept-Charset" -%}
client.DefaultRequestHeaders.AcceptCharset.Add(StringWithQualityHeaderValue.Parse("
{% when "Accept-Encoding" -%}
client.DefaultRequestHeaders.AcceptEncoding.Add(StringWithQualityHeaderValue.Parse("
{% when "Accept-Language" -%}
client.DefaultRequestHeaders.AcceptLanguage.Add(StringWithQualityHeaderValue.Parse("
{% when "Cache-Control" -%}
client.DefaultRequestHeaders.CacheControl = CacheControlHeaderValue.Parse("{{header.value}}");
{% when "Connection" -%}
client.DefaultRequestHeaders.Connection.Add("{{header.value}}");
{% when "Date" -%}
client.DefaultRequestHeaders.Date = DateTimeOffset.Parse("{{header.value}}");
{% when "Expect" -%}
client.DefaultRequestHeaders.Expect.Add(NameValueWithParametersHeaderValue.Parse("
{% when "If-Match" -%}
client.DefaultRequestHeaders.IfMatch.Add(EntityTagHeaderValue.Parse("{{header.value}}"));
{% when "If-Modified-Since" -%}
client.DefaultRequestHeaders.IfModifiedSince = DateTimeOffset.Parse("{{header.value}}");
{% when "If-None-Match" -%}
client.DefaultRequestHeaders.IfNoneMatch.Add(EntityTagHeaderValue.Parse("{{header.value}}"));
{% when "If-Range" -%}
client.DefaultRequestHeaders.IfRange = RangeConditionHeaderValue.Parse("{{header.value}}");
{% when "If-Unmodified-Since" -%}
client.DefaultRequestHeaders.IfUnmodifiedSince = DateTimeOffset.Parse("{{header.value}}");
{% when "Max-Forwards" -%}
client.DefaultRequestHeaders.MaxForwards = int.Parse("{{header.value}}");
{% when "Pragma" -%}
client.DefaultRequestHeaders.Pragma.Add(NameValueHeaderValue.Parse("{{header.value}}"));
{% when "Range" -%}
client.DefaultRequestHeaders.Range = RangeHeaderValue.Parse("{{header.value}}");
{% when "Referer" -%}
client.DefaultRequestHeaders.Referrer = new Uri("{{header.value}}");
{% when "TE" -%}
client.DefaultRequestHeaders.TE.Add(TransferCodingWithQualityHeaderValue.Parse("
{% when "Transfer-Encoding" -%}
client.DefaultRequestHeaders.TransferEncoding.Add(TransferCodingHeaderValue.Parse("
{% when "Upgrade" -%}
client.DefaultRequestHeaders.Upgrade.Add(ProductHeaderValue.Parse("{{header.value}}"));
{% when "User-Agent" -%}
client.DefaultRequestHeaders.UserAgent.Add(ProductInfoHeaderValue.Parse("{{header.value}}"));
{% when "Via" -%}
client.DefaultRequestHeaders.Via.Add(ViaHeaderValue.Parse("{{header.value}}"));
{% when "Warning" -%}
client.DefaultRequestHeaders.Warning.Add(WarningHeaderValue.Parse("{{header.value}}"));
{% when "Content-Type" -%}
{% else -%}
client.DefaultRequestHeaders.Add("{{header.Name}}", "{{header.value}}");
client.DefaultRequestHeaders.Add("{{header.Name}}", "{{header.value}}");
{% endcase -%}
{% endfor -%}
{% endif -%}
{% if parameters.size > 0 -%}

// Request parameters
{% for parameter in parameters -%}
queryString["{{parameter.Name}}"] = "{{parameter.Value}}";
{% endfor -%}
{% endif -%}
var uri = "{{scheme}}://{{host}}{{path}}{% if path contains '?' %}&{% else %}?{% endif %}" +
queryString;
{% case method -%}
{% when "POST" -%}

HttpResponseMessage response;
// Request body
byte[] byteData = Encoding.UTF8.GetBytes("{{ body | replace:'"','\"'}}");
using (var content = new ByteArrayContent(byteData))

{
{% if body -%}
content.Headers.ContentType = new MediaTypeHeaderValue("< your content type, i.e.
application/json >");
{% endif -%}
response = await client.PostAsync(uri, content);
}
{% when "GET" -%}

var response = await client.GetAsync(uri);
{% when "DELETE" -%}
var response = await client.DeleteAsync(uri);
{% when "PUT" -%}
HttpResponseMessage response;
// Request body
byte[] byteData = Encoding.UTF8.GetBytes("{{ body | replace:'"','\"'}}");
using (var content = new ByteArrayContent(byteData))

{
{% if body -%}
content.Headers.ContentType = new MediaTypeHeaderValue("< your content type, i.e.
application/json >");
{% endif -%}
response = await client.PutAsync(uri, content);
}
{% when "HEAD" -%}
var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Head, uri));
{% when "OPTIONS" -%}
var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Options, uri));
{% when "TRACE" -%}
var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Trace, uri));
if (response.Content != null)
{
var responseString = await response.Content.ReadAsStringAsync();
Console.WriteLine(responseString);
}
{% endcase -%}
}
}
}
Controles
Modelo de datos
{
"title": "C#",
"snippet": null,
"brush": "csharp",
"template": "DocumentationSamplesCsharp",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
Java
La plantilla DocumentationSamplesJava le permite personalizar ese ejemplo de código en la sección de
// // This sample uses the Apache HTTP client from HTTP Components (http://hc.apache.org/httpcomponents-
client-ga/)
import java.net.URI;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.client.HttpClient;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;
public class JavaSample

{
public static void main(String[] args)
{
HttpClient httpclient = HttpClients.createDefault();
try
{
URIBuilder builder = new URIBuilder("{{scheme}}://{{host}}{{path}}");

builder.setParameter("{{parameter.name}}", "{{parameter.value}}");
{% endfor -%}
{% endif -%}
URI uri = builder.build();

Http{{ method | downcase | capitalize }} request = new Http{{ method | downcase | capitalize }}
(uri);
request.setHeader("{{header.Name}}", "{{header.value}}");
{% endfor %}
{% if body -%}
// Request body
StringEntity reqEntity = new StringEntity("{{ body | replace:'"','\"' }}");
request.setEntity(reqEntity);
{% endif -%}
HttpResponse response = httpclient.execute(request);

HttpEntity entity = response.getEntity();
if (entity != null)
{
System.out.println(EntityUtils.toString(entity));
}
}
catch (Exception e)
{
System.out.println(e.getMessage());
}
}
}
Controles
Modelo de datos
{
"title": "Java",
"snippet": null,
"brush": "java",
"template": "DocumentationSamplesJava",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
JavaScript
La plantilla DocumentationSamplesJs le permite personalizar ese ejemplo de código en la sección de ejemplos
de código de la página de operación.
<!DOCTYPE html>
<html>
<head>
<title>JSSample</title>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
</head>
<body>
<script type="text/javascript">
$(function() {
var params = {
"{{parameter.name}}": "{{parameter.value}}",
{% endfor -%}
{% endif -%}
};
$.ajax({
url: "{{scheme}}://{{host}}{{path}}{% if path contains '?' %}&{% else %}?{% endif %}" +
$.param(params),
beforeSend: function(xhrObj){
// Request headers
xhrObj.setRequestHeader("{{header.name}}","{{header.value}}");
{% endfor -%}
},
{% endif -%}
type: "{{method}}",
{% if body -%}
// Request body
data: "{{ body | replace:'"','\"' }}",
{% endif -%}
})
.done(function(data) {
alert("success");
})
.fail(function() {
alert("error");
});
});
</script>
</body>
</html>
Controles
Modelo de datos
{
"title": "JavaScript",
"snippet": null,
"brush": "xml",
"template": "DocumentationSamplesJs",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
Objective C
La plantilla DocumentationSamplesObjc le permite personalizar ese ejemplo de código en la sección de
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[])

{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString* path = @"{{scheme}}://{{host}}{{path}}";

NSArray* array = @[
@"entities=true",
@"{{parameter.name}}={{parameter.value}}",
{% endfor -%}
{% endif -%}
];
NSString* string = [array componentsJoinedByString:@"&"];

path = [path stringByAppendingFormat:@"?%@", string];
NSLog(@"%@", path);
NSMutableURLRequest* _request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:path]];

[_request setHTTPMethod:@"{{method}}"];
// Request headers
[_request setValue:@"{{header.value}}" forHTTPHeaderField:@"{{header.name}}"];
{% endfor -%}
{% endif -%}
{% if body -%}
// Request body
[_request setHTTPBody:[@"{{ body | replace:'"','\"' }}" dataUsingEncoding:NSUTF8StringEncoding]];
{% endif -%}
{% endif -%}
NSURLResponse *response = nil;

NSError *error = nil;
NSData* _connectionData = [NSURLConnection sendSynchronousRequest:_request returningResponse:&response
error:&error];
if (nil != error)
{
NSLog(@"Error: %@", error);
}
else
{
NSError* error = nil;
NSMutableDictionary* json = nil;
NSString* dataString = [[NSString alloc] initWithData:_connectionData encoding:NSUTF8StringEncoding];
NSLog(@"%@", dataString);
if (nil != _connectionData)
{
json = [NSJSONSerialization JSONObjectWithData:_connectionData
options:NSJSONReadingMutableContainers error:&error];
}
if (error || !json)
{
NSLog(@"Could not parse loaded json with error:%@", error);
}
NSLog(@"%@", json);
_connectionData = nil;
}
[pool drain];
return 0;
}
Controles
Modelo de datos
{
"title": "ObjC",
"snippet": null,
"brush": "objc",
"template": "DocumentationSamplesObjc",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
PHP
La plantilla DocumentationSamplesPhp le permite personalizar ese ejemplo de código en la sección de
<?php
// This sample uses the HTTP_Request2 PHP library (https://github.com/pear/HTTP_Request2)
require_once 'HTTP/Request2.php';
$request = new Http_Request2('{{scheme}}://{{host}}{{path}}');

$url = $request->getUrl();

$headers = array(
// Request headers
'{{header.name}}' => '{{header.value}}',
{% endfor -%}
);
$request->setHeader($headers);
{% endif -%}

$parameters = array(
'{{parameter.name}}' => '{{parameter.value}}',
{% endfor -%}
);
$url->setQueryVariables($parameters);
{% endif -%}
$request->setMethod(HTTP_Request2::METHOD_{{method}});
{% if body -%}
// Request body
$request->setBody("{{ body | replace:'"','\"' }}");
{% endif -%}
try
{
$response = $request->send();
echo $response->getBody();
}
catch (HttpException $ex)
{
echo $ex;
}
?>
Controles
Modelo de datos
{
"title": "PHP",
"snippet": null,
"brush": "php",
"template": "DocumentationSamplesPhp",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
Python
La plantilla DocumentationSamplesPython le permite personalizar ese ejemplo de código en la sección de
########### Python 2.7 #############

import httplib, urllib, base64
headers = {
# Request headers
'{{header.name}}': '{{header.value}}',
{% endfor -%}
{% endif -%}
}
params = urllib.urlencode({
# Request parameters
'{{parameter.name}}': '{{parameter.value}}',
{% endfor -%}
{% endif -%}
})
try:
{% case scheme -%}
{% when "http" -%}
conn = httplib.HTTPConnection('{{host}}')
{% when "https" -%}
conn = httplib.HTTPSConnection('{{host}}')
{% endcase -%}
conn.request("{{method}}", "{{path}}{% if path contains '?' %}&{% else %}?{% endif %}%s" % params{% if
body %}, "{{ body | replace:'"','\"' }}"{% endif %}, headers)
response = conn.getresponse()
data = response.read()
print(data)
conn.close()
conn.close()
except Exception as e:
print("[Errno {0}] {1}".format(e.errno, e.strerror))
####################################
########### Python 3.2 #############

import http.client, urllib.request, urllib.parse, urllib.error, base64
headers = {
# Request headers
'{{header.name}}': '{{header.value}}',
{% endfor -%}
{% endif -%}
}
params = urllib.parse.urlencode({
'{{parameter.name}}': '{{parameter.value}}',
{% endfor -%}
{% endif -%}
})
try:
{% case scheme -%}
{% when "http" -%}
conn = http.client.HTTPConnection('{{host}}')
{% when "https" -%}
conn = http.client.HTTPSConnection('{{host}}')
{% endcase -%}
conn.request("{{method}}", "{{path}}{% if path contains '?' %}&{% else %}?{% endif %}%s" % params{% if
body %}, "{{ body | replace:'"','\"' }}"{% endif %}, headers)
response = conn.getresponse()
data = response.read()
print(data)
conn.close()
except Exception as e:
print("[Errno {0}] {1}".format(e.errno, e.strerror))
####################################
Controles
Modelo de datos
{
"title": "Python",
"snippet": null,
"brush": "python",
"template": "DocumentationSamplesPython",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
Ruby
La plantilla DocumentationSamplesRuby le permite personalizar ese ejemplo de código en la sección de
require 'net/http'
uri = URI('{{scheme}}://{{host}}{{path}}')
uri.query = URI.encode_www_form({
'{{parameter.name}}' => '{{parameter.value}}'{% unless forloop.last %},{% endunless %}
{% endfor -%}
{% endif -%}
})
request = Net::HTTP::{{ method | downcase | capitalize }}.new(uri.request_uri)

# Request headers
request['{{header.name}}'] = '{{header.value}}'
{% endfor -%}
{% if body -%}
# Request body
request.body = "{{ body | replace:'"','\"' }}"
{% endif -%}
response = Net::HTTP.start(uri.host, uri.port, :use_ssl => uri.scheme == 'https') do |http|

http.request(request)
end
puts response.body
Controles
Modelo de datos
{
"title": "Ruby",
"snippet": null,
"brush": "ruby",
"template": "DocumentationSamplesRuby",
"body": "{body}",
"method": "GET",
"scheme": "https",
"query": "",
"headers": [
{
"options": null,
"required": true,
"readonly": false
}
],
"parameters": []
}
Pasos siguientes
Plantillas de producto en Azure API Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de producto en el portal para
desarrolladores.
Product list
Producto
NOTE
Disponibilidad
IMPORTANT
Product list
La plantilla Product list le permite personalizar el cuerpo de la página de lista de productos en el portal para
desarrolladores.
<div class="row">
</div>
</div>
<div class="row">
{% if products.size > 0 %}
{% for product in products %}
<li>
<h3><a href="/products/{{product.id}}">{{product.title}}</a></h3>
{{product.description}}
</li>
{% endfor %}
</ul>
{% else %}
{% endif %}
</div>
</div>
Controles
La plantilla Product list puede usar los siguientes controles de página.
paging-control
search-control
Modelo de datos
Paginación Entidad Paging. La información de paginación de la

colección de productos.
Filtros Entidad Filtering. La información de filtrado de la página

de lista de productos.
Productos Colección de entidades de producto. Los productos visibles para el usuario

actual.

{
"Paging": {
"Page": 1,
"PageSize": 10,
"ShowAll": false,
"PageCount": 1
},
"Filtering": {
"Pattern": null,
"Placeholder": "Search products"
},
"Products": [
{
"Id": "56f9445ffaf7560049060001",
"Title": "Starter",
"Description": "Subscribers will be able to run 5 calls/minute up to a maximum of 100
calls/week.",
"Terms": "",
"ProductState": 1,
},
{
"Id": "56f9445ffaf7560049060002",
"Title": "Unlimited",
"Description": "Subscribers have completely unlimited access to the API. Administrator approval is
required.",
"Terms": null,
"ProductState": 1,
}
]
}
Product
La plantilla Product list le permite personalizar el cuerpo de la página de producto en el portal para
desarrolladores.
<h2>{{Product.Title}}</h2>
<p>{{Product.Description}}</p>
{% assign replaceString0 = '{0}' %}

{% if Limits and Limits.size > 0 %}

<h3>{% localized "ProductDetailsStrings|WebProductsUsageLimitsHeader"%}</h3>
<ul>
{% for limit in Limits %}
<li>{{limit.DisplayName}}</li>
{% endfor %}
</ul>
{% endif %}
{% if apis.size > 0 %}
<p>
<b>
{% if apis.size == 1 %}
{% capture apisCountText %}{% localized "ProductDetailsStrings|TextblockSingleApisCount" %}{% endcapture
%}
{% else %}
{% capture apisCountText %}{% localized "ProductDetailsStrings|TextblockMultipleApisCount" %}{% endcapture
%}
{% endif %}
{% capture apisCount %}{{apis.size}}{% endcapture %}

{{ apisCountText | replace : replaceString0, apisCount }}
</b>
</p>
<ul>
{% for api in Apis %}
<li>
<a href="/docs/services/{{api.Id}}">{{api.Name}}</a>
</li>
{% endfor %}
</ul>
{% endif %}
{% if subscriptions.size > 0 %}
<p>
<b>
{% if subscriptions.size == 1 %}
{% capture subscriptionsCountText %}{% localized "ProductDetailsStrings|TextblockSingleSubscriptionsCount"
%}{% endcapture %}
{% else %}
{% capture subscriptionsCountText %}{% localized
"ProductDetailsStrings|TextblockMultipleSubscriptionsCount" %}{% endcapture %}
{% endif %}
{% capture subscriptionsCount %}{{subscriptions.size}}{% endcapture %}

{{ subscriptionsCountText | replace : replaceString0, subscriptionsCount }}
</b>
</p>
<ul>
{% for subscription in subscriptions %}
<li>
<a href="/developer#{{subscription.Id}}">{{subscription.DisplayName}}</a>
</li>
{% endfor %}
</ul>
{% endif %}
{% if CannotAddBecauseSubscriptionNumberLimitReached %}
<b>{% localized "ProductDetailsStrings|TextblockSubscriptionLimitReached" %}</b>
{% elsif CannotAddBecauseMultipleSubscriptionsNotAllowed == false %}
<subscribe-button></subscribe-button>
{% endif %}
Controles
subscribe-button
Modelo de datos
Producto Producto El producto especificado.
IsDeveloperSubscribed boolean Si el usuario actual está suscrito a este

producto.
SubscriptionState número El estado de la suscripción. Los estados

posibles son:
- 0 - suspended : la suscripción está

bloqueada y el suscriptor no puede
llamar a ninguna API del producto.
- 1 - active : la suscripción está
activa.
- 2 - expired : la suscripción ha
alcanzado su fecha de expiración y se ha
desactivado.
- 3 - submitted : el desarrollador ha
realizado una solicitud de suscripción,
pero esta aún no se ha aprobado ni
rechazado.
- 4 - rejected : un administrador ha
rechazado la solicitud de suscripción.
- 5 - cancelled : el desarrollador o el
administrador han cancelado la
suscripción.
límites array Esta propiedad está en desuso y no

debe utilizarse.
DelegatedSubscriptionEnabled boolean Si la delegación está habilitada para esta

suscripción.
DelegatedSubscriptionUrl string Si la delegación está habilitada, la

dirección URL de la suscripción
delegada.
IsAgreed boolean Si el producto tiene términos, si el

usuario actual ha aceptado los términos.
Suscripciones Colección de entidades de resumen de Las suscripciones al producto.

suscripción.
Apis Colección de entidades de API. Las API de este producto.
CannotAddBecauseSubscriptionNumber boolean Si el usuario actual es apto para

LimitReached suscribirse a este producto en relación
con el límite de suscripción.
CannotAddBecauseMultipleSubscription boolean Si el usuario actual es apto para

sNotAllowed suscribirse a este producto en relación
con que se permitan o no varias
suscripciones.
{
"Product": {
"Id": "56f9445ffaf7560049060001",
"Title": "Starter",
"Description": "Subscribers will be able to run 5 calls/minute up to a maximum of 100 calls/week.",
"Terms": "",
"ProductState": 1,
},
"IsDeveloperSubscribed": true,
"SubscriptionState": 1,
"Limits": [],
"DelegatedSubscriptionEnabled": false,
"DelegatedSubscriptionUrl": null,
"IsAgreed": false,
"Subscriptions": [
{
"Id": "56f9445ffaf7560049070001",
"DisplayName": "Starter (default)"
}
],
"Apis": [
{
"id": "56f9445ffaf7560049040001",
"name": "Echo API",
"description": null,
"serviceUrl": "http://echoapi.cloudapp.net/api",
"path": "echo",
"protocols": [
2
],
"authenticationSettings": null,
"subscriptionKeyParameterNames": null
}
],
"CannotAddBecauseSubscriptionNumberLimitReached": false,
"CannotAddBecauseMultipleSubscriptionsNotAllowed": true
}
Pasos siguientes
Plantillas de aplicación en Azure API Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de Application en el portal para
desarrolladores.
Application list
Aplicación
NOTE
Disponibilidad
IMPORTANT
Application list
La plantilla Application list le permite personalizar el cuerpo de la página de lista de aplicaciones en el portal
<div class="row">
<h2>{% localized "AppStrings|WebApplicationsHeader" %}</h2>
</div>
</div>
<div class="row">
{% if applications.size > 0 %}
{% for app in applications %}
<li>
{% if app.application.icon.url != "" %}
<aside>
<a href="/applications/details/{{app.application.id}}"><img src="
{{app.application.icon.url}}" alt="App Icon" /></a>
</aside>
{% endif %}
<h3><a href="/applications/details/{{app.application.id}}">{{app.application.title}}</a></h3>
{{app.application.description}}
</li>
{% endfor %}
</ul>
{% else %}
{% endif %}
</div>
</div>
Controles
paging-control
Modelo de datos
Paging Entidad Paging. La información de paginación de la

colección de aplicaciones.
Applications Colección de entidades de aplicación. Las aplicaciones visibles para el usuario

actual.
CategoryName string La categoría de aplicación.

{
"Paging": {
"Page": 1,
"PageSize": 10,
"ShowAll": false,
"PageCount": 1
},
"Applications": [
{
"Application": {
"Id": "5702b96fb16653124c8f9ba8",
"Title": "Contoso Calculator",
"Description": "A simple online calculator.",
"Url": null,
"Version": null,
"Requirements": "Free application with no requirements.",
"State": 2,
"RegistrationDate": "2016-04-04T18:59:00",
"CategoryId": 5,
"DeveloperId": "5702b5b0b16653124c8f9ba4",
"Attachments": [
{
"UniqueId": "a58af001-e6c3-45fd-8bc9-c60a1875c3f6",
"Url":
"https://apimgmtst65gdjvjrgdbfhr4.blob.core.windows.net/content/applications/a58af001-e6c3-45fd-8bc9-
c60a1875c3f6.png",
"Type": "Icon",
"ContentType": "image/png"
},
{
"UniqueId": "2b4fa5dd-00ff-4a8f-b1b7-51e715849ede",
"Url":
"https://apimgmtst65gdjvjrgdbfhr4.blob.core.windows.net/content/applications/2b4fa5dd-00ff-4a8f-b1b7-
51e715849ede.png",
"Type": "Screenshot",
}
],
"Icon": {
"Url":
"https://apimgmtst65gdjvjrgdbfhr4.blob.core.windows.net/content/applications/a58af001-e6c3-45fd-8bc9-
c60a1875c3f6.png",
"Type": "Icon",
}
},
"CategoryName": "Finance"
}
]
}
Application
La plantilla Application le permite personalizar el cuerpo de la página de aplicación en el portal para
desarrolladores.
<h2>{{title}}</h2>
{% if icon.url != "" %}
<aside class="applications_aside">
<div class="image-placeholder">
<img src="{{icon.url}}" alt="Application Icon" />
</div>
</aside>
{% endif %}
<article>
{% if url != "" %}
<a target="_blank" href="{{url}}">{{url}}</a>
{% endif %}
<p>{{description}}</p>
{% if requirements != null %}
<h3>{% localized "AppDetailsStrings|WebApplicationsRequirementsHeader" %}</h3>
<p>{{requirements}}</p>
{% endif %}
{% if attachments.size > 0 %}
<h3>{% localized "AppDetailsStrings|WebApplicationsScreenshotsHeader" %}</h3>
{% for screenshot in attachments %}
{% if screenshot.type != "Icon" %}
<a href="{{screenshot.url}}" data-lightbox="example-set">
<img src="/Developer/Applications/Thumbnail?url={{screenshot.url}}" alt='{% localized
"AppDetailsStrings|WebApplicationsScreenshotAlt" %}' />
</a>
{% endif %}
{% endfor %}
{% endif %}
</article>
Controles
La plantilla Application no permite el uso de ningún control de página.
Modelo de datos
Entidad Application.
{
"Id": "5702b96fb16653124c8f9ba8",
"Title": "Contoso Calculator",
"Description": "A simple online calculator.",
"Url": null,
"Version": null,
"Requirements": "Free application with no requirements.",
"State": 2,
"RegistrationDate": "2016-04-04T18:59:00",
"CategoryId": 5,
"DeveloperId": "5702b5b0b16653124c8f9ba4",
"Attachments": [
{
"Url": "https://apimgmtst3aybshdqqcqrle4.blob.core.windows.net/content/applications/a58af001-e6c3-
45fd-8bc9-c60a1875c3f6.png",
"Type": "Icon",
},
{
"UniqueId": "2b4fa5dd-00ff-4a8f-b1b7-51e715849ede",
"Url": "https://apimgmtst3aybshdqqcqrle4.blob.core.windows.net/content/applications/2b4fa5dd-00ff-
4a8f-b1b7-51e715849ede.png",
"Type": "Screenshot",
}
],
"Icon": {
"Url": "https://apimgmtst3aybshdqqcqrle4.blob.core.windows.net/content/applications/a58af001-e6c3-
45fd-8bc9-c60a1875c3f6.png",
"Type": "Icon",
}
}
Pasos siguientes
Plantillas de problema en Azure API Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de problema en el portal para
desarrolladores.
Issue list
NOTE
Disponibilidad
IMPORTANT
Issue list
La plantilla Issue list le permite personalizar el cuerpo de la página de lista de problemas en el portal para
desarrolladores.
<div class="row">
<h2>{% localized "IssuesStrings|WebIssuesIndexTitle" %}</h2>
</div>
</div>
<div class="row">
{% if issues.size > 0 %}
{% capture reportedBy %}{% localized "IssuesStrings|WebIssuesStatusReportedBy" %}{% endcapture %}
{% for issue in issues %}
<li>
<h3>
<a href="/issues/{{issue.id}}">{{issue.title}}</a>
</h3>
<p>{{issue.description}}</p>
<em>
{% capture state %}{{issue.issueState}}{% endcapture %}
{% capture devName %}{{issue.subscriptionDeveloperName}}{% endcapture %}
{% capture str1 %}{{ reportedBy | replace : replaceString0, state }}{% endcapture %}
{{ str1 | replace : replaceString1, devName }}
<span class="UtcDateElement">{{ issue.reportedOn | date: "r" }}</span>
</em>
</li>
{% endfor %}
</ul>
{% else %}
{% endif %}
{% if canReportIssue %}
<a class="btn btn-primary" id="createIssue" href="/Issues/Create">{% localized
"IssuesStrings|WebIssuesReportIssueButton" %}</a>
{% elsif isAuthenticated %}
<hr />
<p>{% localized "IssuesStrings|WebIssuesNoActiveSubscriptions" %}</p>
{% else %}
<hr />
<p>
{% capture signIntext %}{% localized "IssuesStrings|WebIssuesNotSignin" %}{% endcapture %}
{% capture link %}<a href="/signin">{% localized "IssuesStrings|WebIssuesSignIn" %}</a>{% endcapture %}
{{ signIntext | replace : replaceString0, link }}
</p>
{% endif %}
</div>
</div>
Controles
La plantilla Issue list puede usar los siguientes controles de página.
paging-control
Modelo de datos
Issues Colección de entidades de problema. Los problemas visibles para el usuario

actual.
Paging Entidad Paging. La información de paginación de la

colección de aplicaciones.
IsAuthenticated boolean Si el usuario actual ha iniciado sesión en

CanReportIssues boolean Si el usuario actual tiene permisos para

registrar un problema.
Search string Esta propiedad está en desuso y no

debe utilizarse.
{
"Issues": [
{
"Id": "5702b68bb16653124c8f9ba7",
"ApiId": "570275f1b16653124c8f9ba3",
"Title": "I couldn't figure out how to connect my application to the API",
"Description": "I'm having trouble connecting my application to the backend API.",
"SubscriptionDeveloperName": "Clayton",
"IssueState": "Proposed",
"ReportedOn": "2016-04-04T18:46:35.64",
"Comments": null,
"Attachments": null,
"Services": null
}
],
"Paging": {
"Page": 1,
"PageSize": 10,
"ShowAll": false,
"PageCount": 1
},
"IsAuthenticated": true,
"CanReportIssue": true,
"Search": null
}
Pasos siguientes
Plantillas de perfil de usuario en Azure API
Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de perfil de usuario en el portal
Perfil
Subscriptions
Aplicaciones
Update account info
NOTE
Disponibilidad
IMPORTANT
Perfil
La plantilla de perfil le permite personalizar la sección de perfil de usuario de la página de perfil de usuario en el
portal para desarrolladores.
<div class="pull-right">
{% if canChangePassword == true %}
<a class="btn btn-default" id="ChangePassword" role="button" href="{{changePasswordUrl}}">{% localized
"UserProfile|ButtonLabelChangePassword" %}</a>
{% endif %}
<a id="changeAccountInfo" href="{{changeNameOrEmailUrl}}" class="btn btn-default">
<span class="glyphicon glyphicon-user"></span>
<span>{% localized "UserProfile|ButtonLabelChangeAccountInfo" %}</span>
</a>
</div>
<h2>{% localized "SubscriptionStrings|PageTitleDeveloperProfile" %}</h2>
<div class="container-fluid">
<div class="row">
<div class="col-sm-3">
<label for="Email">{% localized "UserProfile|TextboxLabelEmail" %}</label>
</div>
<div class="col-sm-9" id="Email">{{email}}</div>
</div>
{% if isSystemUser != true %}
<div class="row">
<label for="FirstName">{% localized "UserProfile|TextboxLabelEmailFirstName" %}</label>
</div>
<div class="col-sm-9" id="FirstName">{{FirstName}}</div>
</div>
<div class="row">
<label for="LastName">{% localized "UserProfile|TextboxLabelEmailLastName" %}</label>
</div>
<div class="col-sm-9" id="LastName">{{LastName}}</div>
</div>
{% else %}
<div class="row">
<label for="CompanyName">{% localized "UserProfile|TextboxLabelOrganizationName" %}</label>
</div>
<div class="col-sm-9" id="CompanyName">{{CompanyName}}</div>
</div>
<div class="row">
<label for="AddresserEmail">{% localized "UserProfile|TextboxLabelNotificationsSenderEmail" %}</label>
</div>
<div class="col-sm-9" id="AddresserEmail">{{AddresserEmail}}</div>
</div>
{% endif %}
</div>
Controles
Esta plantilla no puede utilizar los controles de página.
Modelo de datos
NOTE
Las plantillas de perfil, aplicaciones, y suscripciones comparten el mismo modelo de datos y reciben los mismos datos de
plantilla.
firstName string Nombre del usuario actual.

lastName string Apellido del usuario actual.
companyName string El nombre de la empresa del usuario

actual.
addresserEmail string Dirección de correo electrónico del

usuario actual.
developersUsageStatisticsLink string Dirección URL relativa para ver el

análisis para el usuario actual.
subscriptions Colección de entidades de suscripción. Las suscripciones para el usuario actual.
applications Colección de entidades de aplicación. Las aplicaciones del usuario actual.
changePasswordUrl string La dirección URL relativa para cambiar la

contraseña del usuario actual.
changeNameOrEmailUrl string La dirección URL relativa para cambiar el

nombre y el correo electrónico para el
usuario actual.
canChangePassword boolean Si el usuario actual puede cambiar su

contraseña.
isSystemUser boolean Si el usuario actual es miembro de uno

de los grupos integrados.

{
"firstName": "Administrator",
"lastName": "",
"companyName": "Contoso",
"addresserEmail": "[email protected]",
"email": "[email protected]",
"developersUsageStatisticsLink": "/Developer/Analytics",
"subscriptions": [
{
"Id": "57026e30de15d80041070001",
"ProductId": "57026e30de15d80041060001",
"ProductTitle": "Starter",
"ProductDescription": "Subscribers will be able to run 5 calls/minute up to a maximum of 100
calls/week.",
"ProductDetailsUrl": "/Products/57026e30de15d80041060001",
"State": "Active",
"DisplayName": "Starter (default)",
"CreatedDate": "2016-04-04T13:37:52.847",
"CanBeCancelled": true,
"IsAwaitingApproval": false,
"StartDate": null,
"ExpirationDate": null,
"NotificationDate": null,
"PrimaryKey": "b6b2870953d04420a4e02c58f2c08e74",
"SecondaryKey": "cfe28d5a1cd04d8abc93f48352076ea5",
"UserId": 1,
"CanBeRenewed": false,
"HasExpired": false,
"IsRejected": false,
"CancelUrl": "/Subscriptions/57026e30de15d80041070001/Cancel",
"RenewUrl": "/Subscriptions/57026e30de15d80041070001/Renew"
},
{
"Id": "57026e30de15d80041070002",
"ProductId": "57026e30de15d80041060002",
"ProductTitle": "Unlimited",
"ProductDescription": "Subscribers have completely unlimited access to the API. Administrator
"State": "Active",
"DisplayName": "Unlimited (default)",
"CreatedDate": "2016-04-04T13:37:52.923",
"StartDate": null,
"PrimaryKey": "8fe7843c36de4cceb4728e6cae297336",
"SecondaryKey": "96c850d217e74acf9b514ff8a5b38551",
"UserId": 1,
}
],
"applications": [],
"changePasswordUrl": "/account/password/change",
"changeNameOrEmailUrl": "/account/update",
"canChangePassword": false,
"isSystemUser": true
}
Suscripciones
La plantilla de suscripciones le permite personalizar la sección de suscripciones de la página de perfil de usuario
en el portal para desarrolladores.
<div class="ap-account-subscriptions">
<a href="{{developersUsageStatisticsLink}}" id="UsageStatistics" class="btn btn-default pull-right">
<span class="glyphicon glyphicon-stats"></span>
<span>{% localized "SubscriptionListStrings|WebDevelopersUsageStatisticsLink" %}</span>
</a>
<h2>{% localized "SubscriptionListStrings|WebDevelopersYourSubscriptions" %}</h2>
<table class="table">
<thead>
<tr>
<th>Subscription details</th>
<th>Product</th>
<th>{% localized "SubscriptionListStrings|WebDevelopersSubscriptionTableStateHeader" %}</th>
<th>Action</th>
</tr>
</thead>
<tbody>
{% if subscriptions.size == 0 %}
<tr>
<td class="text-center" colspan="4">
</td>
</tr>
{% else %}
{% for subscription in subscriptions %}
<tr id="{{subscription.id}}" {% if subscription.hasExpired %} class="expired" {% endif %}>
<td>
<div class="row">
<label class="col-lg-3">{% localized "SubscriptionListStrings|SubscriptionPropertyLabelName" %}
</label>
<div class="col-lg-6">
{{ subscription.displayName }}
</div>
<a class="btn-link" href="/Subscriptions/{{subscription.id}}/Rename">Rename</a>
</div>
</div>
{% if subscription.isAwaitingApproval %}
<div class="row">
<label class="col-lg-3">{% localized
"SubscriptionListStrings|SubscriptionPropertyLabelRequestedDate" %}</label>
{{ subscription.createdDate | date:"MM/dd/yyyy" }}
</div>
</div>
{% else %}
{% if subscription.isRejected == false %}
{% if subscription.startDate %}
<div class="row">
<label class="col-lg-3">{% localized
"SubscriptionListStrings|SubscriptionPropertyLabelStartedDate" %}</label>
{{ subscription.startDate | date:"MM/dd/yyyy" }}
</div>
</div>
{% endif %}

<div class="row">
<label class="col-lg-3">{% localized "SubscriptionListStrings|WebDevelopersPrimaryKey" %}</label>
<code data-bind="text: $data.displayKey()" id="primary_{{subscription.id}}"></code>
</div>

<div class="nowrap">
<a href="#" class="btn-link" id="togglePrimary_{{subscription.id}}" data-bind="click:
toggleKeyDisplay, text: toggleKeyLabel"></a>
|
<a href="#" class="btn-link" id="regeneratePrimary_{{subscription.id}}" data-bind="click:
regenerateKey, text: regenerateKeyLabel"></a>
</div>


<div class="progress progress-striped active">
<div class="progress-bar" role="progressbar" aria-valuenow="100" aria-valuemin="0" aria-
valuemax="100" style="width: 100%">
<span class="sr-only"></span>
</div>
</div>

</div>
</div>


<div class="row">
<label class="col-lg-3">{% localized "SubscriptionListStrings|WebDevelopersSecondaryKey" %}
</label>
<code data-bind="text: $data.displayKey()" id="secondary_{{subscription.id}}"></code>
</div>
<a href="#" class="btn-link" id="toggleSecondary_{{subscription.id}}" data-bind="click:
toggleKeyDisplay, text: toggleKeyLabel">{% localized "SubscriptionListStrings|ButtonLabelShowKey" %}</a>
|
<a href="#" class="btn-link" id="regenerateSecondary_{{subscription.id}}" data-bind="click:
regenerateKey, text: regenerateKeyLabel">{% localized "SubscriptionListStrings|WebDevelopersRegenerateLink" %}
</a>
</div>
</div>
</div>
<div class="clearfix"> </div>
</div>

{% endif %}
{% endif %}
</td>
<td>
<a href="{{subscription.productDetailsUrl}}">{{subscription.productTitle}}</a>
</td>
<td>
<strong>
{{subscription.state}}
</strong>
</td>
<td>
{% if subscription.canBeCancelled %}
<subscription-cancel params="{ subscriptionId: '{{subscription.id}}', cancelUrl:
'{{subscription.cancelUrl}}' }"></subscription-cancel>
{% endif %}
</div>
</td>
</tr>
{% endfor %}
{% endif %}
</tbody>
</table>
</div>
Controles
Esta plantilla puede utilizar los siguientes controles de página.
subscription-cancel
Modelo de datos
NOTE
plantilla.

actual.

usuario actual.




usuario actual.

contraseña.


{
"lastName": "",
"subscriptions": [
{
"Id": "57026e30de15d80041070001",
"ProductId": "57026e30de15d80041060001",
calls/week.",
"State": "Active",
"CreatedDate": "2016-04-04T13:37:52.847",
"StartDate": null,
"UserId": 1,
},
{
"Id": "57026e30de15d80041070002",
"ProductId": "57026e30de15d80041060002",
"State": "Active",
"CreatedDate": "2016-04-04T13:37:52.923",
"StartDate": null,
"UserId": 1,
}
],
"applications": [],
}
Aplicaciones
La plantilla de aplicaciones le permite personalizar la sección de suscripciones de la página de perfil de usuario en
<div class="ap-account-applications">
<a id="RegisterApplication" href="/Developer/Applications/Register" class="btn btn-success pull-right">
<span class="glyphicon glyphicon-plus"></span>
<span>{% localized "ApplicationListStrings|WebDevelopersRegisterAppLink" %}</span>
</a>
<h2>{% localized "ApplicationListStrings|WebDevelopersYourApplicationsHeader" %}</h2>
<table class="table">
<thead>
<tr>
<th class="col-md-8">{% localized "ApplicationListStrings|WebDevelopersAppTableNameHeader" %}</th>
<th class="col-md-2">{% localized "ApplicationListStrings|WebDevelopersAppTableCategoryHeader" %}</th>
<th class="col-md-2" colspan="2">{% localized
"ApplicationListStrings|WebDevelopersAppTableStateHeader" %}</th>
</tr>
</thead>
<tbody>
{% if applications.size == 0 %}
<tr>
<td class="col-md-12 text-center" colspan="4">
</td>
</tr>
{% else %}
{% for app in applications %}

<tr>
<td class="col-md-8">
{{app.title}}
</td>
{{app.categoryName}}
</td>
<strong>
{% case app.state %}
{% when ApplicationStateModel.Registered %}
{% localized "ApplicationListStrings|WebDevelopersAppNotSubmitted" %}
{% when ApplicationStateModel.Unpublished %}
{% localized "ApplicationListStrings|WebDevelopersAppNotPublished" %}
{% else %}
{{ app.state }}
{% endcase %}
</strong>
</td>
{% if app.state != ApplicationStateModel.Submitted and app.state !=
ApplicationStateModel.Published %}
<app-actions params="{ appId: '{{app.id}}' }"></app-actions>
{% endif %}
</div>
</td>
</tr>
{% endfor %}
{% endif %}
</tbody>
</table>
</div>
Controles
Esta plantilla puede utilizar los siguientes controles de página.
app-actions
Modelo de datos
NOTE
plantilla.

actual.

usuario actual.



usuario actual.

contraseña.


{
"lastName": "",
"subscriptions": [
{
"Id": "57026e30de15d80041070001",
"ProductId": "57026e30de15d80041060001",
calls/week.",
"State": "Active",
"CreatedDate": "2016-04-04T13:37:52.847",
"StartDate": null,
"UserId": 1,
},
{
"Id": "57026e30de15d80041070002",
"ProductId": "57026e30de15d80041060002",
"State": "Active",
"CreatedDate": "2016-04-04T13:37:52.923",
"StartDate": null,
"UserId": 1,
}
],
"applications": [],
}
Update account info

La plantilla para actualizar información de cuenta le permite personalizar la página Actualizar información
de cuenta en el portal para desarrolladores.
<div class="row">
<div class="col-sm-6 col-md-6">
<div class="form-group">
<label for="Email">{% localized "SigninResources|TextboxLabelEmail" %}</label>
<input autofocus="autofocus" class="form-control" id="Email" name="Email" type="text" value="{{email}}">
</div>
<label for="FirstName">{% localized "SigninResources|TextboxLabelEmailFirstName" %}</label>
<input class="form-control" id="FirstName" name="FirstName" type="text" value="{{firstName}}">
</div>
<label for="LastName">{% localized "SigninResources|TextboxLabelEmailLastName" %}</label>
<input class="form-control" id="LastName" name="LastName" type="text" value="{{lastName}}">
</div>
<label for="Password">{% localized "SigninResources|WebAuthenticationSigninPasswordLabel" %}</label>
<input class="form-control" id="Password" name="Password" type="password">
</div>
</div>
</div>
<button type="submit" class="btn btn-primary" id="UpdateProfile">

{% localized "UpdateProfileStrings|ButtonLabelUpdateProfile" %}
</button>
<a class="btn btn-default" href="/developer" role="button">
{% localized "CommonStrings|ButtonLabelCancel" %}
</a>
Controles
Esta plantilla no puede utilizar los controles de página.
Modelo de datos
Entidad Información de cuenta de usuario.
{
"FirstName": "Administrator",
"LastName": "",
"Email": "[email protected]",
"Password": null,
"NameIdentifier": null,
"ProviderName": null,
"IsBasicAccount": false
}
Pasos siguientes
Plantillas de página en Azure API Management
Las plantillas de esta sección le permiten personalizar el contenido de las páginas de inicio de sesión, registro y
página no encontrada del portal para desarrolladores.
Sign in
Sign up
Page not found
NOTE
Disponibilidad
IMPORTANT
Sign in
La plantilla sign in le permite personalizar la página de inicio de sesión en el portal para desarrolladores.
<h2 class="text-center">{% localized "SigninStrings|WebAuthenticationSigninTitle" %}</h2>
{% if registrationEnabled == true %}
<p class="text-center">{% localized "SigninStrings|WebAuthenticationNotAMember" %}</p>
{% endif %}
<div class="row center-block ap-idp-container">

<p>{% localized "SigninStrings|WebAuthenticationSigininWithPassword" %}</p>
<basic-SignIn></basic-SignIn>
{% endif %}
</div>
{% if registrationEnabled != true and providers.size == 0 %}

{% localized "ProviderInfoStrings|TextboxExternalIdentitiesDisabled" %}
{% else %}
{% if providers.size > 0 %}
<div class="providers-list">
<p class="text-left">
{% localized "ProviderInfoStrings|TextboxExternalIdentitiesSigninInvitation" %}
{% else %}
{% localized "ProviderInfoStrings|TextboxExternalIdentitiesSigninInvitationPrimary" %}
{% endif %}
</p>
<providers></providers>
</div>
</div>
{% endif %}
{% endif %}
{% if userRegistrationTermsEnabled == true %}
<div id="terms" class="modal" role="dialog" tabindex="-1">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<h4 class="modal-title">{% localized "SigninResources|DialogHeadingTermsOfUse" %}</h4>
</div>
<div class="modal-body break-all">{{userRegistrationTerms}}</div>
<div class="modal-footer">
<button type="button" class="btn btn-default" data-dismiss="modal">{% localized
"CommonStrings|ButtonLabelClose" %}</button>
</div>
</div>
</div>
</div>
<p>{% localized "SigninResources|TextblockUserRegistrationTermsProvided" %}</p>
</div>
{% endif %}
</div>
Controles
Esta plantilla puede usar los siguientes controles de página.
basic-signin
providers
Modelo de datos
Entidad User sign in.
{
"Email": null,
"Password": null,
"ReturnUrl": null,
"RememberMe": false,
"RegistrationEnabled": true,
"DelegationEnabled": false,
"DelegationUrl": null,
"SsoSignUpUrl": null,
"AuxServiceUrl": "https://portal.azure.com/#resource/subscriptions/{subscription ID}/resourceGroups/Api-
Default-West-US/providers/Microsoft.ApiManagement/service/contoso5",
"Providers": [
{
"Properties": {
"AuthenticationType": "Aad",
"Caption": "Azure Active Directory"
},
"AuthenticationType": "Aad",
"Caption": "Azure Active Directory"
}
],
"UserRegistrationTerms": null,
"UserRegistrationTermsEnabled": false
}
Sign up
La plantilla sign up le permite personalizar la página de registro en el portal para desarrolladores.
<h2 class="text-center">{% localized "SignupStrings|PageTitleSignup" %}</h2>

<p class="text-center">
{% localized "SignupStrings|WebAuthenticationAlreadyAMember" %} <a href="/signin">{% localized
"SignupStrings|WebAuthenticationSigninNow" %}</a>
</p>
<div class="row center-block ap-idp-container">

<p>{% localized "SignupStrings|WebAuthenticationCreateNewAccount" %}</p>
<sign-up></sign-up>
</div>
</div>
Controles
Esta plantilla puede usar los siguientes controles de página.
sign-up
Modelo de datos
Entidad User sign up.
{
"PasswordConfirm": null,
"Password": null,
"PasswordVerdictLevel": 0,
"UserRegistrationTermsOptions": 0,
"ConsentAccepted": false,
"Email": null,
"FirstName": null,
"LastName": null,
"UserData": null,
"NameIdentifier": null,
"ProviderName": null
}
Page not found

La plantilla page not found le permite personalizar la página de página no encontrada en el portal para
desarrolladores.
<h2>{% localized "NotFoundStrings|PageTitleNotFound" %}</h2>
<h3>{% localized "NotFoundStrings|TitlePotentialCause" %}</h3>

<ul>
<li>{% localized "NotFoundStrings|TextblockPotentialCauseOldLink" %}</li>
<li>{% localized "NotFoundStrings|TextblockPotentialCauseMisspelledUrl" %}</li>
</ul>
<h3>{% localized "NotFoundStrings|TitlePotentialSolution" %}</h3>

<ul>
<li>{% localized "NotFoundStrings|TextblockPotentialSolutionRetype" %}</li>
<li>
{% capture textPotentialSolutionStartOver %}{% localized
"NotFoundStrings|TextblockPotentialSolutionStartOver" %}{% endcapture %}
{% capture homeLink %}<a href="/">{% localized "NotFoundStrings|LinkLabelHomePage" %}</a>{% endcapture %}
{% assign replaceString = '{0}' %}
{{ textPotentialSolutionStartOver | replace : replaceString, homeLink }}

</li>
</ul>
<p>
{% capture textReportProblem %}{% localized "NotFoundStrings|TextReportProblem" %}{% endcapture %}
{% capture emailLink %}<a href="mailto:[email protected]" target="_self" title="API Management Support">
{% localized "NotFoundStrings|LinkLabelSendUsEmail" %}</a>{% endcapture %}
{% assign replaceString = '{0}' %}
{{ textReportProblem | replace : replaceString, emailLink }}

</p>
Controles
Esta plantilla no puede usar ninguno de los controles de página.
Modelo de datos
referenceCode string Código generado si esta página se

mostró como resultado de un error
interno.
errorCode string Código generado si esta página se

mostró como resultado de un error
interno.
emailBody string Cuerpo de correo electrónico generado

si esta página se mostró como
resultado de un error interno.
requestedUrl string La dirección URL solicitada cuando no

se encontró la página.
referrerUrl string La dirección URL de origen de referencia

a la dirección URL solicitada.

{
"referenceCode": null,
"errorCode": null,
"emailBody": null,
"requestedUrl": "https://contoso5.portal.azure-api.net:443/NotFoundPage?startEditTemplate=NotFoundPage",
"referrerUrl": "https://contoso5.portal.azure-api.net/signup?startEditTemplate=SignUpTemplate"
}
Pasos siguientes
Recursos de plantilla de Azure API Management
Azure API Management proporciona los siguientes tipos de recursos para su uso en las plantillas del portal para
desarrolladores.
Recursos de cadena
Recursos de glifo
Disponibilidad
IMPORTANT
Recursos de cadena
API Management proporciona un conjunto completo de recursos de cadena para su uso en el portal para
desarrolladores. Estos recursos están localizados en todos los idiomas admitidos por API Management. El
conjunto predeterminado de plantillas utiliza estos recursos para encabezados de páginas etiquetas y cualquier
cadena constante que se muestren en el portal para desarrolladores. Para usar un recurso de cadena en sus
plantillas, especifique el prefijo de la cadena del recurso seguido por el nombre de la cadena, como se muestra en
el siguiente ejemplo.
{% localized "Prefix|Name" %}
El siguiente ejemplo está tomado de la plantilla Lista de productos y muestra Productos en la parte superior de la
página.
Se admiten las siguientes opciones de localización:
CONFIGURACIÓN REGIONAL IDIOMA
"en" "English"
"cs" "Čeština"
"de" "Deutsch"
"es" "Español"
"fr" "Français"
CONFIGURACIÓN REGIONAL IDIOMA
"hu" "Magyar"
"it" "Italiano"
"ja-JP" "日本語"
"ko" "한국어"
"nl" "Nederlands"
"pl" "Polski"
"pt-br" "Português (Brasil)"
"pt-pt" "Português (Portugal)"
"ru" "Русский"
"sv" "Svenska"
"tr" "Türkçe"
"zh-hans" "中文(简体)"
"zh-hant" "中文(繁體)"
Consulte las siguientes tablas a fin de obtener los recursos de cadena disponibles para su uso en sus plantillas del
portal para desarrolladores. Use el nombre de la tabla como el prefijo para los recursos de cadena de esa tabla.
ApisStrings
ApplicationListStrings
AppDetailsStrings
AppStrings
CommonResources
CommonStrings
Documentación
ErrorPageStrings
IssuesStrings
NotFoundStrings
ProductDetailsStrings
ProductsStrings
ProviderInfoStrings
SigninResources
SigninStrings
SignupStrings
SubscriptionListStrings
SubscriptionStrings
UpdateProfileStrings
UserProfile
ApisStrings
NOMBRE TEX TO
PageTitleApis API existentes
AppDetailsStrings
NOMBRE TEX TO
WebApplicationsDetailsTitle Versión preliminar de la aplicación
WebApplicationsRequirementsHeader Requisitos
WebApplicationsScreenshotAlt Instantánea
WebApplicationsScreenshotsHeader Capturas de pantalla
ApplicationListStrings
NOMBRE TEX TO
WebDevelopersAppDeleteConfirmation ¿Está seguro de que desea quitar la aplicación?
WebDevelopersAppNotPublished No publicado
WebDevelopersAppNotSubmitted No enviado
WebDevelopersAppTableCategoryHeader Categoría
WebDevelopersAppTableNameHeader NOMBRE
WebDevelopersAppTableStateHeader Estado
WebDevelopersEditLink Edit
WebDevelopersRegisterAppLink Registre la aplicación
WebDevelopersRemoveLink Remove
WebDevelopersSubmitLink Enviar
WebDevelopersYourApplicationsHeader Sus aplicaciones

AppStrings
NOMBRE TEX TO
WebApplicationsHeader APLICACIONES
CommonResources
NOMBRE TEX TO
NoItemsToDisplay No se encontró ningún resultado.
GeneralExceptionMessage Se ha producido algún problema. Podría ser un problema

temporal o un error. Vuelva a intentarlo.
GeneralJsonExceptionMessage Se ha producido algún problema. Podría ser un problema

temporal o un error. Vuelva a cargar la página y pruebe otra
vez.
ConfirmationMessageUnsavedChanges Hay algunos cambios no guardados. ¿Está seguro de que

desea cancelar y descartar los cambios?
AzureActiveDirectory Azure Active Directory
HttpLargeRequestMessage El cuerpo de la solicitud HTTP es demasiado extenso.
CommonStrings
NOMBRE TEX TO
ButtonLabelCancel Cancelar
ButtonLabelSave Save
GeneralExceptionMessage Se ha producido algún problema. Podría ser un problema

temporal o un error. Vuelva a intentarlo.
NoItemsToDisplay No hay ningún elemento para mostrar.
PagerButtonLabelFirst Primero
PagerButtonLabelLast Último
PagerButtonLabelNext Pasos siguientes
PagerButtonLabelPrevious Anterior
PagerLabelPageNOfM Página {0} de {1}
PasswordTooShort La contraseña es demasiado extensa.
EmailAsPassword No use su correo electrónico como la contraseña.
PasswordSameAsUserName La contraseña no puede contener su nombre de usuario.

NOMBRE TEX TO
PasswordTwoCharacterClasses Utilice diferentes clases de caracteres.
PasswordTooManyRepetitions Hay demasiados caracteres repetidos.
PasswordSequenceFound La contraseña contiene secuencias.
PagerLabelPageSize Tamaño de página
CurtainLabelLoading Cargando...
TablePlaceholderNothingToDisplay No hay ningún dato para el intervalo de tiempo y el ámbito

seleccionados.
ButtonLabelClose cierre
Documentation
NOMBRE TEX TO
WebDocumentationInvalidHeaderErrorMessage Encabezado "{0}" no válido
WebDocumentationInvalidRequestErrorMessage Dirección URL de solicitud no válida
TextboxLabelAccessToken Token de acceso*
DropdownOptionPrimaryKeyFormat Primary-{0}
DropdownOptionSecondaryKeyFormat Secondary-{0}
WebDocumentationSubscriptionKeyText Su clave de suscripción
WebDocumentationTemplatesAddHeaders Agregue los encabezados HTTP necesarios.
WebDocumentationTemplatesBasicAuthSample Ejemplo de autorización básica
WebDocumentationTemplatesCurlForBasicAuth Para la autorización básica, use lo siguiente: --user {nombre de

usuario}: {contraseña}
WebDocumentationTemplatesCurlValuesForPath Especifique valores para los parámetros de ruta de acceso (que

se muestran como {...}), la clave de la suscripción y valores para
los parámetros de consulta.
WebDocumentationTemplatesDeveloperKey Especifique la clave de suscripción.
WebDocumentationTemplatesJavaApache Este ejemplo utiliza el cliente HTTP Apache desde HTTP

Components (http://hc.apache.org/httpcomponents-client-
ga/)
WebDocumentationTemplatesOptionalParams Especifique valores para los parámetros opcionales, según se

requiera.
NOMBRE TEX TO
WebDocumentationTemplatesPhpPackage Esta muestra utiliza el paquete HTTP_Request2. (para obtener

más información:
https://pear.php.net/package/HTTP_Request2)
WebDocumentationTemplatesPythonValuesForPath Especifique valores para los parámetros de ruta de acceso (que

se muestran como {...}) y el cuerpo de la solicitud, si así se
requiere.
WebDocumentationTemplatesRequestBody Especifique el cuerpo de la solicitud.
WebDocumentationTemplatesRequiredParams Especifique valores para los siguientes parámetros requeridos.
WebDocumentationTemplatesValuesForPath Especifique valores para los parámetros de ruta de acceso (que

se muestran como {...}).
OAuth2AuthorizationEndpointDescription El punto de conexión de autorización se utiliza para interactuar

con el propietario del recurso y obtener la concesión de una
autorización.
OAuth2AuthorizationEndpointName Punto de conexión de autorización
OAuth2TokenEndpointDescription El cliente utiliza el punto de conexión de token para obtener

un token de acceso presentando su concesión de autorización
o token de actualización.
OAuth2TokenEndpointName Punto de conexión de token
OAuth2Flow_AuthorizationCodeGrant_Step_AuthorizationReq <p>El cliente inicia el flujo dirigiendo el agente de usuario del

uest_Description propietario del recurso al punto de conexión de autorización. El
cliente incluye su identificador de cliente, el ámbito solicitado,
el estado local y un URI de redirección al que el servidor de
autorización enviará al agente de usuario una vez concedido el
acceso (o denegado). </p> <p>El servidor de autorización
autentica al propietario del recurso (por medio del agente de
usuario) y establece si aquel acepta o rechaza la solicitud de
acceso del cliente. </p> <p>Suponiendo que el propietario
del recurso conceda el acceso, el servidor de autorización
redirige el agente de usuario al cliente con el URI de
redirección especificado antes (en la solicitud o durante el
registro del cliente). El URI de redirección incluye un código de
autorización y cualquier estado que haya proporcionado el
cliente con anterioridad. </p>
OAuth2Flow_AuthorizationCodeGrant_Step_AuthorizationReq <p>Si el usuario rechaza la solicitud de acceso o si esta no es

uest_ErrorDescription válida, se informará al cliente con los siguientes parámetros,
que se agregan a la redirección: </p>
OAuth2Flow_AuthorizationCodeGrant_Step_AuthorizationReq Solicitud de autorización

uest_Name
OAuth2Flow_AuthorizationCodeGrant_Step_AuthorizationReq <p>La aplicación cliente debe enviar al usuario al punto de

uest_RequestDescription conexión de autorización con el fin de iniciar el proceso de
OAuth. En el punto de conexión de autorización, el usuario se
autentica y, después, se concede o deniega el acceso a la
aplicación. </p>
NOMBRE TEX TO
OAuth2Flow_AuthorizationCodeGrant_Step_AuthorizationReq <p>Suponiendo que el propietario del recurso conceda el

uest_ResponseDescription acceso, el servidor de autorización redirige el agente de
usuario al cliente con el URI de redirección especificado antes
(en la solicitud o durante el registro del cliente). El URI de
redirección incluye un código de autorización y cualquier
estado que haya proporcionado el cliente con anterioridad.
</p>
OAuth2Flow_AuthorizationCodeGrant_Step_TokenRequest_De <p>El cliente solicita un token de acceso del punto de

scription conexión de token del servidor de autorización incluyendo el
código de autorización recibido en el paso anterior. Al realizar la
solicitud, el cliente se autentica con el servidor de autorización.
El cliente incluye el URI de redirección utilizado con el objetivo
de obtener el código de autorización para la comprobación.
</p> <p>El servidor de autorización autentica el cliente,
valida el código de autorización y garantiza que el URI de
redirección recibido coincida con el URI empleado para
redirigir el cliente en el paso C. Si es válido, el servidor de
autorización responde con un token de acceso y, de forma
opcional, otro de actualización. </p>
OAuth2Flow_AuthorizationCodeGrant_Step_TokenRequest_Err <p>Si la solicitud no es válida o no ha superado la

orDescription autenticación del cliente, el servidor de autorización responde
con un código de estado HTTP 400 (solicitud incorrecta) —a
menos que se especifique lo contrario— e incluye en la
respuesta los siguientes parámetros. </p>
OAuth2Flow_AuthorizationCodeGrant_Step_TokenRequest_Re <p>El cliente realiza una solicitud al punto de conexión de

questDescription token enviando los siguientes parámetros en el formato
"application/x-www-form-urlencoded" con una codificación de
caracteres de UTF-8 en el cuerpo de la entidad de la solicitud
HTTP. </p>
OAuth2Flow_AuthorizationCodeGrant_Step_TokenRequest_Re <p>El servidor de autorización emite un token de acceso y

sponseDescription otro de actualización opcional. Además, construye la respuesta
agregando los siguientes parámetros al cuerpo de entidad de
la respuesta HTTP con un código de estado 200 (correcto).
</p>
OAuth2Flow_ClientCredentialsGrant_Step_TokenRequest_Desc <p>El cliente se autentica con el servidor de autorización y

ription solicita un token de acceso del punto de conexión de token.
</p> <p>El servidor de autorización autentica al cliente y, si
es válido, emite un token de acceso. </p>
OAuth2Flow_ClientCredentialsGrant_Step_TokenRequest_Error <p>Si la solicitud no es válida o no ha superado la

Description autenticación del cliente, el servidor de autorización responde
OAuth2Flow_ClientCredentialsGrant_Step_TokenRequest_Requ <p>El cliente realiza una solicitud al punto de conexión de

estDescription token agregando los siguientes parámetros en el formato
HTTP. </p>
NOMBRE TEX TO
OAuth2Flow_ClientCredentialsGrant_Step_TokenRequest_Resp <p>Si la solicitud de acceso es válida y se autoriza, el servidor

onseDescription de autorización emite un token de acceso y otro de
actualización opcional. Además, construye la respuesta
</p>
OAuth2Flow_ImplicitGrant_Step_AuthorizationRequest_Descri <p>El cliente inicia el flujo dirigiendo el agente de usuario del

ption propietario del recurso al punto de conexión de autorización. El
cliente incluye su identificador de cliente, el ámbito solicitado,
el estado local y un URI de redirección al que el servidor de
autorización enviará al agente de usuario una vez concedido el
acceso (o denegado). </p> <p>El servidor de autorización
autentica al propietario del recurso (por medio del agente de
usuario) y establece si aquel acepta o rechaza la solicitud de
acceso del cliente. </p> <p>Suponiendo que el propietario
del recurso conceda el acceso, el servidor de autorización
redirige el agente de usuario al cliente con el URI de
redirección especificado antes. El URI de redirección incluye el
token de acceso en el fragmento del URI. </p>
OAuth2Flow_ImplicitGrant_Step_AuthorizationRequest_ErrorD <p>Si el propietario del recurso rechaza la solicitud de acceso

escription o esta produce algún error por un motivo distinto a un URI de
redirección ausente o no válido, el servidor de autorización
informa al cliente agregando los siguientes parámetros al
componente de fragmento del URI de redirección con el
formato "application/x-www-form-urlencoded". </p>
OAuth2Flow_ImplicitGrant_Step_AuthorizationRequest_Reque <p>La aplicación cliente debe enviar al usuario al punto de

stDescription conexión de autorización con el fin de iniciar el proceso de
OAuth. En el punto de conexión de autorización, el usuario se
autentica y, después, se concede o deniega el acceso a la
aplicación. </p>
OAuth2Flow_ImplicitGrant_Step_AuthorizationRequest_Respo <p>Si el propietario del recurso acepta la solicitud de acceso,

nseDescription el servidor de autenticación emite un token de acceso y lo
envía al cliente agregando los siguientes parámetros en el
componente de fragmento del URI de redirección con el
formato "application/x-www-form-urlencoded". </p>
OAuth2Flow_ObtainAuthorization_AuthorizationCodeGrant_D El flujo del código de autorización está optimizado para

escription clientes con la capacidad de mantener la confidencialidad de
sus credenciales (p. ej., aplicaciones de servidor web
implementadas mediante PHP, Java, Python, Ruby, ASP.NET,
etc.).
OAuth2Flow_ObtainAuthorization_AuthorizationCodeGrant_N Concesión del código de autorización

ame
OAuth2Flow_ObtainAuthorization_ClientCredentialsGrant_Des El flujo de credenciales del cliente es adecuado para casos en

cription los que este último (es decir, su aplicación) solicita acceso a los
recursos protegidos bajo su control. El cliente se considera un
propietario de recursos, por lo que no se requiere ninguna
interacción por parte del usuario final.
OAuth2Flow_ObtainAuthorization_ClientCredentialsGrant_Na Concesión de las credenciales de cliente

me
NOMBRE TEX TO
OAuth2Flow_ObtainAuthorization_ImplicitGrant_Description El flujo implícito está optimizado para clientes sin capacidad de

mantener la confidencialidad de sus credenciales y de los que
se tiene constancia que emplean un URI de redirección
concreto. Estos clientes se suelen implementar en un
explorador mediante un lenguaje de scripting como JavaScript.
OAuth2Flow_ObtainAuthorization_ImplicitGrant_Name Concesión implícita
OAuth2Flow_ObtainAuthorization_ResourceOwnerPasswordCr El flujo de credenciales de contraseña del propietario del

edentialsGrant_Description recurso es adecuado en casos en este último mantiene una
relación de confianza con el cliente (es decir, su aplicación),
como el sistema operativo del dispositivo o una aplicación con
privilegios elevados. Este flujo resulta adecuado para clientes
con capacidad de obtener las credenciales del propietario del
recurso (nombre de usuario y contraseña; normalmente
mediante un formulario interactivo).
OAuth2Flow_ObtainAuthorization_ResourceOwnerPasswordCr Concesión de credenciales de contraseña de propietario del

edentialsGrant_Name recurso
OAuth2Flow_ResourceOwnerPasswordCredentialsGrant_Step_ <p>El propietario del recurso proporciona al cliente su

TokenRequest_Description nombre de usuario y contraseña. </p> <p>El cliente solicita
un token de acceso del punto de conexión de token del
servidor de autorización; para ello, incluye las credenciales
recibidas del propietario del recurso. Al realizar la solicitud, el
cliente se autentica con el servidor de autorización. </p>
<p>El servidor de autorización autentica el cliente y valida las
credenciales del propietario del recurso y, en caso de
determinar su validez, emite un token de acceso. </p>
OAuth2Flow_ResourceOwnerPasswordCredentialsGrant_Step_ <p>Si la solicitud no es válida o no ha superado la

TokenRequest_ErrorDescription autenticación del cliente, el servidor de autorización responde
OAuth2Flow_ResourceOwnerPasswordCredentialsGrant_Step_ <p>El cliente realiza una solicitud al punto de conexión de

TokenRequest_RequestDescription token agregando los siguientes parámetros en el formato
HTTP. </p>
OAuth2Flow_ResourceOwnerPasswordCredentialsGrant_Step_ <p>Si la solicitud de acceso es válida y se autoriza, el servidor

TokenRequest_ResponseDescription de autorización emite un token de acceso y otro de
actualización opcional. Además, construye la respuesta
</p>
OAuth2Step_AccessTokenRequest_Name Solicitud de token de acceso
OAuth2Step_AuthorizationRequest_Name Solicitud de autorización
OAuth2AccessToken_AuthorizationCodeGrant_TokenResponse REQUERIDO. El token de acceso emitido por el servidor de

autorización.
NOMBRE TEX TO
OAuth2AccessToken_ClientCredentialsGrant_TokenResponse REQUERIDO. El token de acceso emitido por el servidor de

autorización.
OAuth2AccessToken_ImplicitGrant_AuthorizationResponse REQUERIDO. El token de acceso emitido por el servidor de

autorización.
OAuth2AccessToken_ResourceOwnerPasswordCredentialsGra REQUERIDO. El token de acceso emitido por el servidor de

nt_TokenResponse autorización.
OAuth2ClientId_AuthorizationCodeGrant_AuthorizationReque REQUERIDO. Identificador del cliente.

st
OAuth2ClientId_AuthorizationCodeGrant_TokenRequest REQUERIDO si el cliente no se autentica con el servidor de

autorización.
OAuth2ClientId_ImplicitGrant_AuthorizationRequest REQUERIDO. El identificador del cliente.
OAuth2Code_AuthorizationCodeGrant_AuthorizationRespons REQUERIDO. El código de autorización que genera el servidor

e de autorización.
OAuth2Code_AuthorizationCodeGrant_TokenRequest REQUERIDO. El código de autorización recibido del servidor de

autorización.
OAuth2ErrorDescription_AuthorizationCodeGrant_Authorizati OPCIONAL. Texto ASCII en lenguaje natural que proporciona

onErrorResponse información adicional.
OAuth2ErrorDescription_AuthorizationCodeGrant_TokenError OPCIONAL. Texto ASCII en lenguaje natural que proporciona

Response información adicional.
OAuth2ErrorDescription_ClientCredentialsGrant_TokenErrorRe OPCIONAL. Texto ASCII en lenguaje natural que proporciona

sponse información adicional.
OAuth2ErrorDescription_ImplicitGrant_AuthorizationErrorResp OPCIONAL. Texto ASCII en lenguaje natural que proporciona

onse información adicional.
OAuth2ErrorDescription_ResourceOwnerPasswordCredentials OPCIONAL. Texto ASCII en lenguaje natural que proporciona

Grant_TokenErrorResponse información adicional.
OAuth2ErrorUri_AuthorizationCodeGrant_AuthorizationErrorR OPCIONAL. Un URI que identifica una página web en lenguaje

esponse natural con información sobre el error.
OAuth2ErrorUri_AuthorizationCodeGrant_TokenErrorRespons OPCIONAL. Un URI que identifica una página web en lenguaje

e natural con información sobre el error.
OAuth2ErrorUri_ClientCredentialsGrant_TokenErrorResponse OPCIONAL. Un URI que identifica una página web en lenguaje

natural con información sobre el error.
OAuth2ErrorUri_ImplicitGrant_AuthorizationErrorResponse OPCIONAL. Un URI que identifica una página web en lenguaje

natural con información sobre el error.
OAuth2ErrorUri_ResourceOwnerPasswordCredentialsGrant_To OPCIONAL. Un URI que identifica una página web en lenguaje

kenErrorResponse natural con información sobre el error.
NOMBRE TEX TO
OAuth2Error_AuthorizationCodeGrant_AuthorizationErrorRes REQUERIDO. Un solo código de error ASCII entre las opciones

ponse siguientes: invalid_request, unauthorized_client, access_denied,
unsupported_response_type, invalid_scope, server_error y
temporarily_unavailable.
OAuth2Error_AuthorizationCodeGrant_TokenErrorResponse REQUERIDO. Un solo código de error ASCII entre las opciones

siguientes: invalid_request, invalid_client, invalid_grant,
unauthorized_client, unsupported_grant_type e invalid_scope.
OAuth2Error_ClientCredentialsGrant_TokenErrorResponse REQUERIDO. Un solo código de error ASCII entre las opciones

siguientes: invalid_request, invalid_client, invalid_grant,
OAuth2Error_ImplicitGrant_AuthorizationErrorResponse REQUERIDO. Un solo código de error ASCII entre las opciones

siguientes: invalid_request, unauthorized_client, access_denied,
unsupported_response_type, invalid_scope, server_error y
temporarily_unavailable.
OAuth2Error_ResourceOwnerPasswordCredentialsGrant_Toke REQUERIDO. Un solo código de error ASCII entre las opciones

nErrorResponse siguientes: invalid_request, invalid_client, invalid_grant,
OAuth2ExpiresIn_AuthorizationCodeGrant_TokenResponse RECOMENDADO. La vigencia en segundos del token de

acceso.
OAuth2ExpiresIn_ClientCredentialsGrant_TokenResponse RECOMENDADO. La vigencia en segundos del token de

acceso.
OAuth2ExpiresIn_ImplicitGrant_AuthorizationResponse RECOMENDADO. La vigencia en segundos del token de

acceso.
OAuth2ExpiresIn_ResourceOwnerPasswordCredentialsGrant_T RECOMENDADO. La vigencia en segundos del token de

okenResponse acceso.
OAuth2GrantType_AuthorizationCodeGrant_TokenRequest REQUERIDO. El valor debe establecerse en

"authorization_code".
OAuth2GrantType_ClientCredentialsGrant_TokenRequest REQUERIDO. El valor debe establecerse en "client_credentials".
OAuth2GrantType_ResourceOwnerPasswordCredentialsGrant_ REQUERIDO. El valor debe establecerse en "password".

TokenRequest
OAuth2Password_ResourceOwnerPasswordCredentialsGrant_ REQUERIDO. La contraseña de propietario del recurso.

TokenRequest
OAuth2RedirectUri_AuthorizationCodeGrant_AuthorizationRe OPCIONAL. El URI del punto de conexión de redirección debe

quest ser un URI absoluto.
OAuth2RedirectUri_AuthorizationCodeGrant_TokenRequest REQUERIDO si el parámetro se incluyó "redirect_uri" en la

solicitud de autorización y sus valores deben ser idénticos.
OAuth2RedirectUri_ImplicitGrant_AuthorizationRequest OPCIONAL. El URI del punto de conexión de redirección debe

ser un URI absoluto.
NOMBRE TEX TO
OAuth2RefreshToken_AuthorizationCodeGrant_TokenRespons OPCIONAL. El token de actualización, que puede utilizarse

e para obtener nuevos tokens de acceso.
OAuth2RefreshToken_ClientCredentialsGrant_TokenResponse OPCIONAL. El token de actualización, que puede utilizarse

para obtener nuevos tokens de acceso.
OAuth2RefreshToken_ResourceOwnerPasswordCredentialsGra OPCIONAL. El token de actualización, que puede utilizarse

nt_TokenResponse para obtener nuevos tokens de acceso.
OAuth2ResponseType_AuthorizationCodeGrant_Authorization REQUERIDO. El valor debe establecerse en "code".

Request
OAuth2ResponseType_ImplicitGrant_AuthorizationRequest REQUERIDO. El valor debe establecerse en "token".
OAuth2Scope_AuthorizationCodeGrant_AuthorizationRequest OPCIONAL. El ámbito de la solicitud de acceso.
OAuth2Scope_AuthorizationCodeGrant_TokenResponse OPCIONAL si es idéntico al ámbito solicitado por el cliente; de

lo contrario REQUERIDO.
OAuth2Scope_ClientCredentialsGrant_TokenRequest OPCIONAL. El ámbito de la solicitud de acceso.
OAuth2Scope_ClientCredentialsGrant_TokenResponse OPCIONAL si es idéntico al ámbito solicitado por el cliente; de

OAuth2Scope_ImplicitGrant_AuthorizationRequest OPCIONAL. El ámbito de la solicitud de acceso.
OAuth2Scope_ImplicitGrant_AuthorizationResponse OPCIONAL si es idéntico al ámbito solicitado por el cliente; de

OAuth2Scope_ResourceOwnerPasswordCredentialsGrant_Toke OPCIONAL. El ámbito de la solicitud de acceso.

nRequest
OAuth2Scope_ResourceOwnerPasswordCredentialsGrant_Toke OPCIONAL si es idéntico al ámbito solicitado por el cliente; de

nResponse lo contrario REQUERIDO.
OAuth2State_AuthorizationCodeGrant_AuthorizationErrorRes REQUERIDO si el parámetro "state" estaba presente en la

ponse solicitud de autorización de cliente. El valor exacto recibido del
cliente.
OAuth2State_AuthorizationCodeGrant_AuthorizationRequest RECOMENDADO. Un valor opaco que utiliza el cliente para

mantener el estado entre la solicitud y la devolución de
llamada. El servidor de autorización incluye este valor al
redirigir el agente de usuario al cliente. El parámetro debe
usarse para evitar la falsificación de solicitudes entre sitios.
OAuth2State_AuthorizationCodeGrant_AuthorizationRespons REQUERIDO si el parámetro "state" estaba presente en la

e solicitud de autorización de cliente. El valor exacto recibido del
cliente.
OAuth2State_ImplicitGrant_AuthorizationErrorResponse REQUERIDO si el parámetro "state" estaba presente en la

solicitud de autorización de cliente. El valor exacto recibido del
cliente.
NOMBRE TEX TO
OAuth2State_ImplicitGrant_AuthorizationRequest RECOMENDADO. Un valor opaco que utiliza el cliente para

mantener el estado entre la solicitud y la devolución de
llamada. El servidor de autorización incluye este valor al
redirigir el agente de usuario al cliente. El parámetro debe
usarse para evitar la falsificación de solicitudes entre sitios.
OAuth2State_ImplicitGrant_AuthorizationResponse REQUERIDO si el parámetro "state" estaba presente en la

solicitud de autorización de cliente. El valor exacto recibido del
cliente.
OAuth2TokenType_AuthorizationCodeGrant_TokenResponse REQUERIDO. El tipo del token emitido.
OAuth2TokenType_ClientCredentialsGrant_TokenResponse REQUERIDO. El tipo del token emitido.
OAuth2TokenType_ImplicitGrant_AuthorizationResponse REQUERIDO. El tipo del token emitido.
OAuth2TokenType_ResourceOwnerPasswordCredentialsGrant REQUERIDO. El tipo del token emitido.

_TokenResponse
OAuth2UserName_ResourceOwnerPasswordCredentialsGrant_ REQUERIDO. El nombre de usuario del propietario del recurso.

TokenRequest
OAuth2UnsupportedTokenType El tipo de token "{0}" no se admite.
OAuth2InvalidState Respuesta no válida del servidor de autorización
OAuth2GrantType_AuthorizationCode Código de autorización
OAuth2GrantType_Implicit Implícita
OAuth2GrantType_ClientCredentials Credenciales de cliente
OAuth2GrantType_ResourceOwnerPassword Contraseña del propietario del recurso
WebDocumentation302Code 302 (encontrado)
WebDocumentation400Code 400 (solicitud incorrecta)
OAuth2SendingMethod_AuthHeader Encabezado de autorización
OAuth2SendingMethod_QueryParam Parámetro de consulta
OAuth2AuthorizationServerGeneralException Se ha producido un error al autorizar el acceso a través de {0}.
OAuth2AuthorizationServerCommunicationException No se ha podido establecer una conexión HTTP con el servidor

de autorización o se ha interrumpido de forma inesperada.
WebDocumentationOAuth2GeneralErrorMessage Se ha producido un error inesperado.
AuthorizationServerCommunicationException Se ha producido una excepción de comunicación con el

servidor de autorización. Póngase en contacto con el
administrador.
NOMBRE TEX TO
TextblockSubscriptionKeyHeaderDescription Clave de suscripción que proporciona acceso a esta API. Se

encontró en el <a href='/developer'>perfil</a>.
TextblockOAuthHeaderDescription Token de acceso OAuth 2.0 obtenido de <i>{0}</i>. Tipos de

concesión admitidos: <i>{1}</i>.
TextblockContentTypeHeaderDescription Tipo de soporte del cuerpo enviado a la API.
ErrorMessageApiNotAccessible A la API a la que está tratando de llamar no se puede acceder

en este momento. Póngase en contacto con el publicador de
la API <a href="/issues">aquí</a>.
ErrorMessageApiTimedout La API a la que está tratando de llamar está tardando más de

lo normal en devolver una respuesta. Póngase en contacto
con el publicador de la API <a href="/issues">aquí</a>.
BadRequestParameterExpected "Se espera el parámetro '{0}'"
TooltipTextDoubleClickToSelectAll Haga doble clic para seleccionarlo todo.
TooltipTextHideRevealSecret Mostrar/ocultar
ButtonLinkOpenConsole Pruébelo
SectionHeadingRequestBody Cuerpo de la solicitud
SectionHeadingRequestParameters Parámetros de solicitud
SectionHeadingRequestUrl URL de la solicitud
SectionHeadingResponse Response
SectionHeadingRequestHeaders Encabezados de solicitud
FormLabelSubtextOptional opcional
SectionHeadingCodeSamples Ejemplos de código
TextblockOpenidConnectHeaderDescription Token de identificador de OpenID Connect obtenido de <i>{0}

</i>. Tipos de concesión admitidos: <i>{1}</i>.
ErrorPageStrings
NOMBRE TEX TO
LinkLabelBack atrás
LinkLabelHomePage página principal
LinkLabelSendUsEmail Envíenos un correo electrónico

NOMBRE TEX TO
PageTitleError Lo sentimos, se ha producido un problema al mostrar la

página solicitada.
TextblockPotentialCauseIntermittentIssue Esto puede ser un problema de acceso a los datos

intermitente que ya ha pasado.
TextblockPotentialCauseOldLink El vínculo en el que ha hecho clic puede ser antiguo y no

apuntar ya al sitio correcto.
TextblockPotentialCauseTechnicalProblem Es posible que haya un problema técnico por nuestra parte.
TextblockPotentialSolutionRefresh Pruebe a actualizar la página.
TextblockPotentialSolutionStartOver Empiece de nuevo desde nuestro {0}.
TextblockPotentialSolutionTryAgain Vaya a {0} e intente de nuevo la acción que realizó.
TextReportProblem {0} en el que se describa el error y lo analizaremos lo antes

posible.
TitlePotentialCause Causa posible
TitlePotentialSolution Es posible que se trate únicamente de un problema temporal.

Hay varias soluciones que puede probar.
IssuesStrings
NOMBRE TEX TO
WebIssuesIndexTitle Problemas
WebIssuesNoActiveSubscriptions No tiene ninguna suscripción activa. Debe suscribirse a un

producto para informar de un problema.
WebIssuesNotSignin No ha iniciado sesión. {0} para informar de un problema o

publicar un comentario.
WebIssuesReportIssueButton Informar sobre un problema
WebIssuesSignIn iniciar sesión
WebIssuesStatusReportedBy Estado: {0} | notificado por {1}
NotFoundStrings
NOMBRE TEX TO
LinkLabelHomePage página principal
LinkLabelSendUsEmail envíenos un correo electrónico
PageTitleNotFound No encontramos la página que busca.

NOMBRE TEX TO
TextblockPotentialCauseMisspelledUrl Es posible que haya escrito mal la URL si la ha especificado a

mano.
TextblockPotentialCauseOldLink El vínculo en el que ha hecho clic puede ser antiguo y no

apuntar ya al sitio correcto.
TextblockPotentialSolutionRetype Pruebe a volver a escribir la URL.
TextblockPotentialSolutionStartOver Empiece de nuevo desde nuestro {0}.
TextReportProblem {0} en el que se describa el error y lo analizaremos lo antes

posible.
TitlePotentialCause Causa posible
TitlePotentialSolution Posible solución
ProductDetailsStrings
NOMBRE TEX TO
WebProductsAgreement Al suscribirse al producto {0}, acepta los

<a data-toggle='modal' href='#legal-terms'\>Terms of
Use</a\>
.
WebProductsLegalTermsLink Términos de uso
WebProductsSubscribeButton Suscribirse
WebProductsUsageLimitsHeader Límites de uso
WebProductsYouAreNotSubscribed Está suscrito a este producto.
WebProductsYouRequestedSubscription Ha solicitado una suscripción a este producto.
ErrorYouNeedToAgreeWithLegalTerms Debe aceptar los términos de uso antes de continuar.
ButtonLabelAddSubscription Agregar suscripción
LinkLabelChangeSubscriptionName cambiar
ButtonLabelConfirm Confirm
TextblockMultipleSubscriptionsCount Tiene {0} suscripciones a este producto:
TextblockSingleSubscriptionsCount Tiene {0} suscripción a este producto:
TextblockSingleApisCount Este producto contiene {0} API:
TextblockMultipleApisCount Este producto contiene {0} API:

NOMBRE TEX TO
TextblockHeaderSubscribe Suscribirse al producto
TextblockSubscriptionDescription Se creará una nueva suscripción de la siguiente manera:
TextblockSubscriptionLimitReached Ha alcanzado el límite de suscripciones.
ProductsStrings
NOMBRE TEX TO
PageTitleProducts Productos
ProviderInfoStrings
NOMBRE TEX TO
TextboxExternalIdentitiesDisabled Los administradores han deshabilitado el inicio de sesión

actualmente.
TextboxExternalIdentitiesSigninInvitation O bien inicie sesión con
TextboxExternalIdentitiesSigninInvitationPrimary Inicie sesión con:
SigninResources
NOMBRE TEX TO
PrincipalNotFound No se encuentra la entidad de seguridad o la firma no es

válida.
ErrorSsoAuthenticationFailed Error de autenticación SSO.
ErrorSsoAuthenticationFailedDetailed Se ha proporcionado un token no válido o no se ha podido

comprobar la firma.
ErrorSsoTokenInvalid El token SSO no es válido.
ValidationErrorSpecificEmailAlreadyExists El correo electrónico "{0}" ya está registrado.
ValidationErrorSpecificEmailInvalid El correo electrónico "{0}" no es válido.
ValidationErrorPasswordInvalid La contraseña no es válida. Corrija los errores y vuelva a

intentarlo.
PropertyTooShort La propiedad {0} es demasiado corta.
WebAuthenticationAddresserEmailInvalidErrorMessage La dirección de correo electrónico no es válida.
ValidationMessageNewPasswordConfirmationRequired Confirme la nueva contraseña.
ValidationErrorPasswordConfirmationRequired El campo de la contraseña de confirmación está vacío.

NOMBRE TEX TO
WebAuthenticationEmailChangeNotice El mensaje de correo electrónico de confirmación del cambio

va de camino a {0}. Siga las instrucciones incluidas en él para
confirmar la nueva dirección de correo electrónico. Si no recibe
el correo electrónico en su bandeja de entrada en los próximos
minutos, consulte su carpeta de correo no deseado.
WebAuthenticationEmailChangeNoticeHeader Se ha procesado correctamente la solicitud de cambio de

correo electrónico.
WebAuthenticationEmailChangeNoticeTitle Cambio de correo electrónico solicitado
WebAuthenticationEmailHasBeenRevertedNotice Su dirección de correo electrónico ya existe. Se ha revertido la

solicitud.
ValidationErrorEmailAlreadyExists La dirección de correo electrónico ya existe.
ValidationErrorEmailInvalid Dirección de correo electrónico no válida
TextboxLabelEmail Email
ValidationErrorEmailRequired Debe especificar un correo electrónico.
WebAuthenticationErrorNoticeHeader Error
WebAuthenticationFieldLengthErrorMessage {0} debe tener una extensión máxima de {1}
TextboxLabelEmailFirstName Nombre
ValidationErrorFirstNameRequired Debe especificar un nombre.
ValidationErrorFirstNameInvalid Nombre no válido
NoticeInvalidInvitationToken Tenga en cuenta que los vínculos de confirmación solo son

válidos durante 48 horas. Si aún no ha superado ese plazo,
asegúrese de que el vínculo sea correcto. Si ha expirado el
vínculo, repita la acción que trata de confirmar.
NoticeHeaderInvalidInvitationToken Token de invitación no válido
NoticeTitleInvalidInvitationToken Correo electrónico de confirmación
WebAuthenticationLastNameInvalidErrorMessage Apellidos no válidos
TextboxLabelEmailLastName Apellidos
ValidationErrorLastNameRequired Debe especificar un apellido.
WebAuthenticationLinkExpiredNotice El vínculo de confirmación que se le ha enviado ha expirado.

<a href={0}?token={1}>Resend confirmation email.
</a\>
NOMBRE TEX TO
NoticePasswordResetLinkInvalidOrExpired El vínculo de restablecimiento de la contraseña no es válido o

ha expirado.
WebAuthenticationLinkExpiredNoticeTitle Vínculo enviado
WebAuthenticationNewPasswordLabel Contraseña nueva
ValidationMessageNewPasswordRequired Se requiere una nueva contraseña.
TextboxLabelNotificationsSenderEmail Correo electrónico del remitente de las notificaciones
TextboxLabelOrganizationName Nombre de la organización
WebAuthenticationOrganizationRequiredErrorMessage El campo del nombre de la organización está vacío.
WebAuthenticationPasswordChangedNotice La contraseña se ha actualizado correctamente.
WebAuthenticationPasswordChangedNoticeTitle Contraseña actualizada
WebAuthenticationPasswordCompareErrorMessage Las contraseñas no coinciden.
WebAuthenticationPasswordConfirmLabel Confirmar contraseña
ValidationErrorPasswordInvalidDetailed La contraseña es demasiado poco segura.
WebAuthenticationPasswordLabel Contraseña
ValidationErrorPasswordRequired Se requiere una contraseña.
WebAuthenticationPasswordResetSendNotice El mensaje de correo electrónico de confirmación del cambio

de contraseña va de camino a {0}. Siga las instrucciones
incluidas en el mensaje de correo electrónico para continuar
con el proceso de cambio de la contraseña.
WebAuthenticationPasswordResetSendNoticeHeader La solicitud de restablecimiento de contraseña se ha

procesado correctamente.
WebAuthenticationPasswordResetSendNoticeTitle Se solicitó el restablecimiento de contraseña.
WebAuthenticationRequestNotFoundNotice Solicitud no encontrada
WebAuthenticationSenderEmailRequiredErrorMessage El campo del correo electrónico del remitente de las

notificaciones está vacío.
WebAuthenticationSigninPasswordLabel Confirme el cambio especificando una contraseña.
WebAuthenticationSignupConfirmNotice Se ha enviado un correo electrónico de confirmación del

registro a {0}.<br /> Siga las instrucciones incluidas en el
correo electrónico para activar la cuenta.<br /> Si no recibe el
correo electrónico en la bandeja de entrada en los próximos
minutos, consulte la carpeta de correo no deseado.
NOMBRE TEX TO
WebAuthenticationSignupConfirmNoticeHeader La cuenta se ha creado correctamente.
WebAuthenticationSignupConfirmNoticeRepeatHeader Se ha vuelto a enviar el mensaje de correo electrónico de

confirmación de registro.
WebAuthenticationSignupConfirmNoticeTitle Cuenta creada
WebAuthenticationTokenRequiredErrorMessage El token está vacío.
WebAuthenticationUserAlreadyRegisteredNotice Parece que ya hay un usuario con esa dirección de correo

electrónico registrado en el sistema. Si ha olvidado la
contraseña, intente restaurarla o póngase en contacto con
nuestro equipo de soporte técnico.
WebAuthenticationUserAlreadyRegisteredNoticeHeader El usuario ya está registrado.
WebAuthenticationUserAlreadyRegisteredNoticeTitle Ya registrado
ButtonLabelChangePassword Cambiar contraseña
ButtonLabelChangeAccountInfo Cambiar información de la cuenta
ButtonLabelCloseAccount Cerrar cuenta
WebAuthenticationInvalidCaptchaErrorMessage El texto escrito no coincide con el de la imagen. Vuelva a

intentarlo.
ValidationErrorCredentialsInvalid El correo electrónico o la contraseña no son válidos. Corrija los

errores y vuelva a intentarlo.
WebAuthenticationRequestIsNotValid La solicitud no es válida.
WebAuthenticationUserIsNotConfirm Confirme el registro antes de tratar de iniciar sesión.
WebAuthenticationInvalidEmailFormated El correo electrónico no es válido: {0}
WebAuthenticationUserNotFound Usuario no encontrado
WebAuthenticationTenantNotRegistered La cuenta pertenece a un inquilino de Azure Active Directory

que no está autorizado para acceder a este portal.
WebAuthenticationAuthenticationFailed Error de autenticación.
WebAuthenticationGooglePlusNotEnabled Error de autenticación. Si ha autorizado la aplicación, póngase

en contacto con el administrador para asegurarse de que la
autenticación de Google está configurada correctamente.
ValidationErrorAllowedTenantIsRequired Se requiere un inquilino permitido.
ValidationErrorTenantIsNotValid El inquilino de Azure Active Directory "{0}" no es válido.
WebAuthenticationActiveDirectoryTitle Azure Active Directory

NOMBRE TEX TO
WebAuthenticationLoginUsingYourProvider Inicie sesión con la cuenta de {0}.
WebAuthenticationUserLimitNotice Este servicio ha alcanzado el número máximo de usuarios

permitidos.
<a href="mailto:{0}"\>contact the administrator</a\>
para actualizar su servicio y volver a habilitar el registro de
usuarios.
WebAuthenticationUserLimitNoticeHeader Registro de usuarios deshabilitado
WebAuthenticationUserLimitNoticeTitle Registro de usuarios deshabilitado
WebAuthenticationUserRegistrationDisabledNotice El administrador ha deshabilitado el registro de usuarios. Inicie

sesión con el proveedor de identidades externo.
WebAuthenticationUserRegistrationDisabledNoticeHeader Registro de usuarios deshabilitado
WebAuthenticationUserRegistrationDisabledNoticeTitle Registro de usuarios deshabilitado
WebAuthenticationSignupPendingConfirmationNotice Para poder completar la creación de su cuenta, tenemos que

comprobar su dirección de correo electrónico. Hemos enviado
un mensaje de correo electrónico a {0}. Siga las instrucciones
incluidas en el mensaje de correo electrónico para activar su
cuenta. Si no le llega el mensaje de correo electrónico en unos
minutos, consulte su carpeta de correo no deseado.
WebAuthenticationSignupPendingConfirmationAccountFound Se ha encontrado una cuenta no confirmada para la dirección

Notice de correo electrónico {0}. Para completar la creación de su
cuenta, tenemos que comprobar su dirección de correo
electrónico. Hemos enviado un mensaje de correo electrónico
a {0}. Siga las instrucciones incluidas en el mensaje de correo
electrónico para activar su cuenta. Si no le llega el mensaje de
correo electrónico en unos minutos, consulte su carpeta de
correo no deseado.
WebAuthenticationSignupConfirmationAlmostDone Casi ha terminado.
WebAuthenticationSignupConfirmationEmailSent Hemos enviado un mensaje de correo electrónico a {0}. Siga

las instrucciones incluidas en el mensaje de correo electrónico
para activar su cuenta. Si no le llega el mensaje de correo
electrónico en unos minutos, consulte su carpeta de correo no
deseado.
WebAuthenticationEmailSentNotificationMessage Se ha enviado un mensaje de correo electrónico

correctamente a {0}.
WebAuthenticationNoAadTenantConfigured No hay ningún inquilino de Azure Active Directory

configurado para el servicio.
CheckboxLabelUserRegistrationTermsConsentRequired Acepto los

<a data-toggle="modal" href="#" data-
target="#terms"\>Terms of Use</a\>
.
NOMBRE TEX TO
TextblockUserRegistrationTermsProvided Revise los

<a data-toggle="modal" href="#" data-
target="#terms"\>Terms of Use.</a\>
.
DialogHeadingTermsOfUse Términos de uso
ValidationMessageConsentNotAccepted Debe aceptar los términos de uso antes de continuar.
SigninStrings
NOMBRE TEX TO
WebAuthenticationForgotPassword ¿Ha olvidado la contraseña?
WebAuthenticationIfAdministrator Si es administrador, debe iniciar sesión en

<a href="{0}"\>here</a\> .
WebAuthenticationNotAMember ¿Aún no es miembro?

<a href="/signup"\>Sign up now</a\>
WebAuthenticationRemember Recordarme en este equipo
WebAuthenticationSigininWithPassword Inicie sesión con su nombre de usuario y contraseña.
WebAuthenticationSigninTitle Iniciar sesión
WebAuthenticationSignUpNow Regístrese ahora
SignupStrings
NOMBRE TEX TO
PageTitleSignup Suscripción
WebAuthenticationAlreadyAMember ¿Ya es miembro?
WebAuthenticationCreateNewAccount Cree una nueva cuenta de API Management.
WebAuthenticationSigninNow Inicie sesión ahora
ButtonLabelSignup Suscripción
SubscriptionListStrings
NOMBRE TEX TO
SubscriptionCancelConfirmation ¿Está seguro de que desea cancelar esta suscripción?
SubscriptionRenewConfirmation ¿Está seguro de que desea renovar esta suscripción?
WebDevelopersManageSubscriptions Administrar suscripciones

NOMBRE TEX TO
WebDevelopersPrimaryKey Clave principal
WebDevelopersRegenerateLink Regenerar
WebDevelopersSecondaryKey Clave secundaria
ButtonLabelShowKey Presentación
ButtonLabelRenewSubscription Renovación
WebDevelopersSubscriptionRequested Solicitud realizada el {0}
WebDevelopersSubscriptionRequestedState Solicitada
WebDevelopersSubscriptionTableNameHeader NOMBRE
WebDevelopersSubscriptionTableStateHeader Estado
WebDevelopersUsageStatisticsLink Informes de análisis
WebDevelopersYourSubscriptions Sus suscripciones
SubscriptionPropertyLabelRequestedDate Solicitud realizada el
SubscriptionPropertyLabelStartedDate Iniciado el
PageTitleRenameSubscription Cambiar el nombre de la suscripción
SubscriptionPropertyLabelName Nombre de la suscripción
SubscriptionStrings
NOMBRE TEX TO
SectionHeadingCloseAccount ¿Desea para cerrar su cuenta?
PageTitleDeveloperProfile Perfil
ButtonLabelHideKey Ocultar
ButtonLabelRegenerateKey Regenerar
InformationMessageKeyWasRegenerated ¿Está seguro de que desea regenerar esta clave?
ButtonLabelShowKey Presentación
UpdateProfileStrings
NOMBRE TEX TO
ButtonLabelUpdateProfile Actualizar perfil

NOMBRE TEX TO
PageTitleUpdateProfile Actualizar información de cuenta
UserProfile
NOMBRE TEX TO
ButtonLabelChangeAccountInfo Cambiar información de la cuenta
ButtonLabelChangePassword Cambiar contraseña
ButtonLabelCloseAccount Cerrar cuenta
TextboxLabelEmail Email
TextboxLabelEmailFirstName Nombre
TextboxLabelEmailLastName Apellidos
TextboxLabelNotificationsSenderEmail Correo electrónico del remitente de las notificaciones
TextboxLabelOrganizationName Nombre de la organización
SubscriptionStateActive Active
SubscriptionStateCancelled Cancelado
SubscriptionStateExpired Expirada
SubscriptionStateRejected Rechazada
SubscriptionStateRequested Solicitada
SubscriptionStateSuspended Suspended
DefaultSubscriptionNameTemplate {0} (valor predeterminado)
SubscriptionNameTemplate Acceso de desarrollador n.º{0}
TextboxLabelSubscriptionName Nombre de la suscripción
ValidationMessageSubscriptionNameRequired El nombre de suscripción no puede estar vacío.
ApiManagementUserLimitReached Este servicio ha alcanzado el número máximo de usuarios

permitidos. Actualice a un plan de tarifa superior.
Recursos de glifo
Las plantillas del portal para desarrolladores de API Management puede usar los glifos de Glyphicons de
Bootstrap. Este conjunto de glifos incluye más de 250 glifos en formato de fuente del conjunto Glyphicon
Halflings. Para utilizar un glifo de este conjunto, utilice la siguiente sintaxis.
<span class="glyphicon glyphicon-user">
Para obtener la lista completa de glifos, consulte Glyphicons de Bootstrap.
Pasos siguientes
Referencia de modelo de datos de la plantilla de
Este tema describe las representaciones de entidad y tipo de elementos comunes que se usan en los modelos de
datos en las plantillas de portal para desarrolladores de Azure API Management.
Disponibilidad
IMPORTANT
El portal para desarrolladores no está disponible en el nivel Consumo.
Referencia
API
Resumen de API
Aplicación
Datos adjuntos
Código de ejemplo
Comment
Filtrado
Encabezado
Solicitud HTTP
Respuesta HTTP
Problema
operación
Menú de operaciones
Elemento de menú de operaciones
Paginación
Parámetro
Producto
Proveedor
Representación
Suscripción
Resumen de suscripción
Información de cuenta de usuario
Inicio de sesión de usuario
Registro de usuario
API
La entidad API tiene las siguientes propiedades:
id string Identificador de recursos. Identifica de

forma única la API de la instancia actual
del servicio API Management. El valor
es una dirección URL relativa válida con
el formato apis/{id} , donde {id}
es un identificador de API. Esta
propiedad es de solo lectura.
name string Nombre de la API. No debe estar vacía.

La longitud máxima es de 100
caracteres.
description string Descripción de la API. No debe estar

vacía. Puede incluir etiquetas de
formato HTML. La longitud máxima es
de 1000 caracteres.
serviceUrl string Dirección URL absoluta del servicio

back-end que implementa esta API.
path string Dirección URL relativa que identifica de

forma única esta API y todas las rutas
de acceso a sus recursos dentro de la
instancia del servicio API Management.
Se anexa a la dirección URL base del
punto de conexión de API que se
especificó durante la creación de la
instancia de servicio para formar una
dirección URL pública para esta API.
protocols matriz de número Describe en qué protocolos se pueden

invocar las operaciones en esta API. Los
valores permitidos son 1 - http y
2 - https , o ambos.
authenticationSettings Configuración de autenticación del Colección de ajustes de autenticación

servidor de autorización que se incluyen en esta API.
subscriptionKeyParameterNames objeto Propiedad opcional que puede utilizarse

para especificar nombres personalizados
para los parámetros de la consulta o
encabezado que contiene la clave de
suscripción. Cuando esta propiedad está
presente, debe contener al menos una
de las dos propiedades siguientes.
{
"subscriptionKeyParameterNames":
{ "query":
“customQueryParameterName",
"header":
“customHeaderParameterName" } }
Resumen de API
La entidad API summary tiene las siguientes propiedades:

forma única la API de la instancia actual
del servicio API Management. El valor
es una dirección URL relativa válida con
el formato apis/{id} , donde {id}
es un identificador de API. Esta
name string Nombre de la API. No debe estar vacía.

La longitud máxima es de 100
caracteres.
description string Descripción de la API. No debe estar

de 1000 caracteres.
Application
La entidad application tiene las siguientes propiedades:
Id string Identificador único de la aplicación.
Title string Título de la aplicación.
Description string Descripción de la aplicación.
Url URI Identificador URI de la aplicación.
Version string Información de versión de la aplicación.
Requirements string Descripción de los requisitos de la

aplicación.
State número Estado actual de la aplicación.
-0 - registrada
-1 - enviada
-2 - publicada
-3 - rechazada
-4 - no publicada
RegistrationDate Datetime Fecha y hora a las que se registró la

aplicación.
CategoryId número Categoría de la aplicación (finanzas,

entretenimiento, etcétera).
DeveloperId string Identificador único del desarrollador que

envió la aplicación.
Attachments Colección de entidades Attachment. Cualquier tipo de datos adjuntos de la

aplicación, como capturas de pantalla o
iconos.
Icon Datos adjuntos Icono de la aplicación.
Datos adjuntos
La entidad attachment tiene las siguientes propiedades:
UniqueId string Identificador único de los datos

adjuntos.
Url string Dirección URL del recurso.
Type string Tipo de datos adjuntos.
ContentType string Tipo de medios de los datos adjuntos.
Código de ejemplo
title string Nombre de la operación.
snippet string Esta propiedad está en desuso y no

debe utilizarse.
brush string Especifica qué plantilla de color de

sintaxis de código se usará al mostrar el
ejemplo de código. Los valores
permitidos son plain , php , java ,
xml , objc , python , ruby y
csharp .
template string Nombre de esta plantilla de ejemplo de

código.
body string Un marcador de posición para la parte

del ejemplo de código del fragmento de
código.
method string Método HTTP de la operación.

scheme string Protocolo que se debe usar en la

solicitud de operación.
path string Ruta de acceso de la operación.
query string Ejemplo de cadena de consulta con

parámetros definidos.
host string Dirección URL de la puerta de enlace del

servicio API Management para la API
que contiene esta operación.
headers Colección de entidades Header. Encabezados de esta operación.
parameters Colección de entidades Parameter. Los parámetros definidos para esta

operación.
Comment
La entidad API tiene las siguientes propiedades:
Id número Identificador del comentario.
CommentText string Cuerpo del comentario. Puede incluir

HTML.
DeveloperCompany string Nombre de la empresa del desarrollador.
PostedOn Datetime Fecha y hora de publicación del

comentario.
Issue
La entidad issue tiene las siguientes propiedades.
Id string Identificador único del problema.
ApiID string Identificador de la API sobre la que se

notificó este problema.
Title string Título del problema.
Description string Descripción del problema.
SubscriptionDeveloperName string Nombre del desarrollador que notificó el

problema.
IssueState string Estado actual del problema. Los valores

posibles son Proposed (Propuesto),
Opened (Abierto), Closed (Cerrado).
ReportedOn Datetime Fecha y hora a las que se notificó el

problema.
Comments Colección de entidades Comment. Comentarios sobre este problema.
Attachments Colección de entidades Attachment. Datos adjuntos al problema.
Services Colección de entidades API. Las API a las que está suscrito el usuario
que archivó el problema.
Filtrado
La entidad filtering tiene las siguientes propiedades:
Pattern string El término de búsqueda actual; o null

si no hay ningún término de búsqueda.
Placeholder string Texto que se muestra en el cuadro de

búsqueda cuando no hay ningún
término de búsqueda especificado.
Header
Esta sección describe la representación de parameter .
name string Nombre del parámetro.
description string Descripción del parámetro.
value string Valor del encabezado.
typeName string Tipo de datos del valor del encabezado.
options string Opciones.
required boolean Especifica si el encabezado es necesario.
readOnly boolean Especifica si el encabezado es de solo

lectura.
HTTP Request
Esta sección describe la representación de request .
description string Descripción de la solicitud de operación.
headers matriz de entidades Header. Encabezados de solicitud.
parameters matriz de Parameter Colección de parámetros de solicitud de

operación.
representations matriz de Representation Colección de representaciones de

solicitud de operación.
HTTP Response
Esta sección describe la representación de response .
statusCode número entero positivo Código de estado de la respuesta de la

operación.
description string Descripción de la respuesta de la

operación.
representations matriz de Representation Colección de representaciones de

respuesta de operación.
Operation
La entidad operation tiene las siguientes propiedades:

forma única la operación de la instancia
actual del servicio API Management. El
valor es una dirección URL relativa
válida con el formato
apis/{aid}/operations/{id} , donde
{aid} es un identificador de API y
{id} es un identificador de operación.
Esta propiedad es de solo lectura.
name string Nombre de la operación. No debe estar

vacía. La longitud máxima es de 100
caracteres.
description string Descripción de la operación. No debe

estar vacía. Puede incluir etiquetas de
de 1000 caracteres.
scheme string Describe en qué protocolos se pueden

invocar las operaciones en esta API. Los
valores permitidos son http , https
o tanto http como https .
uriTemplate string Plantilla de dirección URL relativa

identifica el recurso de destino para esta
operación. Puede incluir parámetros.
Ejemplo:
customers/{cid}/orders/{oid}/?
date={date}
host string Dirección URL de la puerta de enlace de

API Management que hospeda la API.
httpMethod string Método HTTP de la operación.
request Solicitud HTTP Una entidad que contiene los detalles

de la solicitud.
responses matriz de HTTP Response Matriz de entidades HTTP Response de

la operación.
Menú de operaciones
La entidad operation menu tiene las siguientes propiedades:
ApiId string Identificador de la API actual.
CurrentOperationId string Identificador de la operación actual.
Action string Tipo de menú.
MenuItems Colección de entidades Operation menu Operaciones de la API actual.

item.
Elemento de menú de operaciones

La entidad operation menu item tiene las siguientes propiedades:
Id string Identificador de la operación.
Title string Descripción de la operación.
HttpMethod string Método HTTP de la operación.
Paginación
La entidad paging tiene las siguientes propiedades:
Page número Número de página actual.
PageSize número Número máximo de resultados que se

mostrarán en una misma página.
TotalItemCount número Número de elementos que se muestran.
ShowAll boolean Especifica si se deben mostrar todos los

resultados en una misma página.
PageCount número Número de páginas de resultados.
Parameter
Esta sección describe la representación de parameter .
name string Nombre del parámetro.
description string Descripción del parámetro.
value string Valor del parámetro.
options matriz de cadena Valores definidos para los valores de

parámetro de consulta.
required boolean Especifica si el parámetro es necesario o

no.
kind número Determina si este parámetro es un

parámetro de ruta de acceso (1) o un
parámetro de cadena de consulta (2).
typeName string Tipo de parámetro.
Product
La entidad product tiene las siguientes propiedades:
Id string Identificador de recursos. Identifica de

forma única el producto en la instancia
actual del servicio API Management. El
valor es una dirección URL relativa
válida con el formato products/{pid} ,
donde {pid} es un identificador de
producto. Esta propiedad es de solo
lectura.
Title string Nombre del producto. No debe estar

caracteres.
Description string Descripción del producto. No debe estar

de 1000 caracteres.
Terms string Términos de uso del producto. Los

desarrolladores que traten de
suscribirse al producto verán y deberán
aceptar estos términos para poder
completar el proceso de suscripción.
ProductState número Especifica si el producto se ha publicado

o no. Los desarrolladores pueden
consultar los productos publicados en el
portal para desarrolladores. Solo los
administradores pueden ver los
productos que no se han publicado.
Los valores de estado del producto

permitidos son:
- 0 - Not Published
- 1 - Published
- 2 - Deleted
AllowMultipleSubscriptions boolean Especifica si un usuario puede tener

varias suscripciones a este producto al
mismo tiempo.
MultipleSubscriptionsCount número Número máximo de suscripciones a este

producto que un usuario puede tener al
mismo tiempo.
Provider
La entidad provider tiene las siguientes propiedades:
Properties diccionario de cadenas Propiedades de este proveedor de

autenticación.
AuthenticationType string Tipo de proveedor. (Azure Active

Directory, inicio de sesión de Facebook,
cuenta de Google, cuenta de Microsoft,
Twitter).
Caption string Nombre para mostrar del proveedor.
Representación
Representación
En esta sección se describe representation .
contentType string Especifica un tipo de contenido

personalizado o registrado para esta
representación, por ejemplo,
application/xml .
sample string Un ejemplo de la representación.
Subscription
La entidad subscription tiene las siguientes propiedades:

forma única la suscripción de la
instancia actual del servicio API
Management. El valor es una dirección
URL relativa válida con el formato
subscriptions/{sid} , donde {sid}
es un identificador de suscripción. Esta
ProductId string El identificador de recurso de producto

del producto suscrito. El valor es una
dirección URL relativa válida con el
formato products/{pid} , donde
{pid} es un identificador de producto.
ProductTitle string Nombre del producto. No debe estar

caracteres.
ProductDescription string Descripción del producto. No debe estar

de 1000 caracteres.
ProductDetailsUrl string Dirección URL relativa a los detalles del

producto.
state string Estado de la suscripción. Los estados

posibles son:
- 0 - suspended : la suscripción está

bloqueada y el suscriptor no puede
llamar a ninguna API del producto.
- 1- active : la suscripción está

activa.
- 2 - expired : la suscripción ha
alcanzado su fecha de expiración y se ha
desactivado.
- 3 - submitted : el desarrollador ha
realizado una solicitud de suscripción,
pero esta aún no se ha aprobado ni
rechazado.
- 4 - rejected : un administrador ha
rechazado la solicitud de suscripción.
- 5 - cancelled : el desarrollador o el
administrador han cancelado la
suscripción.
DisplayName string Nombre para mostrar de la suscripción.
CreatedDate dateTime Fecha en la que se creó la suscripción,

en formato ISO 8601:
2014-06-24T16:25:00Z .
CanBeCancelled boolean Especifica si el usuario actual puede

cancelar la suscripción.
IsAwaitingApproval boolean Especifica si la suscripción está en

espera de aprobación.
StartDate dateTime Fecha de inicio de la suscripción, en

formato ISO 8601:
2014-06-24T16:25:00Z .
ExpirationDate dateTime Fecha de expiración de la suscripción, en

formato ISO 8601:
2014-06-24T16:25:00Z .
NotificationDate dateTime Fecha de notificación de la suscripción,

en formato ISO 8601:
2014-06-24T16:25:00Z .
primaryKey string Clave de suscripción principal. La

longitud máxima es de 256 caracteres.
secondaryKey string Clave de suscripción secundaria. La

CanBeRenewed boolean Especifica si el usuario actual puede

renovar la suscripción.
HasExpired boolean Especifica si la suscripción ha expirado.
IsRejected boolean Especifica si la solicitud de suscripción

ha sido denegada.
CancelUrl string La dirección URL relativa para cancelar

la suscripción.
RenewUrl string La dirección URL relativa para renovar la

suscripción.
Resumen de suscripción
La entidad subscription summary tiene las siguientes propiedades:

forma única la suscripción de la
instancia actual del servicio API
Management. El valor es una dirección
URL relativa válida con el formato
subscriptions/{sid} , donde {sid}
es un identificador de suscripción. Esta
DisplayName string Nombre para mostrar de la suscripción.
Información de cuenta de usuario

La entidad user account info tiene las siguientes propiedades:
FirstName string Nombre. No debe estar vacía. La

LastName string Apellidos. No debe estar vacía. La

Email string Dirección de correo electrónico. No

debe estar vacía y debe ser única dentro
de la instancia de servicio. La longitud
máxima es de 254 caracteres.
Password string Contraseña de la cuenta de usuario.
NameIdentifier string Identificador de cuenta, es igual al

correo electrónico del usuario.
ProviderName string Nombre del proveedor de autenticación.
IsBasicAccount boolean Es True si esta cuenta se registró

mediante un correo electrónico y una
contraseña; False si la cuenta se registró
con un proveedor.
Inicio de sesión de usuario

La entidad user sign in tiene las siguientes propiedades:

ReturnUrl string Dirección URL de la página donde el

usuario hizo clic en el vínculo de inicio
de sesión.
RememberMe boolean Especifica si se desea guardar la

información del usuario actual.
RegistrationEnabled boolean Especifica si el registro se ha habilitado.
DelegationEnabled boolean Especifica si está habilitado el inicio de

sesión delegado.
DelegationUrl string Dirección URL de inicio de sesión

delegado, si está habilitado.
SsoSignUpUrl string Inicio de sesión único en la dirección

URL del usuario, si está presente.
AuxServiceUrl string Si el usuario actual es un administrador,

esto es un vínculo a la instancia de
servicio en Azure Portal.
Providers Colección de entidades Provider. Los proveedores de autenticación de

este usuario.
UserRegistrationTerms string Condiciones que un usuario debe

aceptar para poder iniciar sesión.
UserRegistrationTermsEnabled boolean Especifica si las condiciones están

habilitadas.
Suscripción de usuario
La entidad user sign up tiene las siguientes propiedades:
PasswordConfirm boolean Valor utilizado por el control de inicio de

sesión sign-up.
PasswordVerdictLevel número Valor utilizado por el control de inicio de

sesión sign-up.
UserRegistrationTerms string Condiciones que un usuario debe

aceptar para poder iniciar sesión.
UserRegistrationTermsOptions número Valor utilizado por el control de inicio de

sesión sign-up.
ConsentAccepted boolean Valor utilizado por el control de inicio de

sesión sign-up.

FirstName string Nombre. No debe estar vacía. La

LastName string Apellidos. No debe estar vacía. La

UserData string Valor utilizado por el control de sign-up.
NameIdentifier string Valor utilizado por el control de inicio de

sesión sign-up.
ProviderName string Nombre del proveedor de autenticación.
Pasos siguientes
Controles de página de Azure API
Management
Azure API Management proporciona los siguientes controles para su uso en las plantillas del portal
Para usar un control, colóquelo en la ubicación deseada en la plantilla del portal para
desarrolladores. Algunos controles, como el control app-actions, tienen parámetros, como se
muestra en el ejemplo siguiente:
Los valores de los parámetros se pasan como parte del modelo de datos de la plantilla. En la
mayoría de los casos, puede pegarlos simplemente en el ejemplo proporcionado para cada control
para que funcione correctamente. Para más información sobre los valores de parámetros, puede
ver la sección del modelo de datos de cada plantilla en la que se puede usar un control.
Para más información sobre cómo trabajar con plantillas, consulte Cómo personalizar el portal
para desarrolladores de API Management mediante plantillas.
Disponibilidad
IMPORTANT
Esta característica está disponible en los niveles Premium, Estándar, Básico y Desarrollador de API
Management.
Controles de página de las plantillas del portal para

desarrolladores
app-actions
basic-signin
paging-control
providers
search-control
sign-up
subscribe-button
subscription-cancel
app-actions
El control app-actions proporciona una interfaz de usuario para la interacción con aplicaciones en
la página del perfil de usuario del portal para desarrolladores.
Uso
Parámetros
PARÁMETRO DESCRIPCIÓN
appId Identificador de la aplicación.

El control app-actions se puede usar en las siguientes plantillas del portal para desarrolladores:
Aplicaciones
basic-signin
El control basic-signin ofrece un control para la recolección de información de inicio de sesión del
usuario en la página de inicio de sesión del portal para desarrolladores.
Uso
<basic-SignIn></basic-SignIn>
Parámetros
Ninguno.
El control basic-signin se puede usar en las siguientes plantillas del portal para desarrolladores:
Sign in
paging-control
El control paging-control proporciona funcionalidad de paginación en las páginas del portal para
desarrolladores que muestran una lista de elementos.
Uso
Parámetros
Ninguno.
El control paging-control se puede usar en las siguientes plantillas del portal para desarrolladores:
API list
Issue list
Product list
providers
El control providers proporciona un control para la selección de proveedores de autenticación en
la página de inicio de sesión del portal para desarrolladores.
Uso
<providers></providers>
Parámetros
Ninguno.
El control providers se puede usar en las siguientes plantillas del portal para desarrolladores:
Sign in
search-control
El control search-control proporciona funcionalidad de búsqueda en las páginas del portal para
desarrolladores que muestran una lista de elementos.
Uso
Parámetros
Ninguno.
El control search-control se puede usar en las siguientes plantillas del portal para desarrolladores:
API list
Product list
sign-up
El control sign-up proporciona un control para la recolección de información de perfil de usuario
en la página de inicio de sesión del portal para desarrolladores.
Uso
<sign-up></sign-up>
Parámetros
Ninguno.
El control sign-up se puede usar en las siguientes plantillas del portal para desarrolladores:
Sign up
subscribe-button
El control subscribe-button proporciona un control para la suscripción de un usuario a un
producto.
Uso
<subscribe-button></subscribe-button>
Parámetros
Ninguno.
El control subscribe-button se puede usar en las siguientes plantillas del portal para
desarrolladores:
Producto
subscription-cancel
El control subscription-cancel proporciona un control para la cancelación de una suscripción a un
producto en la página de perfil de usuario del portal para desarrolladores.
Uso
<subscription-cancel params="{ subscriptionId: '{{subscription.id}}', cancelUrl:

'{{subscription.cancelUrl}}' }">
</subscription-cancel>
Parámetros
PARÁMETRO DESCRIPCIÓN
subscriptionId Identificador de la suscripción para cancelar.
cancelUrl Dirección URL de cancelación de la suscripción.

El control subscription-cancel se puede usar en las siguientes plantillas del portal para
desarrolladores:
Producto
Pasos siguientes
Para más información sobre cómo trabajar con plantillas, consulte Cómo personalizar el portal
para desarrolladores de API Management mediante plantillas.
Creación y uso de grupos para administrar cuentas
de desarrollador en Azure API Management
En Administración de API, los grupos se usan para administrar la visibilidad de productos para los
desarrolladores. Los productos son visibles en primer lugar para los grupos y luego los desarrolladores de dichos
grupos pueden ver y suscribirse a los productos asociados a los grupos.
API Management tiene los siguientes grupos invariables del sistema:
Administradores : los administradores de la suscripción de Azure son miembros de este grupo. Los
administradores controlan las instancias del servicio Administración de API y crean las API, las operaciones y
los productos que usan los desarrolladores.
Desarrolladores : los usuarios del portal para desarrolladores autenticados se incluyen en este grupo. Los
desarrolladores son los clientes que compilan aplicaciones con sus API. Los desarrolladores, después de que se
les concede acceso al portal para desarrolladores, crean aplicaciones que llaman a las operaciones de una API.
Invitados : a este grupo pertenecen los usuarios del portal para desarrolladores no autenticados como, por
ejemplo, clientes potenciales que visitan el portal para desarrolladores de una instancia de API Management.
Se les concede determinado acceso de solo lectura, como por ejemplo la posibilidad de ver API pero no
llamarlas.
Además de estos grupos del sistema, los administradores pueden crear grupos personalizados o aprovechar los
grupos externos en inquilinos de Azure Active Directory asociados. Los grupos personalizados y externos pueden
usarse junto con grupos del sistema en la concesión a los desarrolladores de visibilidad y acceso a productos de la
API. Por ejemplo, podría crear un grupo personalizado para los desarrolladores afiliados a una organización
asociada específica y permitirles el acceso a las API a partir de un producto que contenga solo las API relevantes.
Un usuario puede ser miembro de más de un grupo.
En esta guía se muestra cómo los administradores de una instancia de API Management pueden agregar nuevos
grupos y asociarlos a productos y desarrolladores.
Además de crear y administrar grupos en el portal del editor, puede crear y administrar sus grupos mediante la
entidad de grupo de la API de REST de administración.
Disponibilidad
IMPORTANT
Requisitos previos
Complete las tareas de este artículo: Creación de una instancia de Azure API Management.

TIP
Creación de un grupo
En esta sección se explica cómo agregar un nuevo grupo a la cuenta de API Management.
1. Seleccione la pestaña Grupos a la izquierda de la pantalla.
2. Haga clic en +Agregar.
3. Especifique un nombre único para el grupo y una descripción opcional.
4. Pulse Crear.
Una vez creado el grupo, se agrega a la lista Grupos.
Para editar el Nombre o la Descripción del grupo, haga clic en el nombre del grupo y en Configuración.
Para eliminar el grupo, haga clic en el nombre del grupo y después en Eliminar.
Ahora que se ha creado el grupo, se puede asociar a productos y desarrolladores.
Asociación de un grupo a un producto

1. Seleccione la pestaña Productos a la izquierda.
2. Haga clic en el nombre del producto deseado.
3. Haga clic en Control de acceso.
4. Haga clic en + Agregar grupo.
5. Seleccione el grupo que desea agregar.

Para quitar un grupo del producto, haga clic en Eliminar.
Una vez asociado un producto a un grupo, los desarrolladores del grupo pueden ver el producto y suscribirse a él.
NOTE
Para agregar grupos de Azure Active Directory, consulte Autorización de las cuentas de desarrollador con Azure Active
Directory en Azure API Management.
Asociación de grupos a desarrolladores

En esta sección se explica cómo asociar grupos con miembros.
1. Seleccione la pestaña Grupos a la izquierda de la pantalla.
2. Seleccione Miembros.
3. Haga clic en + Agregar y seleccione un miembro.

Una vez agregada, la asociación entre el desarrollador y el grupo se puede ver en la pestaña Usuarios .
Pasos siguientes
Una vez agregado a un grupo, un desarrollador puede ver los productos asociados al grupo y suscribirse a
ellos. Para obtener más información, consulte Creación y publicación de un producto en Azure API
Management.
Además de crear y administrar grupos en el portal del editor, puede crear y administrar sus grupos mediante la
entidad de grupo de la API de REST de administración.
Implementación de una instancia del servicio Azure
API Management en varias regiones de Azure
Azure API Management admite la implementación en varias regiones, lo que permite a los publicadores de API
distribuir un único servicio Azure API Management en el número de regiones de Azure deseado. Esto ayuda a
reducir la latencia de solicitud que perciben los usuarios de API distribuidos geográficamente y, además, mejora
la disponibilidad del servicio en caso de que una región se quede sin conexión.
Inicialmente, un nuevo servicio Azure API Management contiene solo una unidad en una única región de Azure,
la región primaria. Pueden agregarse otras regiones fácilmente mediante Azure Portal. El servidor de puerta de
enlace de API Management se implementa en cada región y el tráfico de llamada se enruta a la puerta de enlace
más cercana en términos de latencia. Cuando una región se queda sin conexión, el tráfico se redirige
automáticamente a la siguiente puerta de enlace más cercana.
NOTE
Azure API Management replica solo el componente de la puerta de enlace de API entre regiones. El componente de
administración de servicio se hospeda solo en la región primaria. En caso de interrupción en la región primaria, no se
pueden aplicar cambios de configuración en una instancia del servicio Azure API Management, incluidas las configuraciones
y las actualizaciones de directivas.
Disponibilidad
IMPORTANT
Esta característica solo está disponible en el nivel Premium de API Management.
Implementación de una instancia del servicio Administración de API

en una nueva región
NOTE
Si todavía no ha creado una instancia del servicio API Management, consulte Creación de una instancia del servicio API
Management.
En Azure Portal, vaya a la página de escala y precios de su instancia de servicio de API Management.
Para implementar en una nueva región, haga clic en + Agregar región desde la barra de herramientas.
Seleccione la ubicación en la lista desplegable y establezca el número de unidades para el control deslizante.
Haga clic en Agregar para colocar la selección en la tabla de ubicaciones.

Repita este proceso hasta que haya configurado todas las ubicaciones y haga clic en Guardar en la barra de
herramientas para iniciar el proceso de implementación.
Eliminación de una instancia de servicio de API Management de una

ubicación
En Azure Portal, vaya a la página de escala y precios de su instancia de servicio de API Management.
Para la ubicación que desee eliminar, abra el menú contextual mediante el botón ... situado a la derecha de la
tabla. Haga clic en la opción Eliminar.
Confirme la eliminación y haga clic en Guardar para aplicar los cambios.
Enrutamiento de las llamadas API a servicios regionales back-end

Azure API Management incluye solo una dirección URL del servicio back-end. Aunque hay instancias de Azure
API Management en varias regiones, la puerta de enlace de API sigue reenviando las solicitudes al mismo
servicio back-end, que se implementa en una única región. En este caso, la ganancia de rendimiento procederá
solo de las respuestas en caché a la solicitud en Azure API Management de una región específica, pero también
puede generar una latencia alta al ponerse en contacto con el back-end de todo el mundo.
Para aprovechar completamente la distribución geográfica de su sistema, debe tener servicios back-end
implementados en las mismas regiones que las instancias de Azure API Management. A continuación, mediante
directivas y la propiedad @(context.Deployment.Region) puede enrutar el tráfico a las instancias locales de su
back-end.
1. Vaya a la instancia de Azure API Management y haga clic en API en el menú izquierdo.
2. Seleccione la API que desee.
3. Haga clic en el Editor de código de la flecha desplegable de Procesamiento de entrada.
4. Use set-backend en combinación con directivas choose condicionales para construir una directiva de
enrutamiento adecuada en la sección <inbound> </inbound> del archivo.
Por ejemplo, el siguiente archivo XML sería válido para las regiones Oeste de Estados Unidos y Asia
oriental:
<policies>
<inbound>
<base />
<choose>
<when condition="@("West US".Equals(context.Deployment.Region,
StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://contoso-us.com/" />
</when>
<when condition="@("East Asia".Equals(context.Deployment.Region,
StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://contoso-asia.com/" />
</when>
<otherwise>
<set-backend-service base-url="http://contoso-other.com/" />
</otherwise>
</choose>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
TIP
También puede adelantar sus servicios de back-end con Azure Traffic Manager, dirigir las llamadas de las API a
Traffic Manager y dejar que resuelva el enrutamiento automáticamente.
Uso del enrutamiento personalizado a puertas de enlace regionales de

API Management
API Management enruta las solicitudes a una puerta de enlace regional en función de la latencia más baja.
Aunque no es posible invalidar esta configuración en API Management, puede usar su propia instancia de
Traffic Manager con reglas de enrutamiento personalizadas.
1. Cree su propio perfil de Azure Traffic Manager.
2. Si usa un dominio personalizado, úselo con Traffic Manager y no con el servicio API Management.
3. Configuración de los puntos de conexión regionales de API Management en Traffic Manager. Los puntos de
conexión regionales siguen el patrón de dirección URL de
https://<service-name>-<region>-01.regional.azure-api.net , por ejemplo
https://contoso-westus2-01.regional.azure-api.net .
4. Configure los puntos de conexión de estado regional de API Management en Traffic Manager. Los puntos de
conexión de estado regional siguen el patrón de dirección URL de
https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef , por ejemplo
https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef .
5. Especifique el método de enrutamiento de Traffic Manager.
Cómo registrar eventos en Azure Event Hubs en
Azure Event Hubs es un servicio de introducción de datos altamente escalable que permite la introducción de
millones de eventos por segundo para que pueda procesar y analizar grandes cantidades de datos generados por
los dispositivos y aplicaciones conectados. Event Hubs actúa como la "puerta principal" de una canalización de
eventos y, una vez que los datos se recopilan en un centro de eventos, se pueden transformar y almacenar con
cualquier proveedor de análisis en tiempo real o adaptadores de procesamiento por lotes/almacenamiento. Event
Hubs desacopla la producción de un flujo de eventos desde el consumo de los eventos, para que los
consumidores de eventos pueden tener acceso a los eventos según su propia programación.
Este artículo es un complemento del vídeo Integración de Azure API Management con Event Hubs y describe
cómo registrar eventos de API Management mediante Azure Event Hubs.
Crear un centro de eventos de Azure

Para información detallada sobre cómo crear un centro de eventos y obtener las cadenas de conexión que
necesita para enviar y recibir eventos desde y hacia el centro de eventos, consulte Creación de un espacio de
nombres de Event Hubs y un centro de eventos con Azure Portal.
Creación de un registrador de administración de API

Ahora que tiene un centro de eventos, el siguiente paso es configurar un registrador en el servicio Administración
de API para que se puedan registrar eventos en el centro de eventos.
Los registradores de API Management se configuran mediante la API de REST de API Management. Antes de
usar la API de REST por primera vez, revise los requisitos previos y asegúrese de tener habilitado el acceso a la
API de REST.
Para crear un registrador, efectúe una solicitud HTTP PUT con la siguiente plantilla de dirección URL:
https://{your service}.management.azure-api.net/loggers/{new logger name}?api-version=2017-03-01
Sustituya {your service} por el nombre de la instancia de servicio de administración de API.

Sustituya {new logger name} por el nombre deseado del nuevo registrador. A este nombre se hace referencia
al configurar la directiva log-to-eventhub.
Agregue los siguientes encabezados a la solicitud:
Content-Type : application/json
Autorización: SharedAccessSignature 58...
Para instrucciones sobre cómo generar SharedAccessSignature , vea Autenticación de la API de REST
de administración de API de Azure.
Especifique el cuerpo de la solicitud usando la siguiente plantilla:
{
"loggerType" : "AzureEventHub",
"description" : "Sample logger description",
"credentials" : {
"name" : "Name of the Event Hub from the portal",
"connectionString" : "Endpoint=Event Hub Sender connection string"
}
}
loggerType se debe establecer en AzureEventHub .

description ofrece una descripción opcional del registrador y puede ser una cadena de longitud cero si lo
desea.
credentials contiene el name y connectionString del centro de eventos de Azure.
Al realizar la solicitud, si se crea el registrador, se devuelve un código de estado 201 Created . A continuación se
muestra una respuesta de ejemplo basada en la solicitud de ejemplo anterior.
{
"id": "/loggers/{new logger name}",
"loggerType": "azureEventHub",
"description": "Sample logger description",
"credentials": {
"name": "Name of the Event Hub from the Portal",
"connectionString": "{{Logger-Credentials-xxxxxxxxxxxxxxx}}"
},
"isBuffered": true,
"resourceId": null
}
NOTE
Para conocer otros posibles códigos de retorno y sus razones, vea Creación de un registrador. Para conocer la forma de
realizar otras operaciones como crear listas, actualizar y eliminar, consulte la documentación de la entidad del registrador.
Configuración de directivas log-to-eventhubs

Una vez que el registrador está configurado en la administración de API, puede configurar las directivas de log-
to-eventhubs para registrar los eventos oportunos. La directiva log-to-eventhubs puede utilizarse en la sección de
las directivas de entrada o de salida.
3. Seleccione la API a la que quiere agregar la directiva. En este ejemplo, vamos a agregar una directiva a la API
eco en el producto Unlimited (Sin límites).
5. En la parte superior de la pantalla, seleccione la pestaña Design (Diseño).
6. En la ventana de procesamiento de entrada o salida, haga clic en el triángulo (al lado del lápiz).
7. Seleccione el Editor de código. Para más información, consulte Establecimiento o modificación de directivas.
8. Coloque el cursor en la sección de directiva inbound o outbound .
9. En la ventana de la derecha, seleccione Advanced policies > (Directivas avanzadas) Log to EventHub
(Registro en EventHub). Esta acción inserta la plantilla de declaración de directiva log-to-eventhub .
<log-to-eventhub logger-id ='logger-id'>
@( string.Join(",", DateTime.UtcNow, context.Deployment.ServiceName, context.RequestId,
context.Request.IpAddress, context.Operation.Name))
</log-to-eventhub>
Reemplace logger-id con el valor que utilizó para {new logger name} en la dirección URL para crear el
registrador en el paso anterior.
Puede usar cualquier expresión que devuelva una cadena como valor para el elemento log-to-eventhub . En este
ejemplo, se registra una cadena que contiene la fecha y la hora, el nombre del servicio, el identificador de la
solicitud, la dirección IP de la solicitud y el nombre de la operación.
Haga clic en Guardar para guardar la configuración de la directiva actualizada. En el momento de guardarla, la
directiva se activa y los eventos se registran en el centro de eventos designado.
Pasos siguientes
Obtenga más información acerca de Azure Event Hubs
Introducción a Azure Event Hubs
Recepción de mensajes con EventProcessorHost
Guía de programación de Event Hubs
Obtener más información acerca de la integración de API Management y Event Hubs
Referencia de entidad del registrador
referencia de la directiva log-to-eventhub
Supervisión de las API con Azure API Management, Event Hubs y Moesif
Obtenga más información acerca de la integración con Azure Application Insights
Cómo integrar Azure API Management con Azure
Application Insights
Azure API Management le permite una integración sencilla con Azure Application Insights, un servicio extensible
para desarrolladores web que compilan y administran aplicaciones en varias plataformas. En esta guía, verá todos
los pasos para dicha integración; además, se describen las estrategias para reducir el impacto en el rendimiento en
la instancia de servicio de API Management.
Requisitos previos
Para seguir esta guía, debe tener una instancia de Azure API Management. Si no tiene una, complete antes el
tutorial.
Creación de una instancia de Azure Application Insights

Antes de poder usar Azure Application Insights, debe crear una instancia del servicio.
1. Abra Azure Portal y vaya a Application Insights.
3. Rellene el formulario. Seleccione General como Tipo de aplicación.

Creación de una conexión entreAzure Application Insights y la
instancia de servicio de Azure API Management
2. Seleccione Application Insights en el menú de la izquierda.
4. Seleccione la instancia de Application Insights creada anteriormente y escriba una descripción breve.
6. Acaba de crear un registrador de Azure Application Insights con una clave de instrumentación. Ahora debería
aparecer en la lista.
NOTE
En segundo plano, se crea una entidad Logger en la instancia de API Management, que contiene la clave de instrumentación
de la instancia de Application Insights.
Habilitación del registro Application Insights para la API

3. Haga clic en la API, en este caso, Demo Conference API.
4. Vaya a la pestaña Configuración de la barra superior.
5. Desplácese hacia abajo hasta la sección Diagnostics Logs (Registros de diagnóstico).
6. Marque la casilla Habilitar.
7. Seleccione el registrador adjunto en el menú desplegable Destino.
8. Escriba 100 como Sampling (%) [Muestreo (%)] y marque la casilla Always log errors (Registrar errores
siempre).
WARNING
Reemplazar el valor predeterminado 0 en el campo First bytes of body (Primeros bytes del cuerpo) puede disminuir
considerablemente el rendimiento de las API.
NOTE
En segundo plano, se crea una entidad de diagnóstico denominada "applicationinsights" en el nivel de API.
NOMBRE DEL VALOR TIPO DE VALOR DESCRIPCIÓN
Habilitar boolean Especifica si el registro de esta API está

habilitado.
Destino Registrador de Azure Application Especifica el registrador de Azure

Insights Application Insights que se usará
NOMBRE DEL VALOR TIPO DE VALOR DESCRIPCIÓN
Sampling (%) [Muestreo (%)] decimal Valores de 0 a 100 (porcentaje).

Especifica el porcentaje de solicitudes
que se registrarán en Azure Application
Insights. Un muestreo del 0 % significa
que no se registrará ninguna solicitud,
mientras que un muestreo del 100 % se
traduce en que se registrarán todas las
solicitudes.
Este valor se usa para reducir las
consecuencias que tiene en el
rendimiento registrar solicitudes en
Azure Application Insights (consulte la
sección siguiente).
Always log errors (Registrar errores boolean Si se selecciona esta opción, se

siempre) registrarán todos los errores en Azure
Application Insights,
independientemente del valor de
Sampling.
Opciones básicas: encabezados list Especifica los encabezados que se

registrarán en Azure Application
Insights para las solicitudes y las
respuestas. Predeterminado: no se
registra ningún encabezado.
Opciones básicas: Primeros bytes del integer Especifica cuántos primeros bytes del
cuerpo cuerpo se registrarán en Azure
Application Insights para las solicitudes
y las respuestas. Predeterminado: el
cuerpo no se registra.
Opciones avanzadas: Solicitud de front- Especifica si las solicitudes de front-end

end se registran en Azure Application
Insights y cuántas se registran.
Frontend request es una solicitud que
entra al servicio de Azure API
Management.
Opciones avanzadas: Respuesta de Especifica si las respuestas de front-end

front-end se registran en Azure Application
Insights y cuántas se registran.
Frontend response es una respuesta
que sale del servicio de Azure API
Management.
Opciones avanzadas: Solicitud de back- Especifica si las solicitudes de back-end

end se registran en Azure Application
Insights y cuántas se registran. Backend
request es una solicitud que sale del
servicio de Azure API Management.
Opciones avanzadas: Respuesta de Especifica si las respuestas de back-end

back-end se registran en Azure Application
Insights y cuántas se registran. Backend
response es una respuesta que entra al
servicio de Azure API Management.
NOTE
Puede especificar registradores en distintos niveles: registrador para una API o registrador para todas las API.
Si especifica ambos:
si son registradores distintos, se usarán ambos (registros de multiplexación);
si son el mismo registrador, pero tienen configuraciones diferentes, el correspondiente a una sola API (nivel más granular)
invalidará al que corresponde a todas las API.
Qué datos se agregan a Azure Application Insights

Azure Application Insights recibe:
elemento de telemetría Solicitud, para cada solicitud de entrada (solicitud de front-end, respuesta de front-end);
elemento de telemetría Dependencia, para cada solicitud reenviada a un servicio de back-end ( solicitud de
back-end, respuesta de back-end);
elemento de telemetría Excepción, para cada solicitud con error.
Una solicitud con error es una solicitud que:
no se pudo procesar debido a una conexión cerrada con el cliente; o
desencadenó una sección on-error (al producirse un error) de las directivas de la API; o
tiene un código de estado HTTP de respuesta que coincide con 4xx o 5xx.
Consecuencias en el rendimiento y muestreo de registros

WARNING
Registrar todos los eventos puede tener graves consecuencias en el rendimiento, según la tasa de solicitudes de entrada.
En función de las pruebas de carga internas, habilitar esta característica provocó una reducción del 40 % al 50 %
en el rendimiento cuando la tasa de solicitudes superaba las 1000 solicitudes por segundo. Azure Application
Insights está diseñada para usar análisis estadísticos para evaluar el rendimiento de las aplicaciones. No está
destinado a ser un sistema de auditoría y no es apta para registrar cada solicitud individual para API de gran
volumen.
Para manipular el número de solicitudes que se registran, puede ajustar la opción Sampling (Muestreo) que se
explica anteriormente. Un valor del 100 % significa que se registran todas las solicitudes, mientras que un 0 %
indica que no se registra nada en absoluto. Sampling (Muestreo) ayuda a reducir el volumen de telemetría, lo que
evita de manera eficaz una degradación significativa en el rendimiento, a la vez que brinda las ventajas del registro.
Omitir el registro de encabezados y del cuerpo de las solicitudes y respuestas también tendrá un efecto positivo
para evitar problemas de rendimiento.
Vídeo
Pasos siguientes
Más información sobre Azure Application Insights.
Tenga en cuenta el registro con Azure Event Hubs.
Procedimiento para implementar la recuperación
ante desastres mediante copias de seguridad y
restauración del servicio en Azure API Management
Si publica y administra las API a través de Azure API Management, podrá aprovechar numerosas funcionalidades
de infraestructura y tolerancia a errores que, de lo contrario, debería diseñar, implementar y administrar de manera
manual. La plataforma Azure mitiga una gran cantidad de posibles errores a un costo reducido.
Para recuperarse de problemas de disponibilidad que afectan la región que hospeda el servicio de API
Management, esté preparado para reconstituir el servicio en otra región en cualquier momento. Según el objetivo
de tiempo de recuperación, puede que quiera mantener un servicio en espera en una o varias regiones. También,
puede que quiera intentar mantener sincronizados la configuración y el contenido con el servicio activo según el
objetivo de punto de recuperación. Las características de copia de seguridad y restauración del servicio ofrecen los
bloques de creación necesarios para implementar una estrategia de recuperación ante desastres.
Las operaciones de copia de seguridad y restauración también pueden usarse para replicar la configuración del
servicio API Management entre entornos operativos, por ejemplo, desarrollo y almacenamiento provisional. Sepa
que los datos del entorno de ejecución, como los usuarios y las suscripciones, también se copiarán, lo que no
siempre podría ser deseable.
En esta guía se muestra cómo automatizar las operaciones de copia de seguridad y restauración y cómo garantizar
la correcta autenticación de las solicitudes de copia de seguridad y restauración mediante Azure Resource
Manager.
IMPORTANT
La operación de restauración no cambia la configuración del nombre de host personalizado del servicio de destino. Se
recomienda usar el mismo nombre de host personalizado y el mismo certificado TLS para los servicios activos y en espera, de
modo que, una vez finalizada la operación de restauración, el tráfico pueda redirigirse a la instancia en espera mediante un
simple cambio de DNS CNAME.
La operación de copia de seguridad no captura los datos de registro previamente agregados usados en los informes
mostrados en la hoja Analytics de Azure Portal.
WARNING
Cada copia de seguridad expira después de treinta días. Si intenta restaurar una copia de seguridad una vez transcurrido el
período de expiración de treinta días, se producirá un error en la restauración con un mensaje
Cannot restore: backup expired .
NOTE
Disponibilidad
IMPORTANT
Solicitudes de autenticación del Administrador de recursos de Azure

IMPORTANT
La API de REST para copia de seguridad y restauración utiliza el Administrador de recursos de Azure y tiene un mecanismo
de autenticación diferente que las API de REST para administrar las entidades de la administración de API. Los pasos de esta
sección describen cómo autenticar las solicitudes del Administrador de recursos de Azure. Par obtener más información,
consulte Solicitudes de autenticación del Administrador de recursos de Azure.
Todas las tareas que se realizan en los recursos mediante Azure Resource Manager deben autenticarse con Azure
Active Directory con los siguientes pasos:
Agregue una aplicación al inquilino de Azure Active Directory.
Establezca permisos para la aplicación que ha agregado.
Obtenga el token para autenticar solicitudes al Administrador de recursos de Azure.
Creación de una aplicación de Azure Active Directory
2. Mediante la suscripción que contiene la instancia del servicio API Management, vaya a la pestaña
Registros de aplicaciones de Azure Active Directory (Azure Active Directory > Administrar/Registros
de aplicaciones).
NOTE
Si el directorio predeterminado de Azure Active Directory no está visible en su cuenta, póngase en contacto con el
administrador de la suscripción de Azure para que le conceda los permisos necesarios para su cuenta.
3. Haga clic en Nuevo registro de aplicaciones.

Aparecerá la ventana Crear a la derecha. Es donde debe especificar la información pertinente de la
aplicación de AAD.
4. Escriba un nombre para la aplicación.
5. En el tipo de aplicación, seleccione Nativa.
6. Escriba una dirección URL de marcador de posición como http://resources para el URI de
redireccionamiento, ya que es un campo obligatorio, pero el valor no se utiliza más adelante. Haga clic en
la casilla para guardar la aplicación.
Adición de una aplicación
1. Una vez creada la aplicación, haga clic en Configuración.
2. Haga clic en Permisos necesarios.
3. Haga clic en +Agregar.
4. Haga clic en Seleccionar una API.
5. Elija Windows Azure Service Management API.
7. Haga clic en Permisos delegados al lado de la aplicación recién agregada, active la casilla Access Azure
Service Management (preview) [Acceso a Azure Service Management (versión preliminar)].
9. Haga clic en Concesión de permisos.
Configuración de la aplicación
Antes de llamar a las API que generan la copia de seguridad y la restauran, debe obtener un token. En el ejemplo
siguiente se utiliza el paquete de NuGet Microsoft.IdentityModel.Clients.ActiveDirectory para recuperar el token.
using Microsoft.IdentityModel.Clients.ActiveDirectory;
using System;
namespace GetTokenResourceManagerRequests
{
class Program
{
static void Main(string[] args)
{
var authenticationContext = new AuthenticationContext("https://login.microsoftonline.com/{tenant
id}");
var result = authenticationContext.AcquireTokenAsync("https://management.azure.com/", "
{application id}", new Uri("{redirect uri}"), new PlatformParameters(PromptBehavior.Auto)).Result;
if (result == null) {
throw new InvalidOperationException("Failed to obtain the JWT token");
}
Console.WriteLine(result.AccessToken);
Console.ReadLine();
}
}
}
Reemplace {tenant id} , {application id} y {redirect uri} mediante las siguientes instrucciones:
1. Reemplace {tenant id} por el identificador del inquilino de la aplicación de Azure Active Directory que se
creó. Para acceder al identificador, haga clic en Registros de aplicaciones -> Puntos de conexión.
2. Reemplace {application id} con el valor obtenido en la página Configuración.

3. Reemplace el valor {redirect uri} por el valor de la pestaña Redirect URIs (URI de redireccionamiento)
de la aplicación de Azure Active Directory.
Una vez especificados los valores, el ejemplo de código debe devolver un token similar al ejemplo siguiente:
NOTE
El token puede expirar tras un período determinado. Vuelva a ejecutar el ejemplo de código para generar un token
nuevo.
Llamada a operaciones de copia de seguridad y restauración

Las API REST son servicio API Management: Copia de seguridad y servicio API Management: Restauración.
Antes de llamar a las operaciones de "copia de seguridad y restauración" descritas en las secciones siguientes,
establezca el encabezado de solicitud de autorización para la llamada REST.
request.Headers.Add(HttpRequestHeader.Authorization, "Bearer " + token);
Crear una copia de seguridad del servicio API Management

Para crear una copia de seguridad del servicio API Management, emita esta solicitud HTTP:
POST
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micro
soft.ApiManagement/service/{serviceName}/backup?api-version={api-version}
donde:
subscriptionId : identificador de la suscripción que contiene el servicio API Management del que intenta crear
una copia de seguridad
resourceGroupName : nombre del grupo de recursos del servicio Azure API Management
serviceName : el nombre del servicio API Management del que desea crear una copia de seguridad que se
especificó durante su creación
api-version : reemplazar por 2018-06-01-preview
En el cuerpo de la solicitud, especifique el nombre de la copia de seguridad, el nombre del contenedor de blobs, la
clave de acceso y el nombre de la cuenta de almacenamiento de Azure de destino:
{
"storageAccount": "{storage account name for the backup}",
"accessKey": "{access key for the account}",
"containerName": "{backup container name}",
"backupName": "{backup blob name}"
}
Establezca el valor del encabezado de solicitud Content-Type en application/json .

La creación de una copia de seguridad es una operación de larga ejecución que puede tardar más de un minuto en
completarse. Si la solicitud se realizó correctamente y empezó el proceso de copia de seguridad, recibirá un código
de estado de respuesta 202 Accepted con un encabezado Location . Realice solicitudes "GET" en la URL del
encabezado Location para averiguar el estado de la operación. Mientras se crea la copia de seguridad, recibirá el
código de estado "202 Aceptado". El código de respuesta 200 OK indica que la operación de copia de seguridad se
ha completado correctamente.
Tenga en cuenta las siguientes restricciones al realizar una solicitud de copia de seguridad:
El contenedor que se especifique en el cuerpo de la solicitud debe ser real.
Mientras la copia de seguridad esté en curso, evite hacer cambios en la administración del servicio, como
una actualización o un cambio a una versión anterior de una SKU, el cambio en un nombre de dominio, etc.
La restauración de una copia de seguridad se garantiza solo durante 30 días a partir del momento en que
esta se crea.
Los datos de uso con los que se crean informes de análisis no se incluyen en la copia de seguridad. La API
de REST de Azure API Management permite recibir de forma periódica informes de análisis para guardarlos en
un lugar seguro.
La frecuencia con la que se crean las copias de seguridad afecta al objetivo de punto de recuperación. Para
minimizarlo, se recomienda implementar copias de seguridad habituales y realizar copias de seguridad a
petición después de hacer cambios en el servicio API Management.
Es posible que los cambios que se realicen en la configuración del servicio (por ejemplo, las API, las directivas
y la apariencia del portal para desarrolladores) mientras se está realizando la operación de copia de seguridad
no se incluyan en la copia de seguridad y se pierdan.
Restaurar el servicio Administración de API
Para restaurar el servicio API Management de una copia de seguridad anterior, realice esta solicitud HTTP:
POST
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micro
soft.ApiManagement/service/{serviceName}/restore?api-version={api-version}
donde:
subscriptionId : identificador de la suscripción que contiene el servicio API Management en el que se restaura
una copia de seguridad.
resourceGroupName : nombre del grupo de recursos que contiene el servicio Azure API Management en el que
se restaura una copia de seguridad.
serviceName : el nombre del servicio API Management que desea restaurar que se especificó durante su
creación.
api-version : reemplazar por 2018-06-01-preview
En el cuerpo de la solicitud, especifique la ubicación del archivo de copia de seguridad. Es decir, agregue el nombre
de la cuenta de almacenamiento de Azure, la clave de acceso, el nombre del contenedor de blob y el nombre de la
copia de seguridad:
{
"storageAccount": "{storage account name for the backup}",
"accessKey": "{access key for the account}",
"containerName": "{backup container name}",
"backupName": "{backup blob name}"
}
Establezca el valor del encabezado de solicitud Content-Type en application/json .

La restauración es una operación de larga duración que puede tardar 30 minutos o más en completarse. Si la
solicitud se realizó correctamente y empezó el proceso de restauración, recibirá un código de estado de respuesta
202 Accepted con un encabezado Location . Realice solicitudes "GET" en la URL del encabezado Location para
averiguar el estado de la operación. Mientras se realiza la restauración, recibirá el código de estado "202
Aceptado". El código de respuesta 200 OK indica que la operación de restauración se ha completado
correctamente.
IMPORTANT
La SKU en la que desea restaurar el servicio debe coincidir con la SKU del servicio del que ha creado una copia de
seguridad que desea restaurar.
Los cambios que se realicen en la configuración del servicio (por ejemplo, en la API, las directivas o la apariencia del portal
para desarrolladores) con la operación de restauración en curso pueden sobrescribirse.
NOTE
También se pueden realizar operaciones de copia de seguridad y restauración con los comandos Backup-AzApiManagement
y Restore-AzApiManagement de PowerShell, respectivamente.
Pasos siguientes
Consulte los recursos siguientes para ver distintos tutoriales del proceso de copia de seguridad y restauración.
Replicate Azure API Management Accounts (Réplica de cuentas de Administración de API de Azure)
Automating API Management Backup and Restore with Logic Apps (Automatización de la copia de seguridad y
restauración de API Management con Logic Apps)
Azure API Management: Backing Up and Restoring Configuration (Azure API Management: copia de
seguridad y restauración de la configuración) El enfoque detallado por Stuart no coincide con la orientación
oficial, pero es interesante.
Administración de cuentas de usuario en Azure API
Management
En Administración de API, los desarrolladores son los usuarios de las API que se exponen mediante
Administración de API. En esta guía se muestra cómo crear desarrolladores e invitarlos a usar las API y los
productos que usted pone a su disposición con la instancia de API Management. Para obtener información acerca
de cómo administrar cuentas de usuario mediante programación, consulte la documentación de Entidad de
usuario en la referencia sobre REST de API Management.
Disponibilidad
IMPORTANT
Requisitos previos
Complete las tareas de este artículo: Creación de una instancia de Azure API Management.

TIP
Creación de un desarrollador
Para agregar un nuevo usuario, siga los pasos descritos en esta sección:
1. Seleccione la pestaña Usuarios a la izquierda de la pantalla.
2. Presione +Agregar.
3. Especifique la información correspondiente al usuario.
4. Presione Agregar.
De forma predeterminada, las cuentas de desarrollador recién creadas se encuentran en estado Activo y se
asocian al grupo Desarrolladores. Las cuentas de desarrollador que se encuentran en estado activo se pueden
usar para obtener acceso a todas las API para las que tienen suscripciones. Para asociar el desarrollador recién
creado a otros grupos, consulte Asociación de grupos a desarrolladores.
Invitación a un desarrollador
Para invitar a un desarrollador, siga los pasos descritos en esta sección:
2. Presione +Invitar.
Se mostrará un mensaje de confirmación, pero el desarrollador recién invitado no aparecerá en la lista hasta que
acepte la invitación.
Cuando se invita a un desarrollador, se le envía un correo electrónico. Este correo electrónico se genera con una
plantilla y se puede personalizar. Para obtener más información, consulte Configuración de plantillas de correo
electrónico.
Una vez aceptada la invitación, la cuenta se activa.
Desactivación o reactivación de una cuenta de desarrollador
De forma predeterminada, las cuentas de desarrollador recién creadas o a las que se ha invitado se encuentran en
estado Activo. Para desactivar una cuenta de desarrollador, haga clic en Bloquear. Para reactivar una cuenta de
desarrollador bloqueada, haga clic en Activar. Una cuenta de desarrollador bloqueada no puede obtener acceso al
portal para desarrolladores ni llamar a ninguna API. Para eliminar una cuenta de usuario, haga clic en Eliminar.
Para bloquear a un usuario, siga los siguientes pasos.
2. Haga clic en el usuario que quiera bloquear.
3. Presione Bloquear.
Restablecimiento de la contraseña del usuario

Para trabajar con cuentas de usuario mediante programación, consulte la documentación de Entidad de usuario en
la referencia sobre API de REST de API Management. Para restablecer la contraseña de una cuenta de usuario a
un valor específico, puede utilizar la operación Actualizar un usuario y especificar la contraseña que desea utilizar.
Pasos siguientes
Una vez creada una cuenta de desarrollador, se puede asociar a roles y suscribirse a productos y API. Para obtener
más información, consulte Creación y uso de grupos.
Guardado y configuración del servicio Administración
de API mediante Git
Cada instancia del servicio Administración de API mantiene una base de datos de configuración que contiene
información sobre la configuración y los metadatos de la instancia del servicio. Es posible hacer cambios en la
instancia del servicio; para ello, modifique un valor en Azure Portal con un cmdlet de PowerShell o realice una
llamada de API REST. Pero esto no es todo, también puede administrar la configuración de la instancia del servicio
con Git, con lo que se posibilitan escenarios de administración de servicio como los siguientes:
Control de versiones de configuración: descargue y almacene versiones diferentes de la configuración del
servicio
Cambios masivos en la configuración: realice cambios en varios ajustes de la configuración del servicio en el
repositorio local e integre los cambios de nuevo en el servidor con una sola operación
Cadena de herramientas y flujo de trabajo familiares de Git: use las herramientas y los flujos de trabajo de Git
con los que ya está familiarizado
El diagrama siguiente muestra de forma global los distintos modos de configurar la instancia del servicio de API
Management.
Cuando hace cambios en el servicio mediante Azure Portal, los cmdlets de PowerShell o la API REST, está
administrando la base de datos de configuración del servicio mediante el punto de conexión
https://{name}.management.azure-api.net , tal como se muestra en el lado derecho del diagrama. En el lado
izquierdo del diagrama se muestra cómo administrar la configuración del servicio mediante Git y el repositorio de
Git para el servicio ubicado en https://{name}.scm.azure-api.net .
Los pasos siguientes proporcionan una visión general sobre el proceso de administración de la instancia del
servicio de API Management mediante Git.
1. Acceso a la configuración de Git en el servicio
2. Guardar la base de datos de configuración del servicio en el repositorio de Git
3. Clonar el repositorio de Git en el equipo local
4. Desplegar el repositorio más reciente en el equipo local, y confirmar e insertar los cambios de nuevo en el
repositorio
5. Implementar los cambios desde el repositorio en la base de datos de configuración del servicio
Este artículo describe cómo habilitar y usar Git para administrar la configuración del servicio y sirve como
referencia para los archivos y las carpetas del repositorio Git.
Disponibilidad
IMPORTANT
Acceso a la configuración de Git en el servicio

Para ver y configurar las opciones de configuración Git, puede hacer clic en el menú Seguridad e ir a la pestaña
Repositorio de configuraciones.
IMPORTANT
Los secretos que no estén definidos como valores con nombre se almacenará en el repositorio y permanecerán en su
historial hasta que deshabilitar y volver a habilitar el acceso de Git. Valores con nombre proporcionan un lugar seguro para
administrar los valores de cadena constante, como los secretos, a través de toda la configuración de la API y las directivas,
por lo que no tiene que almacenarlos directamente en las instrucciones de directiva. Para obtener más información, consulte
cómo usar los valores con nombre en las directivas de Azure API Management.
Para obtener información sobre la habilitación o la deshabilitación del acceso de Git mediante la API de REST,
consulte Enable or disable Git access using the REST API(Habilitación o deshabilitación del acceso de Git
mediante la API de REST).
Guardado de la configuración del servicio en el repositorio de Git

El primer paso antes de la clonación del repositorio es guardar el estado actual de la configuración del servicio en
el repositorio. Haga clic en Guardar en repositorio.
Realice los cambios necesarios en la pantalla de confirmación y haga clic en Aceptar para guardar.
Transcurridos unos segundos, la configuración se guarda y se muestra el estado de configuración del repositorio,
incluidas la fecha y la hora del último cambio de configuración y la última sincronización entre la configuración del
servicio y el repositorio.
Una vez que la configuración se guarda en el repositorio, se puede clonar.
Para obtener información acerca de cómo realizar esta operación mediante la API de REST, consulte Commit
configuration snapshot using the REST API(Confirmación de la instantánea de configuración mediante la API de
REST).
Para clonar el repositorio en el equipo local

Para clonar un repositorio, necesitará la dirección URL del repositorio, un nombre de usuario y una contraseña.
Para obtener el nombre de usuario y otras credenciales, haga clic en Credenciales de acceso cerca de la parte
superior de la página.
Para generar una contraseña, primero asegúrese de que el campo Expiración refleja la fecha y la hora de
caducidad deseada y luego haga clic en Generar.
IMPORTANT
Anote esta contraseña. Una vez que salga de esta página, la contraseña no se volverá a mostrar.
En los ejemplos siguientes se usa la herramienta Git Bash desde Git para Windows , pero puede usar cualquier
herramienta de Git con la que esté familiarizado.
Abra su herramienta Git en la carpeta deseada y ejecute el siguiente comando para clonar el repositorio de git en
el equipo local, usando para ello el comando incluido en Azure Portal.
git clone https://{name}.scm.azure-api.net/
Proporcione el nombre de usuario y la contraseña cuando se le solicite.

Si recibe algún error, pruebe a modificar su comando git clone para incluir el nombre de usuario y la contraseña,
como se muestra en el ejemplo siguiente.
git clone https://username:password@{name}.scm.azure-api.net/
Si de este modo aparece un error, pruebe a codificar como dirección URL la parte de la contraseña del comando.
Una manera rápida de hacer esto es abrir Visual Studio y emitir el siguiente comando en la Ventana Inmediato.
Para abrir la Ventana Inmediato, abra cualquier solución o proyecto en Visual Studio (o cree una aplicación de
consola vacía) y elija Ventanas, Inmediato en el menú Depurar.
?System.NetWebUtility.UrlEncode("password from the Azure portal")
Utilice la contraseña codificada junto con su nombre de usuario y ubicación de repositorio para construir el
comando git.
git clone https://username:url encoded password@{name}.scm.azure-api.net/
Una vez que se clone el repositorio, podrá ver y trabajar con él en el sistema de archivos local. Para más
información, consulte Referencia de estructura de archivo y carpeta del repositorio local de Git.
Para actualizar su repositorio local con la configuración de instancia de

servicio más reciente
Si realiza cambios en la instancia del servicio de API Management en Azure Portal o mediante la API REST, debe
guardar estos cambios en el repositorio para poder actualizar el repositorio local con los cambios más recientes.
Para ello, haga clic en Guardar configuración en repositorio en la pestaña Repositorio de configuración de
Azure Portal y emita el siguiente comando en el repositorio local.
git pull
Antes de ejecutar git pull , asegúrese de que se encuentra en la carpeta del repositorio local. Si acaba de
completar el comando git clone , debe cambiar el directorio a su repositorio ejecutando un comando similar al
siguiente.
cd {name}.scm.azure-api.net/
Para insertar los cambios desde su repositorio local al repositorio del

servidor
Para insertar los cambios desde el repositorio local al repositorio del servidor, debe confirmar los cambios y, a
continuación, insertarlos en el repositorio del servidor. Para confirmar los cambios, abra la herramienta de
comandos de Git, cambie al directorio del repositorio local y emita los siguientes comandos.
git add --all

git commit -m "Description of your changes"
Para insertar todas las confirmaciones en el servidor, ejecute el siguiente comando.
git push
Para implementar los cambios de la configuración del servicio en la

instancia del servicio de API Management
Una vez confirmados los cambios locales e insertados en el repositorio del servidor, puede implementarlos en la
instancia del servicio Administración de API.
Para obtener información acerca de cómo realizar esta operación mediante la API de REST, consulte Deploy Git
changes to configuration database using the REST API(Implementación de cambios de Git en la base de datos de
configuración mediante la API de REST).
Referencia de estructura de archivo y carpeta del repositorio local de

Git
Los archivos y carpetas del repositorio local de Git contienen la información de configuración acerca de la
instancia de servicio.
ITEM DESCRIPCIÓN
carpeta raíz de la administración de API Contiene la configuración de nivel superior para la instancia de
servicio
carpeta de API Contiene la configuración para las API de la instancia de

servicio
carpeta de grupos Contiene la configuración para los grupos de la instancia de

servicio
carpeta de directivas Contiene las directivas de la instancia de servicio
carpeta portalStyles Contiene la configuración para las personalizaciones del portal

para desarrolladores de la instancia de servicio
carpeta de productos Contiene la configuración para los productos de la instancia

de servicio
carpeta de plantillas Contiene la configuración para las plantillas de correo

electrónico de la instancia de servicio
Cada carpeta puede contener uno o varios archivos y, en algunos casos, una o varias carpetas; por ejemplo, una
carpeta para cada API, producto o grupo. Los archivos dentro de cada carpeta son específicos del tipo de entidad
descrito por el nombre de la carpeta.
TIPO DE ARCHIVO PROPÓSITO
json Información de configuración acerca de la entidad

correspondiente
html Descripción de la entidad, a menudo mostrada en el portal

para desarrolladores
xml Policy statements
css Hojas de estilo para la personalización del portal para

desarrolladores
Estos archivos se pueden crear, eliminar, editar y administrar en el sistema de archivos local, y los cambios se
pueden implementar de nuevo en la instancia de servicio de API Management.
NOTE
Las siguientes entidades no están en el repositorio de Git y no se pueden configurar mediante Git.
Usuarios
Suscripciones
Valores con nombre
Entidades del portal de desarrolladores distintas de los estilos
Carpeta raíz de la administración de API

La carpeta raíz api-management contiene un archivo configuration.json con información de nivel superior sobre la
instancia de servicio en el formato siguiente.
{
"settings": {
"RegistrationEnabled": "True",
"UserRegistrationTermsEnabled": "False",
"UserRegistrationTermsConsentRequired": "False",
"DelegationEnabled": "False",
"DelegationUrl": "",
"DelegatedSubscriptionEnabled": "False",
"DelegationValidationKey": "",
"RequireUserSigninEnabled": "false"
},
"$ref-policy": "api-management/policies/global.xml"
}
Los primeros cuatro valores ( RegistrationEnabled , UserRegistrationTerms , UserRegistrationTermsEnabled y

UserRegistrationTermsConsentRequired ) se asignan a la siguiente configuración en la pestaña Identidades de la
sección Seguridad.
CONFIGURACIÓN DE IDENTIDAD SE ASIGNA A
RegistrationEnabled Presencia del proveedor de identidades Nombre de usuario

y contraseña
UserRegistrationTerms Condiciones de uso del registro de usuario
UserRegistrationTermsEnabled Mostrar condiciones de uso en la página de registro
UserRegistrationTermsConsentRequired Requerir consentimiento
RequireUserSigninEnabled Redirigir a los usuarios anónimos a la página de inicio

de sesión
La cuatro valores siguientes ( DelegationEnabled , DelegationUrl , DelegatedSubscriptionEnabled y

DelegationValidationKey ) se asignan a la siguiente configuración en la pestaña Delegación de la sección
Seguridad.
CONFIGURACIÓN DE DELEGACIÓN SE ASIGNA A
DelegationEnabled Casilla Delegar inicio de sesión y registro
DelegationUrl Dirección URL del punto de conexión de delegación

CONFIGURACIÓN DE DELEGACIÓN SE ASIGNA A
DelegatedSubscriptionEnabled Delegar suscripción de producto
DelegationValidationKey Delegar clave de validación
El valor final, $ref-policy , se asigna al archivo de instrucciones de directiva global para la instancia de servicio.
carpeta de API
La carpeta apis contiene una carpeta para cada API de la instancia de servicio, que contiene los elementos
siguientes.
apis\<api name>\configuration.json : es la configuración de la API y contiene información acerca de la
dirección URL del servicio back-end y las operaciones. Se trata de la misma información que se devolvería si se
llamase a Obtener una API específica con export=true en formato application/json .
apis\<api name>\api.description.html : es la descripción de la API y corresponde a la propiedad description
de la entidad de API.
apis\<api name>\operations\ : esta carpeta contiene archivos <operation name>.description.html que se asignan
a las operaciones de la API. Cada archivo contiene la descripción de una única operación en la API, que se
asigna a la propiedad description de la entidad de operación en la API de REST.
carpeta de grupos
La carpeta groups contiene una carpeta para cada grupo definido en la instancia de servicio.
groups\<group name>\configuration.json : es la configuración para el grupo. Se trata de la misma información
que se devolvería si se llamase a la operación Obtener un grupo específico .
groups\<group name>\description.html : es la descripción del grupo y corresponde a la propiedad description
de la entidad de servicio.
carpeta de directivas
La carpeta policies contiene las instrucciones de directiva para la instancia de servicio.
policies\global.xml : contiene las directivas definidas en el ámbito global para la instancia de servicio.
policies\apis\<api name>\ : si tiene directivas definidas en el ámbito de la API, se encuentran en esta carpeta.
Carpeta policies\apis\<api name>\<operation name>\ : si tiene directivas definidas en el ámbito de la operación,
se encuentran en esta carpeta en archivos <operation name>.xml que se asignan a las instrucciones de directiva
para cada operación.
policies\products\ : si tiene directivas definidas en el ámbito del producto, se encuentran esta carpeta, que
contiene archivos <product name>.xml que se asignan a las instrucciones de directiva para cada producto.
carpeta portalStyles
La carpeta portalStyles contiene la configuración y las hojas de estilo para las personalizaciones del portal para
desarrolladores de la instancia de servicio.
portalStyles\configuration.json : contiene los nombres de las hojas de estilos usadas por el portal de
desarrolladores
portalStyles\<style name>.css : cada archivo <style name>.css contiene estilos para el portal para
desarrolladores ( Preview.css y Production.css de forma predeterminada).
carpeta de productos
La carpeta products contiene una carpeta para cada producto que se define en la instancia de servicio.
products\<product name>\configuration.json : es la configuración del producto. Se trata de la misma
información que se devolvería si se llamase a la operación Obtener un producto específico .
products\<product name>\product.description.html : es la descripción del producto y corresponde a la propiedad
description de la entidad de producto de la API de REST.
plantillas
La carpeta templates contiene la configuración para las plantillas de correo electrónico de la instancia de servicio.
<template name>\configuration.json : es la configuración de la plantilla de correo electrónico.
<template name>\body.html : es el cuerpo de la plantilla de correo electrónico.
Pasos siguientes
Para obtener información sobre otras formas de administrar la instancia de servicio, consulte:
Administrar la instancia de servicio con los siguientes cmdlets de PowerShell
Azure API Management Deployment Management Cmdlets (Cmdlets de administración de la
implementación de Administración de API de Azure)
Azure API Management Service Management Cmdlets (Cmdlets de administración del servicio
Administración de API de Azure)
Administrar la instancia de servicio mediante la API de REST
API Management REST API (API de REST de Administración de API)
Uso del control de acceso basado en rol en Azure API
Management
Azure API Management utiliza el control de acceso basado en rol (RBAC ) de Azure para permitir que pueda
hacerse una administración de acceso detallada en servicios y entidades de API Management (por ejemplo, API y
directivas). En este artículo se proporciona información general de los roles integrados y personalizados en API
Management. Para más información sobre la administración de acceso en Azure Portal, consulte la introducción
sobre la administración de acceso en Azure Portal.
NOTE
Roles integrados
Actualmente, API Management cuenta con tres roles integrados y próximamente agregará otros dos. Estos roles
pueden asignarse en distintos ámbitos, como la suscripción, el grupo de recursos y la instancia concreta de API
Management. Por ejemplo, si el rol "Azure API Management Service Reader" se asigna a un usuario en el nivel de
grupo de recursos, el usuario tendrá acceso de lectura a todas las instancias de API Management incluidas en el
grupo de recursos.
En la tabla siguiente se proporcionan breves descripciones de los roles integrados. Estos roles se pueden asignar a
través de Azure Portal u otras herramientas, como Azure PowerShell, la CLI de Azure y la API de REST. Para
obtener detalles sobre la asignación de roles integrados, consulte Uso de asignaciones de roles para administrar el
acceso a los recursos de la suscripción de Azure.
CREACIÓN,
ELIMINACIÓN Y
ESCALADO DEL
SERVICIO, VPN Y
CONFIGURACIÓN ACCESO AL PORTAL
ACCESO DE ACCESO DE PERSONALIZADA DEL EDITOR
ROL LECTURA[1] ESCRITURA[2] DE DOMINIOS HEREDADO DESCRIPCIÓN
Colaborador de ✓ ✓ ✓ ✓ Superusuario.
servicio de Azure Tiene acceso
API Management CRUD completo a
los servicios y a
las entidades de
API Management
(por ejemplo, API
y directivas).
Tiene acceso al
portal del editor
heredado.
CREACIÓN,
ELIMINACIÓN Y
ESCALADO DEL
SERVICIO, VPN Y
CONFIGURACIÓN ACCESO AL PORTAL
ACCESO DE ACCESO DE PERSONALIZADA DEL EDITOR
ROL LECTURA ESCRITURA DE DOMINIOS HEREDADO DESCRIPCIÓN
Lector de servicio ✓ Tiene acceso de

de Azure API solo lectura a los
Management servicios y a las
entidades de API
Management.
Operador de ✓ ✓ Puede
servicio de Azure administrar
API Management servicios de API
Management,
pero no
entidades.
Editor de servicio ✓ ✓ Puede

de Azure API administrar
Management* entidades de API
Management,
pero no servicios.
Administrador de ✓ ✓ Puede
contenido de administrar el
Azure API portal del
Management* desarrollador.
Acceso de solo
lectura a servicios
y entidades.
[1] Acceso de lectura a los servicios y entidades de API Management (por ejemplo, API y directivas)
[2] Acceso de escritura a los servicios y identidades de API Management, excepto las operaciones siguientes: creación, eliminación y escalado de
instancias; configuración de VPN, y configuración personalizada de dominios
* El rol Service Editor estará disponible cuando se realice la migración de toda la interfaz de usuario de administración desde el portal del editor
existente a Azure Portal. El rol Content Manager estará disponible después de que el portal del editor se refactorice, de modo que solo contenga
funcionalidades relacionadas con la administración del portal del desarrollador.
Roles personalizados
Si ninguno de los roles integrados satisface sus necesidades específicas, se pueden crear roles personalizados para
proporcionar administración de acceso más pormenorizada para entidades de API Management. Por ejemplo,
puede crear un rol personalizado que tenga acceso de solo lectura a un servicio de API Management, pero que
tenga acceso de escritura solamente a una API específica. Para más información sobre los roles personalizados,
consulte Roles personalizados para RBAC de Azure.
NOTE
Para poder ver una instancia de API Management en Azure Portal, un rol personalizado debe incluir la acción
Microsoft.ApiManagement/service/read .
A la hora de crear un rol personalizado, es más fácil comenzar con uno de los roles integrados. Edite los atributos
para agregar los elementos Actions, NotActions o AssignableScopes y guarde los cambios como un nuevo rol.
El ejemplo siguiente comienza con el rol "Azure API Management Service Reader" y crea un rol personalizado
denominado "Calculator API Editor". Puede asignar el rol personalizado a una API concreta. De ese modo, el rol
solamente tendrá acceso a esa API.
$role = Get-AzRoleDefinition "API Management Service Reader Role"

$role.Id = $null
$role.Name = 'Calculator API Contributor'
$role.Description = 'Has read access to Contoso APIM instance and write access to the Calculator API.'
$role.Actions.Add('Microsoft.ApiManagement/service/apis/write')
$role.Actions.Add('Microsoft.ApiManagement/service/apis/*/write')
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add('/subscriptions/<subscription ID>/resourceGroups/<resource group
name>/providers/Microsoft.ApiManagement/service/<service name>/apis/<api ID>')
New-AzRoleDefinition -Role $role
New-AzRoleAssignment -ObjectId <object ID of the user account> -RoleDefinitionName 'Calculator API Contributor'
-Scope '/subscriptions/<subscription ID>/resourceGroups/<resource group
name>/providers/Microsoft.ApiManagement/service/<service name>/apis/<api ID>'
El artículo Operaciones del proveedor de recursos de Azure Resource Manager contiene la lista de permisos que se
pueden conceder en el nivel de API Management.
Vídeo
Pasos siguientes
Para más información sobre el control de acceso basado en rol de Azure, consulte los siguientes artículos:
Introducción a la administración de acceso en Azure Portal
Uso de asignaciones de roles para administrar el acceso a los recursos de la suscripción de Azure
Roles personalizados para RBAC de Azure
Operaciones del proveedor de recursos de Azure Resource Manager
Uso de identidades administradas en Azure API
Management
En este artículo se muestra cómo crear una identidad administrada para una instancia de servicio de API
Management y cómo acceder a otros recursos. Una identidad administrada generada por Azure Active Directory
(Azure AD ) permite a la instancia de API Management acceder de forma fácil y segura a otros recursos protegidos
de Azure AD, como Azure Key Vault. Esta identidad está administrada por Azure y no requiere que aprovisione o
rote los secretos. Para más información sobre las identidades administradas, consulte el artículo sobre qué son las
identidades administradas para recursos de Azure.
Creación de una identidad administrada para una instancia de API

Management
Uso de Azure Portal
Para configurar una identidad administrada en el portal, primero tendrá que crear una instancia de API
Management como lo hace normalmente y, a continuación, habilitar la característica.
1. Cree una instancia de API Management en el portal como lo haría normalmente. Navegue hasta el portal.
2. Seleccione Identidades de servicio administradas.
3. Cambie Registrar en Azure Active Directory a Activado. Haga clic en Guardar.
Uso de la plantilla de Azure Resource Manager

Puede crear una instancia de API Management con una identidad mediante la inclusión de la siguiente propiedad
en la definición de recursos:
"identity" : {
"type" : "SystemAssigned"
}
Esto indica a Azure que debe crear y administrar la identidad para la instancia de API Management.
Por ejemplo, una plantilla de Azure Resource Manager completa podría tener el aspecto siguiente:
{
"$schema": "https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
"contentVersion": "0.9.0.0",
"resources": [{
"apiVersion": "2017-03-01",
"name": "contoso",
"type": "Microsoft.ApiManagement/service",
"location": "[resourceGroup().location]",
"tags": {},
"sku": {
"name": "Developer",
"capacity": "1"
},
"properties": {
"publisherEmail": "[email protected]",
"publisherName": "Contoso"
},
"identity": {
"type": "systemAssigned"
}
}]
}
Uso de la identidad de servicio administrada para acceder a otros

recursos
NOTE
Actualmente, las identidades administradas se pueden utilizar para obtener certificados de Azure Key Vault para los nombres
de dominio personalizados de API Management. Pronto se admitirán más escenarios.
Obtención de un certificado en Azure Key Vault

Requisitos previos
1. El almacén de claves que contiene los certificados pfx debe estar en la misma suscripción de Azure y el mismo
grupo de recursos que el servicio API Management. Se trata de un requisito de la plantilla de Azure Resource
Manager.
2. El tipo de contenido del secreto debe ser application/x-pkcs12. Puede usar el siguiente script para cargar el
certificado:
$pfxFilePath = "PFX_CERTIFICATE_FILE_PATH" # Change this path
$pwd = "PFX_CERTIFICATE_PASSWORD" # Change this password
$flag = [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable
$collection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$collection.Import($pfxFilePath, $pwd, $flag)
$pkcs12ContentType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12
$clearBytes = $collection.Export($pkcs12ContentType)
$fileContentEncoded = [System.Convert]::ToBase64String($clearBytes)
$secret = ConvertTo-SecureString -String $fileContentEncoded -AsPlainText –Force
$secretContentType = 'application/x-pkcs12'
Set-AzureKeyVaultSecret -VaultName KEY_VAULT_NAME -Name KEY_VAULT_SECRET_NAME -SecretValue $Secret -ContentType
$secretContentType
IMPORTANT
Si no se proporciona la versión del objeto del certificado, API Management obtiene automáticamente la versión más reciente
del certificado una vez cargado a Key Vault.
En el ejemplo siguiente se muestra una plantilla de Azure Resource Manager que contiene los siguientes pasos:
1. Creación de una instancia de API Management con una identidad administrada.
2. Actualización de las directivas de acceso de una instancia de Azure Key Vault y permiso para que la instancia de
API Management obtenga secretos de ella.
3. Actualización de la instancia de API Management estableciendo un nombre de dominio personalizado mediante
un certificado de la instancia de Key Vault.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"publisherEmail": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "The email address of the owner of the service"
}
},
"publisherName": {
"type": "string",
"defaultValue": "Contoso",
"minLength": 1,
"metadata": {
"description": "The name of the owner of the service"
}
},
"sku": {
"type": "string",
"allowedValues": ["Developer",
"Standard",
"Premium"],
"defaultValue": "Developer",
"metadata": {
"description": "The pricing tier of this API Management service"
}
},
"skuCount": {
"type": "int",
"defaultValue": 1,
"metadata": {
"description": "The instance size of this API Management service."
}
},
"keyVaultName": {
"type": "string",
"metadata": {
"description": "Name of the vault"
}
},
"proxyCustomHostname1": {
"type": "string",
"metadata": {
"description": "Proxy Custom hostname."
}
},
"keyVaultIdToCertificate": {
"type": "string",
"metadata": {
"description": "Reference to the KeyVault certificate.
https://contoso.vault.azure.net/secrets/contosogatewaycertificate."
}
}
},
"variables": {
"apiManagementServiceName": "[concat('apiservice', uniqueString(resourceGroup().id))]",
"apimServiceIdentityResourceId": "[concat(resourceId('Microsoft.ApiManagement/service',
variables('apiManagementServiceName')),'/providers/Microsoft.ManagedIdentity/Identities/default')]"
},
"resources": [{
"apiVersion": "2017-03-01",
"name": "[variables('apiManagementServiceName')]",
"type": "Microsoft.ApiManagement/service",
"location": "[resourceGroup().location]",
"tags": {
},
"sku": {
"name": "[parameters('sku')]",
"capacity": "[parameters('skuCount')]"
},
"properties": {
"publisherEmail": "[parameters('publisherEmail')]",
"publisherName": "[parameters('publisherName')]"
},
"identity": {
"type": "systemAssigned"
}
},
{
"type": "Microsoft.KeyVault/vaults/accessPolicies",
"name": "[concat(parameters('keyVaultName'), '/add')]",
"apiVersion": "2015-06-01",
"dependsOn": [
"[resourceId('Microsoft.ApiManagement/service', variables('apiManagementServiceName'))]"
],
"properties": {
"accessPolicies": [{
"tenantId": "[reference(variables('apimServiceIdentityResourceId'), '2015-08-31-
PREVIEW').tenantId]",
"objectId": "[reference(variables('apimServiceIdentityResourceId'), '2015-08-31-
PREVIEW').principalId]",
"permissions": {
"secrets": ["get"]
}
}]
}
},
{
"apiVersion": "2017-05-10",
"name": "apimWithKeyVault",
"type": "Microsoft.Resources/deployments",
"dependsOn": [
],
"properties": {
"mode": "incremental",
"templateLink": {
"uri": "https://raw.githubusercontent.com/solankisamir/arm-
templates/master/basicapim.keyvault.json",
"contentVersion": "1.0.0.0"
},
"parameters": {
"publisherEmail": { "value": "[parameters('publisherEmail')]"},
"publisherName": { "value": "[parameters('publisherName')]"},
"sku": { "value": "[parameters('sku')]"},
"skuCount": { "value": "[parameters('skuCount')]"},
"proxyCustomHostname1": {"value" : "[parameters('proxyCustomHostname1')]"},
"keyVaultIdToCertificate": {"value" : "[parameters('keyVaultIdToCertificate')]"}
}
}
}]
}
Pasos siguientes
Obtenga más información sobre las identidades administradas para recursos de Azure:
¿Qué son las identidades administradas de recursos de Azure?
Plantillas del Administrador de recursos de Azure
Autenticación con una identidad administrada en una directiva
Información general de Service Fabric con Azure API
Management
Las aplicaciones en la nube normalmente necesitan una puerta de enlace front-end para proporcionar un único
punto de entrada para usuarios, dispositivos u otras aplicaciones. En Service Fabric, una puerta de enlace puede
ser cualquier servicio sin estado como una aplicación ASP.NET Core u otro servicio designado para la entrada de
tráfico, como Event Hubs, IoT Hub o Azure API Management.
Este artículo es una introducción al uso de Azure API Management como puerta de enlace para las aplicaciones
de Service Fabric. API Management se integra directamente con Service Fabric, lo que le permite publicar API con
un amplio conjunto de reglas de enrutamiento para los servicios back-end de Service Fabric.
Disponibilidad
IMPORTANT
Esta característica ya está disponible en los niveles Premium y Developer de API Management debido a la compatibilidad
requerida con redes virtuales.
Arquitectura
Una arquitectura de Service Fabric común usa una aplicación web de una página que realiza llamadas HTTP a
servicios back-end que exponen API HTTP. La aplicación de ejemplo de inicio de Service Fabric presenta una
muestra de esta arquitectura.
En este escenario, un servicio web sin estado actúa como puerta de enlace en la aplicación de Service Fabric. Este
enfoque precisa que escriba un servicio web que admita solicitudes HTTP proxy para servicios back-end, como se
muestra en el siguiente diagrama:
A medida que aumenta la complejidad de las aplicaciones, también lo hacen las puertas de enlace que deben
presentar una API delante de innumerables servicios back-end. Azure API Management se ha diseñado para
controlar API complejas con reglas de enrutamiento, control de acceso, limitación de velocidad, supervisión,
registro de eventos y almacenamiento en caché de respuestas con el mínimo esfuerzo por su parte. Azure API
Management admite la selección de réplicas, la resolución de la partición y la detección de servicios de Service
Fabric para enrutar de forma inteligente las solicitudes directamente a los servicios back-end en Service Fabric
para que no tenga que escribir su propia puerta de enlace de API sin estado.
En este escenario, la interfaz de usuario web se sigue ofreciendo a través de un servicio web, mientras que las
llamadas a la API HTTP se administran y se enrutan a través de Azure API Management, tal como se muestra en
el siguiente diagrama:
Escenarios de aplicación
Los servicios de Service Fabric pueden ser con o sin estado, y pueden tener particiones con uno de los tres
esquemas: singleton, intervalo de Int-64 y con nombre. La resolución del punto de conexión de servicio requiere
identificar una partición específica de una instancia de servicio específica. Al resolver un punto de conexión de un
servicio, deben especificarse el nombre de instancia de servicio (por ejemplo, fabric:/myapp/myservice ) y la
partición específica del servicio, salvo en el caso de la partición singleton.
Azure API Management puede usarse con cualquier combinación de servicios con o sin estado y cualquier
esquema de partición.
Envío de tráfico a un servicio sin estado

En el caso más simple, el tráfico se reenvía a una instancia de servicio sin estado. Para lograr esto, una operación
de API Management contiene una directiva de procesamiento de entrada con un back-end de Service Fabric que
se asigna a una instancia de servicio sin estado específica en el back-end de Service Fabric. Las solicitudes
destinadas a ese servicio se envían a una réplica aleatoria de la instancia de servicio sin estado.
Ejemplo
En el siguiente escenario, una aplicación de Service Fabric contiene un servicio sin estado denominado
fabric:/app/fooservice , que expone una API HTTP interna. El nombre de instancia de servicio es conocido y
puede estar codificado de forma rígida directamente en la directiva de procesamiento de entrada de API
Management.
Envío de tráfico a un servicio con estado
De forma similar a lo que ocurría en el escenario del servicio sin estado, el tráfico se puede reenviar a una
instancia de servicio con estado. En este caso, una operación de API Management contiene una directiva de
procesamiento de entrada con un back-end de Service Fabric que asigna una solicitud a una partición específica
de una instancia de servicio con estado específica. La partición para asignar cada solicitud se calcula a través de un
método lambda con algunas entradas de la solicitud HTTP entrante, como un valor de la ruta de acceso de la
dirección URL. La directiva puede configurarse para enviar solicitudes solo a la réplica principal o a una réplica
aleatoria para operaciones de lectura.
Ejemplo
En el siguiente escenario, una aplicación de Service Fabric contiene un servicio con estado con partición
denominado fabric:/app/userservice , que expone una API HTTP interna. El nombre de instancia de servicio es
conocido y puede estar codificado de forma rígida directamente en la directiva de procesamiento de entrada de
API Management.
Se realiza la partición del servicio mediante el esquema de partición Int-64 con dos particiones y un intervalo de
claves que abarca de Int64.MinValue a Int64.MaxValue . La directiva de back-end calcula una clave de partición
dentro de ese intervalo convirtiendo el valor id proporcionado en la ruta de acceso de solicitud de la dirección
URL en un entero de 64 bits, aunque se puede utilizar aquí cualquier algoritmo para calcular la clave de partición.
Envío de tráfico a varios servicios sin estado

En escenarios más avanzados, puede definir una operación de API Management que asigne solicitudes a más de
una instancia de servicio. En este caso, cada operación contiene una directiva que asigna solicitudes a una
instancia de servicio determinada basándose en valores de la solicitud HTTP de entrada, como la cadena de
consulta o la ruta de acceso de la dirección URL y, en el caso de servicios con estado, una partición dentro de la
instancia de servicio.
Para lograr esto, una operación de API Management contiene una directiva de procesamiento de entrada con un
back-end de Service Fabric que asigna una instancia de servicio sin estado en el back-end de Service Fabric
basándose en los valores recuperados de la solicitud HTTP entrante. Las solicitudes para la instancia de servicio se
envían a una réplica aleatoria de la instancia de servicio.
Ejemplo
En este ejemplo, se crea una nueva instancia de servicio sin estado para cada usuario de una aplicación con un
nombre generado de forma dinámica con la siguiente fórmula:
fabric:/app/users/<username>
Cada servicio tiene un nombre único, pero los nombres no se conocen por adelantado porque los servicios
se crean en respuesta a la entrada del administrador o usuario y, por lo tanto, no se pueden codificar de
forma rígida en las directivas APIM o las reglas de enrutamiento. En su lugar, se genera el nombre del
servicio que se va a enviar una solicitud en la definición de la directiva de back-end del valor name
proporcionado en la ruta de acceso de solicitud de la dirección URL. Por ejemplo:
Se enruta una solicitud para /api/users/foo a la instancia de servicio fabric:/app/users/foo
Se enruta una solicitud para /api/users/bar a la instancia de servicio fabric:/app/users/bar
Envío de tráfico a varios servicios con estado

De forma similar al ejemplo de servicio sin estado, una operación de API Management puede asignar solicitudes a
más de una instancia de servicio con estado, en cuyo caso también podría tener que realizar una resolución de
partición para cada instancia de servicio con estado.
Para lograr esto, una operación de API Management contiene una directiva de procesamiento de entrada con un
back-end de Service Fabric que se asigna a una instancia de servicio con estado en el back-end de Service Fabric
basándose en los valores recuperados de la solicitud HTTP entrante. Además de asignar una solicitud a la
instancia de servicio específica, la solicitud también se puede asignar a una partición específica dentro de la
instancia de servicio y, opcionalmente, a la réplica principal o a una réplica secundaria aleatoria dentro de la
partición.
Ejemplo
En este ejemplo, se crea una nueva instancia de servicio con estado para cada usuario de la aplicación con un
nombre generado de forma dinámica con la siguiente fórmula:
fabric:/app/users/<username>
Cada servicio tiene un nombre único, pero los nombres no se conocen por adelantado porque los servicios
se crean en respuesta a la entrada del administrador o usuario y, por lo tanto, no se pueden codificar de
forma rígida en las directivas APIM o las reglas de enrutamiento. En su lugar, se genera el nombre del
servicio que se va a enviar una solicitud en la definición de la directiva de back-end del valor name
proporcionado en la ruta de acceso de solicitud de la dirección URL. Por ejemplo:
Se enruta una solicitud para /api/users/foo a la instancia de servicio fabric:/app/users/foo
Se enruta una solicitud para /api/users/bar a la instancia de servicio fabric:/app/users/bar
Se realiza también la partición de cada instancia de servicio mediante el esquema de partición Int-64 con dos
particiones y un intervalo de claves que abarca de Int64.MinValue a Int64.MaxValue . La directiva de back-end
calcula una clave de partición dentro de ese intervalo convirtiendo el valor id proporcionado en la ruta de acceso
de solicitud de la dirección URL en un entero de 64 bits, aunque se puede utilizar aquí cualquier algoritmo para
calcular la clave de partición.
Pasos siguientes
Siga el tutorial para configurar el primer clúster de Service Fabric con API Management y enviar solicitudes
mediante API Management a sus servicios.
Integrar API Management con Service Fabric en
Azure
La implementación de Azure API Management con Service Fabric es un escenario avanzado. API Management
es útil cuando es necesario publicar API con un completo conjunto de reglas de enrutamiento para los servicios
de Service Fabric de back-end. Las aplicaciones en la nube normalmente necesitan una puerta de enlace front-
end para proporcionar un único punto de entrada para usuarios, dispositivos u otras aplicaciones. En Service
Fabric, una puerta de enlace puede ser cualquier servicio sin estado diseñado para la entrada de tráfico, como
una aplicación ASP.NET Core, Event Hubs, IoT Hub o Azure API Management.
En este artículo se muestra cómo configurar Azure API Management con Service Fabric para enrutar el tráfico a
un servicio de back-end de Service Fabric. Cuando haya terminado, habrá implementado API Management en
una red virtual y configurado una operación de API para enviar tráfico a servicios sin estado de back-end. Para
más información sobre escenarios de Azure API Management con Service Fabric, consulte el artículo de
introducción.
NOTE
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca
del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
Disponibilidad
IMPORTANT
Esta característica ya está disponible en los niveles Premium y Developer de API Management debido a la
compatibilidad requerida con redes virtuales.
Requisitos previos
Antes de empezar:
Si no tiene ninguna suscripción a Azure, cree una cuenta gratuita
Instale Azure Powershell o la CLI de Azure.
Cree un clúster de Windows en un grupo de seguridad de red.
Si implementa un clúster de Windows, configure un entorno de desarrollo de Windows. Instale
Visual Studio 2019 y las cargas de trabajo de desarrollo Azure, desarrollo web y ASP.NET y desarrollo a
través de plataformas .NET Core. Después, configure un entorno de desarrollo .NET.
Topología de red
Ahora que tiene un clúster de Windows seguro en Azure, implemente API Management en la red virtual
(VNET), en la subred y en el grupo de seguridad de red diseñados para API Management. En este artículo la
plantilla de Resource Manager para API Management está preconfigurada para usar los nombres de la red
virtual, la subred y el grupo de seguridad de red que configuró en el tutorial del clúster de Windows. Asimismo,
este artículo implementa la siguiente topología en Azure, donde API Management y Service Fabric están en
subredes de la misma red virtual:
Inicio de sesión en Azure y selección de la suscripción

Inicie sesión en su cuenta de Azure y seleccione su suscripción antes de ejecutar comandos de Azure.
Connect-AzAccount
Get-AzSubscription
Set-AzContext -SubscriptionId <guid>
az login
az account set --subscription <guid>
Implementación de un servicio de back-end de Service Fabric

Antes de configurar API Management para enrutar el tráfico a un servicio back-end de Service Fabric, primero
necesita un servicio en ejecución que acepte solicitudes.
Cree un servicio básico y confiable de ASP.NET Core sin estado, con la plantilla de proyecto de Web API
predeterminada. Así se crea un punto de conexión HTTP para el servicio que se expone en Azure API
Management.
Inicie Visual Studio como administrador y cree un servicio ASP.NET Core:
1. En Visual Studio, seleccione Archivo -> Nuevo proyecto.
2. En Nube, seleccione la plantilla de aplicación de Service Fabric y asígnele el nombre "ApiApplication" .
3. Seleccione la plantilla de servicio de ASP.NET Core sin estado y denomine al proyecto
"WebApiService" .
4. Seleccione la plantilla de proyecto de ASP.NET Core 2.0 de API web.
5. Una vez creado el proyecto, abra PackageRoot\ServiceManifest.xml y quite los atributos Port de la
configuración del recurso de punto de conexión:
<Resources>
<Endpoints>
<Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" />
</Endpoints>
</Resources>
Al quitar el puerto permite que Service Fabric especificar un puerto dinámicamente desde el intervalo de
puertos de aplicación, puede abrir a través del grupo de seguridad de red en la plantilla de Cluster
Resource Manager, permitiendo el tráfico fluya a él desde API Management.
6. Presione F5 en Visual Studio para comprobar que la API web está disponible de manera local.
Abra Service Fabric Explorer y vaya a una instancia específica del servicio ASP.NET Core para ver la
dirección base donde escucha el servicio. Agregue /api/values a la dirección base y ábralo en un
explorador. Esto invoca el método Get en ValuesController en la plantilla de Web API. Devuelve la
respuesta predeterminada de la plantilla, una matriz JSON con dos cadenas:
["value1", "value2"]`
Este es el punto de conexión que debe exponer a través de API Management en Azure.
7. Por último, implemente la aplicación en el clúster en Azure. In Visual Studio, haga clic con el botón
derecho en el proyecto de la aplicación y seleccione Publicar. Proporcione el punto de conexión del
clúster (por ejemplo, mycluster.southcentralus.cloudapp.azure.com:19000 ) para implementar la aplicación
en el clúster de Service Fabric en Azure.
En el clúster de Service Fabric en Azure ahora se ejecutará un servicio sin estado ASP.NET Core denominado
fabric:/ApiApplication/WebApiService .
Descarga e información de las plantillas de Resource Manager

Descargue y guarde las plantillas de Resource Manager y el archivo de parámetros siguientes:
network-apim.json
network-apim.parameters.json
apim.json
apim.parameters.json
La plantilla network-apim.json implementa un nuevo grupo de seguridad de red y una nueva subred en la red
virtual donde se implementa el clúster de Service Fabric.
En las siguientes secciones se describen los recursos que se definen mediante la plantilla apim.json. Para más
información, siga los vínculos a la documentación de referencia de plantilla dentro de cada sección. Los
parámetros configurables que se definen en el archivo de parámetros apim.parameters.json se establecen más
adelante en este artículo.
Microsoft.ApiManagement/service
Microsoft.ApiManagement/service describe la instancia de servicio de API Management: nombre, SKU o nivel,
ubicación del grupo de recursos, información del editor y red virtual.
Microsoft.ApiManagement/service/certificates
Microsoft.ApiManagement/service/certificates configura la seguridad de API Management. API Management
debe autenticarse con el clúster de Service Fabric para la detección de servicios mediante un certificado de
cliente con acceso al clúster. En este artículo se usa el mismo certificado que se especificó anteriormente al crear
el clúster de Windows que, de forma predeterminada, se puede usar para tener acceso al clúster.
En este artículo se usa el mismo certificado para la autenticación de cliente y la seguridad de nodo a nodo del
clúster. Puede utilizar otro certificado de cliente si tiene uno configurado para acceder al clúster de Service
Fabric. Rellene los campos name, password y data (cadena codificada en base-64) del archivo de clave privada
(.pfx) del certificado del clúster que especificó al crear el clúster de Service Fabric.
Microsoft.ApiManagement/service/backends
Microsoft.ApiManagement/service/backends describe el servicio back-end al que se reenvía el tráfico.
En los servidores back-end de Service Fabric, su clúster sirve de back-end, en lugar de usar un servicio de
Service Fabric específico. Esto permite que una única directiva enrute a más de un servicio del clúster. Aquí el
campo url es el nombre completo de un servicio del clúster al que se enrutan todas las solicitudes de forma
predeterminada si no se especifica ningún nombre de servicio en una directiva de back-end. Puede usar un
nombre de servicio falso, como "fabric:/fake/service" si no desea un servicio de reserva. resourceId especifica el
punto de conexión de administración del clúster. clientCertificateThumbprint y
serverCertificateThumbprints identifican los certificados usados para autenticarse con el clúster.
Microsoft.ApiManagement/service/products
Microsoft.ApiManagement/service/products crea un producto. En Azure API Management, un producto
contiene una o varias API, así como una cuota de uso y los términos de uso. Una vez publicado un producto, los
desarrolladores pueden suscribirse al producto y comenzar a usar las API del producto.
Rellene el campo displayName con un valor descriptivo y el campo description del producto. En este artículo,
se necesita una suscripción, pero no es necesario que la apruebe un administrador. El valor de state de este
producto es "publicado" y es visible para los suscriptores.
Microsoft.ApiManagement/service/apis
Microsoft.ApiManagement/service/apis crea una API. En API Management, una API representa un conjunto de
operaciones que puede invocarse por las aplicaciones cliente. Una vez agregadas las operaciones, la API se
agrega a un producto y se puede publicar. Una vez publicada una API, pueden usarla y suscribirse a ella los
desarrolladores.
displayName puede ser cualquier nombre para la API. En este artículo usará "Service Fabric App".
name proporciona un nombre único y descriptivo para la API, como "aplicación de service fabric". Se
muestra en el portal para desarrolladores y en el portal del publicador.
serviceUrl hace referencia al servicio HTTP que implementa la API. API Management envía las solicitudes a
esta dirección. En servidores back-end de Service Fabric, este valor de dirección URL no se usa. Puede
escribir aquí cualquier valor. Este artículo, por ejemplo "http://servicefabric".
path se anexa a la dirección URL base del servicio API Management. La dirección URL base es común para
todas las API hospedadas en una instancia del servicio API Management. API Management distingue las API
por su sufijo, por lo que el sufijo debe ser único para cada API de un publicador determinado.
El campo protocols determina los protocolos que se pueden usar para acceder a la API. En este artículo, se
muestran http y https.
path es un sufijo de la API. En este artículo deberá usar "myapp".
Microsoft.ApiManagement/service/apis/operations
Microsoft.ApiManagement/service/apis/operations: antes de usar una API de API Management, se deben
agregar operaciones a la API. Los clientes externos usan una operación para comunicarse con el servicio sin
estado de ASP.NET Core que se ejecuta en el clúster de Service Fabric.
Para agregar una operación de API de front-end, rellene los valores:
displayName y description describen la operación. En este artículo deberá usar "Values".
method especifica el verbo HTTP. En este artículo deberá especificar GET.
urlTemplate se anexa a la dirección URL base de la API e identifica una única operación HTTP. En este
artículo deberá usar /api/values si agregó el servicio back-end de .NET, o getMessage si agregó el servicio
back-end de Java. De forma predeterminada, la ruta de acceso URL que se especifica aquí se envía al servicio
de back-end de Service Fabric. Si usa aquí la misma ruta de acceso URL que usa el servicio, como
"/api/values", la operación funciona sin más modificaciones. También puede especificar aquí una ruta de
acceso URL distinta de la que usa el servicio de back-end de Service Fabric, en cuyo caso también debe
especificar después una ruta de acceso de reescritura en la directiva de la operación.
Microsoft.ApiManagement/service/apis/policies
Microsoft.ApiManagement/service/apis/policies crea una directiva de back-end, que vincula todos los
elementos. Es donde se configura el servicio de back-end de Service Fabric al que se enrutan las solicitudes.
Puede aplicar esta directiva a cualquier operación de API. Para más información, consulte Introducción a las
directivas.
La configuración de back-end de Service Fabric proporciona los controles de enrutamiento de solicitudes
siguientes:
Selección de instancias de servicio mediante la especificación de un nombre de instancia de servicio de
Service Fabric, ya sea codificado de forma rígida (por ejemplo, "fabric:/myapp/myservice" ) o generado a
partir de la solicitud HTTP (por ejemplo,
"fabric:/myapp/users/" + context.Request.MatchedParameters["name"] ).
Resolución de la partición mediante la generación de una clave de partición a partir de cualquier esquema de
partición de Service Fabric.
Selección de réplicas para los servicios con estado.
Condiciones de reintento de resolución que permiten especificar las condiciones para volver a resolver una
ubicación de servicio y volver a enviar una solicitud.
policyContent es el contenido XML con escape JSON de la directiva. En este artículo deberá crear una directiva
de back-end que enrute las solicitudes directamente al servicio sin estado .NET o Java implementado
anteriormente. Agregue una directiva set-backend-service bajo las directivas de entrada. Reemplace el valor de
sf-service-instance-name por fabric:/ApiApplication/WebApiService , si anteriormente implementó el servicio
back-end de .NET, o por fabric:/EchoServerApplication/EchoServerService , si implementó el servicio Java.
backend -id hace referencia a un recurso de back-end, en este caso el recurso
<policies>
<inbound>
<base/>
</inbound>
<backend>
<base/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Para obtener un conjunto completo de los atributos de directiva de back-end de Service Fabric, consulte la
documentación de back-end de API Management
Definición de los parámetros e implementación de API Management

Rellene los siguientes parámetros vacíos en apim.parameters.json para la implementación.
. VALOR
apimInstanceName sf-apim
apimPublisherEmail [email protected]
apimSku Developer
serviceFabricCertificateName sfclustertutorialgroup320171031144217
certificatePassword q6D7nN%6ck@6
serviceFabricCertificateThumbprint C4C1E541AD512B8065280292A8BA6079C3F26F10
serviceFabricCertificate <cadena codificada en base 64>
url_path /api/values
clusterHttpManagementEndpoint https://mysfcluster.southcentralus.cloudapp.azure.com:19080
inbound_policy <Cadena XML>
certificatePassword y serviceFabricCertificateThumbprint deben coincidir con el certificado usado para

configurar el clúster.
serviceFabricCertificate es el certificado como una cadena codificada en base 64, que se puede generar
mediante el siguiente script:
$bytes = [System.IO.File]::ReadAllBytes("C:\mycertificates\sfclustertutorialgroup220171109113527.pfx");
$b64 = [System.Convert]::ToBase64String($bytes);
[System.Io.File]::WriteAllText("C:\mycertificates\sfclustertutorialgroup220171109113527.txt", $b64);
En inbound_policy, reemplace el valor de sf-service-instance-name por fabric:/ApiApplication/WebApiService si

implementó antes el servicio de back-end de .NET, o por fabric:/EchoServerApplication/EchoServerService si
implementó el servicio Java. backend -id hace referencia a un recurso de back-end, en este caso el recurso
<policies>
<inbound>
<base/>
</inbound>
<backend>
<base/>
</backend>
<outbound>
<base/>
</outbound>
</policies>
Use el siguiente script para implementar la plantilla de Resource Manager y los archivos de parámetros para
API Management:
$groupname = "sfclustertutorialgroup"
$clusterloc="southcentralus"
$templatepath="C:\clustertemplates"
New-AzResourceGroupDeployment -ResourceGroupName $groupname -TemplateFile "$templatepath\network-apim.json"

-TemplateParameterFile "$templatepath\network-apim.parameters.json" -Verbose
New-AzResourceGroupDeployment -ResourceGroupName $groupname -TemplateFile "$templatepath\apim.json" -

TemplateParameterFile "$templatepath\apim.parameters.json" -Verbose
az group deployment create --name ApiMgmtNetworkDeployment --resource-group $ResourceGroupName --template-
file network-apim.json --parameters @network-apim.parameters.json
az group deployment create --name ApiMgmtDeployment --resource-group $ResourceGroupName --template-file

apim.json --parameters @apim.parameters.json
Pruébelo
Ahora puede intentar enviar una solicitud al servicio back-end de Service Fabric a través de API Management
directamente desde Azure Portal.
1. En el servicio API Management, seleccione API.
2. En la API de Service Fabric App que creó en los pasos anteriores, seleccione la pestaña Prueba y, a
continuación, la operación Values.
3. Haga clic en el botón Enviar para enviar una solicitud de prueba al servicio de back-end. La respuesta
HTTP debe ser similar a la siguiente:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Vary: Origin
Ocp-Apim-Trace-Location:
https://apimgmtstodhwklpry2xgkdj.blob.core.windows.net/apiinspectorcontainer/PWSQOq_FCDjGcaI1rdMn8w2-
2?sv=2015-07-08&sr=b&sig=MhQhzk%2FEKzE5odlLXRjyVsgzltWGF8OkNzAKaf0B1P0%3D&se=2018-01-
28T01%3A04%3A44Z&sp=r&traceId=9f8f1892121e445ea1ae4d2bc8449ce4
Date: Sat, 27 Jan 2018 01:04:44 GMT
["value1", "value2"]
Un clúster está formado por muchos otros recursos de Azure, además del propio recurso del clúster. La manera
más sencilla de eliminar el clúster y todos los recursos que consume es eliminar el grupo de recursos.
Inicie sesión en Azure y seleccione el identificador de suscripción con el que quiere quitar el clúster. Para
encontrar el identificador de suscripción, inicie sesión en Azure Portal. Eliminar el grupo de recursos y todos los
recursos de clúster mediante el cmdlet Remove-AzResourceGroup.
$ResourceGroupName = "sfclustertutorialgroup"
Remove-AzResourceGroup -Name $ResourceGroupName -Force
az group delete --name $ResourceGroupName
Pasos siguientes
Obtenga más información acerca de cómo usar API Management.
vice-fabric-scripts-and-templates/blob/master/templates/service-integration/network-apim.parameters.jsonn
P+F de Azure API Management
Obtenga respuestas a preguntas comunes, patrones y procedimientos recomendados para Azure API
Management.
NOTE
Ponerse en contacto con nosotros

¿Cómo se puede hacer una pregunta al equipo de Microsoft Azure API Management?
Preguntas más frecuentes

¿Qué significa que una característica se encuentra en su versión preliminar?
¿Cómo se puede proteger la conexión entre la puerta de enlace de API Management y mis servicios back-end?
¿Cómo se puede copiar mi instancia de servicio de API Management en una nueva instancia?
¿Es posible administrar mi instancia de API Management mediante programación?
¿Cómo se puede agregar un usuario al grupo de administradores?
¿Por qué la directiva que deseo agregar no está habilitada en el editor de directivas?
¿Cómo se configuran varios entornos en una sola API?
¿Se puede usar SOAP con API Management?
¿Es constante la dirección IP de la puerta de enlace de API Management? ¿Puedo usarla en las reglas de
firewall?
¿Se puede configurar un servidor de autorización de OAuth 2.0 con seguridad AD FS?
¿Qué método de enrutamiento utiliza API Management en implementaciones en varias ubicaciones
geográficas?
¿Se puede usar una plantilla de Azure Resource Manager para crear una instancia del servicio API
Management?
¿Se puede usar un certificado SSL autofirmado para un back-end?
¿Por qué se obtiene un error de autenticación al intentar clonar un repositorio?
¿Funciona API Management con Azure ExpressRoute?
¿Por qué es necesaria una subred dedicada en las redes virtuales de estilo Resource Manager cuando API
Management está implementado en ellas?
¿Cuál es el tamaño de subred mínimo necesario al implementar API Management en una red virtual?
¿Se puede mover un servicio API Management de una suscripción a otra?
¿Existen restricciones de la importación de mi API o problemas conocidos con ella?
¿Cómo se puede hacer una pregunta al equipo de Microsoft Azure API Management?
Puede ponerse en contacto con nosotros mediante una de estas opciones:
Publicar sus preguntas en nuestro foro de MSDN de API Management.
Envíe un correo electrónico a mailto:[email protected].
Enviar una solicitud de característica en el foro de comentarios de Azure.
¿Qué significa que una característica se encuentra en su versión preliminar?
Cuando una característica está en su versión preliminar, significa que estamos buscando activamente comentarios
acerca de cómo funciona la característica. Una característica en versión preliminar está funcionalmente completa,
pero es posible que hagamos cambios importantes en respuesta a los comentarios de los clientes. Se recomienda
no depender de una característica que está en su versión preliminar en el entorno de producción. Si tiene
cualquier comentario sobre las características de la versión preliminar, háganoslo saber a través de una de las
opciones de contacto que aparecen en ¿Cómo se puede hacer una pregunta al equipo de Microsoft Azure API
Management?.
¿Cómo se puede proteger la conexión entre la puerta de enlace de API Management y mis servicios back-end?
Tiene varias opciones para proteger la conexión entre la puerta de enlace de API Management y mis servicios
back-end. Puede:
Use la autenticación básica HTTP. Para más información, consulte Importación y publicación de la primera API.
Use la autenticación mutua de SSL como se describe en Cómo asegurar servicios back-end con la
autenticación de certificados de cliente en Azure API Management.
Utilice la lista blanca IP en su servicio back-end. En todos los niveles de API Management, a excepción del nivel
de consumo, la dirección IP de la puerta de enlace permanece constante, con algunas salvedades. Puede
establecer una lista blanca para permitir esta dirección IP. Puede obtener la dirección IP de la instancia de API
Management en el Panel de Azure Portal.
Conecte la instancia de API Management a Azure Virtual Network.
¿Cómo se puede copiar mi instancia de servicio de API Management en una nueva instancia?
Tiene varias opciones si desea copiar una instancia de API Management a una nueva instancia. Puede:
Usar la función de copia de seguridad y restauración de API Management. Para más información, consulte
Procedimiento para implementar la recuperación ante desastres mediante copias de seguridad y restauración
del servicio en Azure API Management.
Crear su propia característica de copia de seguridad y restauración mediante la API de REST de API
Management. Usar la API de REST para guardar y restaurar las entidades de la instancia de servicio que desee.
Descargar la configuración del servicio mediante Git y cargarla en una nueva instancia. Para más información,
consulte Guardado y configuración del servicio API Management mediante Git.
¿Es posible administrar mi instancia de API Management mediante programación?
Sí, puede administrar API Management mediante programación utilizando:
La API de REST de API Management.
El SDK de la biblioteca de administración del servicio Microsoft Azure ApiManagement.
Los cmdlets de implementación del servicio y administración del servicio de PowerShell.
¿Cómo se puede agregar un usuario al grupo de administradores?
A continuación se indica cómo agregar un usuario al grupo de administradores:
2. Vaya al grupo de recursos que tiene la instancia de API Management que desea actualizar.
3. En API Management, asigne el rol Colaborador de Service API Management.
Ahora el colaborador recién agregado puede usar los cmdlets de Azure PowerShell. A continuación se indica
cómo iniciar sesión como administrador:
1. Utilice el cmdlet Connect-AzAccount para iniciar sesión.
2. Establezca el contexto para la suscripción que tiene el servicio mediante
Set-AzContext -SubscriptionID <subscriptionGUID> .
3. Obtenga la dirección URL de inicio de sesión único mediante
Get-AzApiManagementSsoToken -ResourceGroupName <rgName> -Name <serviceName> .
4. Utilice la dirección URL para acceder al portal de administración.
¿Por qué la directiva que deseo agregar no está habilitada en el editor de directivas?
Si la directiva que desea agregar aparece atenuada o sombreada en el editor de directivas, asegúrese de que está
en el ámbito correcto para la directiva. Cada instrucción de la directiva está diseñada para su uso en determinados
ámbitos y secciones de la directiva. Para revisar las secciones y los ámbitos de una directiva, consulte en la sección
sobre el uso de la directiva en API Management policies (Directivas de API Management).
¿Cómo se configuran varios entornos en una sola API?
Para configurar varios entornos; por ejemplo, un entorno de prueba y un entorno de producción, en una sola API,
tiene dos opciones. Puede:
Hospedar diferentes API en el mismo inquilino.
Hospedar las mismas API en diferentes inquilinos.
¿Se puede usar SOAP con API Management?
Ahora se admite el paso a través de SOAP. Los administradores pueden importar el WSDL de su servicio SOAP,
y Azure API Management creará un front-end SOAP. Ahora hay documentación del portal para desarrolladores,
la consola de prueba, las directivas y el análisis disponible para los servicios SOAP.
¿Es constante la dirección IP de la puerta de enlace de API Management? ¿Puedo usarla en las reglas de
firewall?
En todos los niveles de API Management, la dirección IP pública (VIP ) del inquilino de API Management es
estática para la vigencia del inquilino, con algunas excepciones. La dirección IP cambia en estas circunstancias:
El servicio se elimina y se vuelve a crear.
La suscripción al servicio se suspende o se advierte (por ejemplo, por falta de pago) y luego se reinstaura.
Se agrega o se quita Azure Virtual Network (solo se puede usar Virtual Network en los niveles Desarrollador y
Premium).
Para las implementaciones de varias regiones, la dirección regional cambia si se vacía la información de la región
y, a continuación, se reinstaura (solo se puede usar puede utilizar la implementación en varias regiones en el nivel
Premium).
A los inquilinos de nivel Premium configurados para la implementación en varias regiones se les asigna una
dirección IP pública por región.
Puede obtener su dirección IP (o direcciones IP, en una implementación de varias regiones) en la página de
inquilino en Azure Portal.
¿Se puede configurar un servidor de autorización de OAUth 2.0 con seguridad AD FS?
Para más información sobre cómo configurar un servidor de autorización de OAuth 2.0 con la seguridad de
Servicios de federación de Active Directory (AD FS ), consulte Using ADFS in API Management (Uso de ADFS en
API Management).
¿Qué método de enrutamiento utiliza API Management en implementaciones en varias ubicaciones
geográficas?
API Management usa el método de enrutamiento de tráfico de rendimiento en las implementaciones en varias
ubicaciones geográficas. El tráfico entrante se enrutará a la puerta de enlace de API más cercana. Si una región se
queda sin conexión, el tráfico entrante se enruta automáticamente a la siguiente puerta de enlace más cercana.
Aprenda más acerca de los métodos de enrutamiento en Métodos de enrutamiento de tráfico de Traffic Manager.
¿Se puede usar una plantilla de Azure Resource Manager para crear una instancia del servicio API
Management?
Sí. Consulte las plantillas de inicio rápido del servicio Azure API Management Service.
¿Se puede usar un certificado SSL autofirmado para un back-end?
Sí. Puede hacerse a través de PowerShell o enviando el certificado directamente a la API. Esta operación
deshabilitará la validación de la cadena de certificados y le permitirá usar certificados autofirmados o firmados de
forma privada cuando se comunique con los servicios back-end desde API Management.
Método de Powershell
Utilice el cmdlet de PowerShell New-AzApiManagementBackend (con el nuevo back-end) o
Set-AzApiManagementBackend (con el back-end existente) y establezca el parámetro
-SkipCertificateChainValidation en True .
$context = New-AzApiManagementContext -resourcegroup 'ContosoResourceGroup' -servicename 'ContosoAPIMService'

New-AzApiManagementBackend -Context $context -Url 'https://contoso.com/myapi' -Protocol http -
SkipCertificateChainValidation $true
Método de actualización directo con la API

1. Cree una entidad de back-end mediante API Management.
2. Establezca la propiedad skipCertificateChainValidation en true.
3. Si ya no desea permitir los certificados autofirmados, puede eliminar la entidad de back-end o establecer la
propiedad skipCertificateChainValidation en false.
¿Por qué se obtiene un error de autenticación al intentar clonar un repositorio?
Si utiliza el Administrador de credenciales de Git o si está intentando clonar un repositorio Git con Visual Studio,
se puede encontrar un problema conocido en el cuadro de diálogo de credenciales de Windows. El cuadro de
diálogo limita la longitud de la contraseña a 127 caracteres y se trunca la contraseña generada por Microsoft.
Estamos trabajando para acortar la contraseña. De momento, use Git Bash para clonar el repositorio Git.
¿Funciona API Management con Azure ExpressRoute?
Sí. API Management funciona con Azure ExpressRoute.
¿Por qué es necesaria una subred dedicada en las redes virtuales de estilo Resource Manager cuando API
Management está implementado en ellas?
El requisito de subred dedicada para API Management procede del hecho de que se basa en el modelo de
implementación clásica (capa V1 de PAAS ). Aunque podemos implementarlo en una red virtual de Resource
Manager (capa V2), hay consecuencias derivadas de ello. El modelo de implementación clásica de Azure no está
estrechamente vinculado al modelo de Resource Manager, así que si crea un recurso en la capa V2, la capa V1 no
lo sabe y pueden surgir problemas, por ejemplo, que API Management intente usar una IP que ya está asignada a
una NIC (creada en V2). Para más información sobre la diferencia entre el modelo de implementación clásica y el
modelo de Resource Manager de Azure consulte las diferencias en los modelos de implementación.
¿Cuál es el tamaño de subred mínimo necesario al implementar API Management en una red virtual?
El tamaño de subred mínimo necesario para implementar API Management es /29, que es el mínimo que admite
Azure.
¿Se puede mover un servicio API Management de una suscripción a otra?
Sí. Para más información, consulte vea Traslado de los recursos a un nuevo grupo de recursos o a una nueva
suscripción.
¿Existen restricciones de la importación de mi API o problemas conocidos con ella?
Problemas conocidos y restricciones para formatos Open API(Swagger), WSDL y WADL.

Ehhhh

Cargado por

Copyright:

Formatos disponibles

Ehhhh

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ehhhh

Cargado por

Copyright:

Formatos disponibles

Contents

Documentación de Azure API Management

Portal para desarrolladores

API Management y la economía de la API

CARACTERÍSTICA CONSUMO DEVELOPER BÁSICA ESTÁNDAR PREMIUM

Integración de Sin Sí Sin Sí Sí

Portal para Sin Sí Sí Sí Sí

Memoria caché Sin Sí Sí Sí Sí

Análisis integrado Sin Sí Sí Sí Sí

aplicaciones y correo electrónico.

Inicio de sesión en Azure

Creación de un nuevo servicio

Nombre Un nombre único para el servicio Este nombre no se podrá

Suscripción Su suscripción La suscripción en que se creará

Grupo de recursos apimResourceGroup Seleccione un nuevo recurso o

Ubicación Oeste de EE. UU. Seleccione la región geográfica

Nombre de la organización El nombre de su organización Este nombre se usa en varios

Correo electrónico del [email protected] Especifique la dirección de correo

Plan de tarifa Developer Especifique el nivel de

Vaya a la instancia de API Management.

El icono de API Management ( ) aparece ahora en el menú izquierdo del portal.

5. Confirme la eliminación; para ello, escriba el nombre del grupo de recursos.

Inicio de sesión en Azure

Uso de Azure Cloud Shell

OPCIÓN EJEMPLO O VÍNCULO

Seleccione Probarlo en la esquina superior derecha de un

Vaya a https://shell.azure.com o seleccione el botón Iniciar

Seleccione el botón Cloud Shell en la barra de menús de la

Para ejecutar el código de este artículo en Azure Cloud Shell:

Creación de un grupo de recursos

New-AzResourceGroup -Name myResourceGroup -Location WestUS

Creación de un servicio de API Management

New-AzApiManagement -ResourceGroupName "myResourceGroup" -Location "West US" -Name "apim-name" -Organization

Remove-AzResourceGroup -Name myResourceGroup

Vaya a la instancia de API Management.

El icono de API Management ( ) aparece ahora en el menú izquierdo del portal.

Importación y publicación de una API de back-end

CONFIGURACIÓN VALOR DESCRIPCIÓN

Especificación OpenAPI https://conferenceapi.azurewebsites. Hace referencia al servicio que

Nombre para mostrar API de conferencia de Si presiona la tecla Tab después de

Nombre demo-conference-api Proporciona un nombre único para

Descripción Proporcione una descripción Si presiona la tecla Tab después de

Esquema URL HTTPS Determina los protocolos que se

Sufijo de dirección URL de API conference El sufijo se anexa a la dirección URL

Productos Sin límite Los productos son asociaciones de

Etiquetas Etiquetas para organizar las API.

¿Definir versión de esta API? Para más información sobre las

Llamada a una operación desde el portal para desarrolladores

Crear y publicar un producto

NOMBRE Un nombre descriptivo del producto.

DESCRIPCIÓN El campo Configuración le permite incluir información

Estado Presione Publicado si desea publicar el producto. Para

Requiere suscripción Seleccione Require subscription (Requerir suscripción) si

Requiere aprobación Seleccione Require approval (Requerir aprobación) si

Límite de recuento de suscripciones Para limitar el número de varias suscripciones simultáneas,

API existentes Los productos son asociaciones de una o varias API.

3. Haga clic en Crear para crear el nuevo producto.

Incorporación de API a un producto

Creación de una API de prueba