Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
As secções seguintes apresentam os produtos de API e os conceitos relacionados, como as quotas e as chaves de API.
O que é um produto de API?
Enquanto fornecedor de APIs, cria produtos de API para agrupar as suas APIs e disponibilizá-las aos programadores de apps para consumo. Pode considerar os produtos de API como a sua linha de produtos.
Especificamente, um produto API agrupa uma ou mais operações. Uma operação especifica um proxy de API e caminhos de recursos que podem ser acedidos nesse proxy. Uma operação também pode limitar o acesso por métodos HTTP e por quota.
Os produtos da API são o mecanismo central para o controlo de acesso às suas APIs. Ao definir um ou mais produtos da API numa app de programador, pode restringir o acesso a proxies com uma chave da API. No Apigee, as chaves da API são aprovisionadas, não para as APIs em si, mas para os produtos de API. Por outras palavras, as chaves de API são fornecidas para conjuntos de operações que definem uma linha de produtos ou um plano de serviços específico.
Exemplos de utilização comuns
Pode criar vários produtos de API que contenham operações para abordar exemplos de utilização específicos. Por exemplo, pode criar um produto de API que agrupe várias operações que contenham recursos de mapeamento para permitir que os programadores integrem facilmente mapas nas respetivas aplicações.
Além disso, pode usar produtos de API para definir níveis de preços com base em critérios como:
O número de pedidos:
- Premium: pedidos ilimitados por dia
- Básico: até 1000 pedidos por dia
- Grátis: até 100 pedidos por dia
Ou nível de acesso:
- Premium: ler, escrever, atualizar e eliminar
- Básico: ler e atualizar
- Grátis: só de leitura
Ou qualquer combinação das opções acima:
- Extra Premium: leia e escreva um número ilimitado de vezes por dia
- Premium: ler e escrever até 1000 pedidos por dia
- Básico: acesso de leitura e escrita até 100 vezes por dia
- Grátis: leia até 1000 vezes por dia
- Gratuito: acesso só de leitura limitado a 100 pedidos por dia
Requisitos
Os produtos de API que fazem parte do pagamento mediante utilização têm de incluir:
- Proxies extensíveis criados com hooks de fluxo ou
- Políticas extensíveis, como a política VerifyAPIKey ou a política OAuthv2
Operações
Uma operação é um grupo de atributos que restringe o acesso a um ou mais proxies de API com base em critérios como o caminho do recurso, o método HTTP e a quota. Uma operação inclui estes atributos:
| Atributo | Obrigatório? | Descrição |
|---|---|---|
| proxy de API | Obrigatória | Cada grupo de operações tem de especificar um proxy de API. Só é permitido um proxy por grupo de operações. |
| Serviço remoto | Depende | Obrigatório apenas se instalar e planear usar o Apigee Adapter for Envoy. |
| Caminho do recurso | Obrigatória | Cada grupo de operações tem de especificar um ou mais caminhos de recursos. Caminhos de recursos numa operação restringem o acesso a recursos específicos num proxy de API. (Um caminho de recurso é a parte de um URL de pedido de proxy de API que surge a seguir ao caminho base do proxy.) |
| Método HTTP | Opcional | Também pode restringir o acesso a um proxy por método HTTP. Por exemplo, se especificar os métodos GET
e POST para um grupo de operações, apenas os pedidos HTTP GET e
POST podem aceder ao proxy para o caminho do recurso especificado. Se nenhum método for especificado, todos os métodos são permitidos. |
| Quota | Opcional | Pode especificar uma quota para o grupo de operações. A quota especificada num grupo de operações tem precedência sobre uma quota ao nível do produto da API, se especificada. |
| Atributos personalizados | Opcional | Os atributos personalizados são úteis para métricas, monitorização ou casos em que quer armazenar informações adicionais com um produto API que podem ser acedidas ou obtidas mais tarde. Os atributos
personalizados associados a uma operação existem além de quaisquer atributos
personalizados ao nível do produto da API e podem ser acedidos no tempo de execução como variáveis de fluxo com o prefixo
apiproduct.operation.attributes.
|
Chaves da API
Quando regista a app de um programador na sua organização, a app tem de estar associada a, pelo menos, um produto de API. Como resultado da sincronização de uma app com um ou mais produtos API, o Apigee atribui à app uma chave de consumidor única. Consulte também Controlar o acesso às suas APIs através do registo de apps.
A chave de consumidor ou o token de acesso funcionam como credenciais de pedido. O programador de apps incorpora a chave de consumidor na app para que, quando a app faz um pedido a uma API alojada pela Apigee, a app transmita a chave de consumidor no pedido de uma das seguintes formas:
- Quando a API usa a validação da chave da API, a app tem de transmitir a chave do consumidor diretamente.
- Quando a API usa a validação de tokens OAuth, a app tem de transmitir um token derivado da chave de consumidor.
A aplicação da chave da API não ocorre automaticamente. Quer use a chave do consumidor ou os tokens OAuth como credenciais de pedido, o proxy de API valida as credenciais de pedido nos seus proxies de API incluindo uma política VerifyAPIKey ou uma configuração de política VerifyAccessToken (consulte a política OAuthv2) no fluxo adequado. Se não incluir uma política de aplicação de credenciais no seu proxy de API, qualquer autor da chamada pode invocar as suas APIs.
Para validar as credenciais transmitidas no pedido, o Apigee executa os seguintes passos:
- Obtenha as credenciais transmitidas com o pedido. No caso da validação do token OAuth, o Apigee verifica se o token não expirou e, em seguida, procura a chave do consumidor que foi usada para gerar o token.
- Recupere a lista de produtos da API aos quais a chave do consumidor foi associada.
- Confirme se o proxy de API atual está incluído no produto de API, se o caminho do recurso atual (caminho do URL) estiver ativado no produto de API e, se estiver incluído no produto, se o pedido usa um verbo HTTP especificado.
- Verifique se a quota, se especificada, não foi excedida.
- Verifique se a chave do consumidor não expirou nem foi revogada, se a app não foi revogada e se o programador da app está ativo.
Se todas as verificações acima forem aprovadas, a validação de credenciais é bem-sucedida.
Em suma, o Apigee gera automaticamente chaves de consumidor, mas os publicadores de APIs têm de aplicar a verificação de chaves em proxies de API através de políticas adequadas.
Aprovação de chaves
Por predefinição, todos os pedidos para obter uma chave de acesso a um produto de API a partir de uma app são aprovados automaticamente. Em alternativa, pode configurar o produto API para que tenha de aprovar as chaves manualmente. A definição para isto é descrita no artigo Gerir produtos de API. Neste caso, tem de aprovar os pedidos de chaves de qualquer app que adicione o produto da API. Para mais informações, consulte o artigo Controlar o acesso às suas APIs através do registo de apps.
Quotas
As quotas podem proteger os seus servidores de back-end de variações de tráfego elevadas e diferenciar a sua linha de produtos. Por exemplo, pode agrupar recursos com uma quota elevada como um produto premium e usar o mesmo pacote com uma quota inferior como um produto básico. As quotas podem ajudar a proteger os seus servidores de ficarem sobrecarregados se um produto for popular e receber uma grande quantidade de pedidos num curto período de tempo.
Pode especificar uma quota que se aplica a todos os proxies de API incluídos no produto de API ou especificar quotas ao nível da operação. Uma quota especificada numa operação tem precedência sobre uma quota definida ao nível do produto da API.
A definição de limites de quota num produto de API não aplica automaticamente a quota. É simplesmente um limite predefinido que pode ser referenciado nas políticas de quotas. Seguem-se algumas vantagens de definir uma quota no produto para que as políticas de quotas possam ser usadas como referência:
- Use uma política de quotas para aplicar uma definição uniforme a todos os proxies de API num produto de API.
- Se alterar as definições de quota do produto da API em tempo de execução, as políticas de quota fazem automaticamente referência às definições de quota atualizadas.
Para mais informações, consulte o seguinte:
- Política de quotas
- Como interagem as definições de quota num produto de API com as políticas de quota num proxy de API?.
âmbitos do OAuth
Pode definir âmbitos de OAuth como uma lista separada por vírgulas que tem de estar presente nos tokens de acesso associados ao produto. Para mais informações sobre a utilização de âmbitos com políticas de OAuth do Apigee, consulte o artigo Trabalhar com âmbitos de OAuth2.
Níveis de acesso
Quando define um produto de API, pode definir os seguintes níveis de acesso:
| Nível de acesso | Descrição |
|---|---|
Public |
Produtos de API disponíveis para todos os programadores. Pode adicioná-los a portais do programador integrados ou baseados em Drupal. |
Private ou Internal only |
Produtos de API concebidos para utilização privada ou interna.
Para o portal integrado, pode adicionar produtos de API Para portais do programador baseados no Drupal, pode gerir o acesso a produtos de API
|