Migração para API v4

Encontre informações detalhadas sobre o plano da Azion para migração para a nova API v4.

Visão geral da migração

Azion está lançando a API v4 nos próximos meses para aprimorar o desempenho, a flexibilidade e a gestão de recursos da plataforma. Esta atualização vai além de uma simples mudança de API: ela introduz um novo conceito central, Workloads, além de novos produtos como Connectors e Custom Pages, e traz melhorias significativas tanto para a API quanto para o Console da Azion.

A API v4 apresenta uma nova arquitetura assíncrona e orientada a eventos, projetada para maior desempenho e resiliência. O novo modelo de recurso Workload centraliza a configuração, facilitando o gerenciamento, reutilização e escalabilidade das suas aplicações. O Connectors permite integrações de backend mais flexíveis e seguras.

A API v4 da Azion já está disponível em Preview para novas contas do suporte Developer e será liberada em ondas para Disponibilidade Geral (GA) de acordo com o seu serviço de suporte.

Pontos-chave sobre a migração:

A migração afeta tanto a plataforma (com a introdução de Workloads, Connectors e Custom Pages) quanto os endpoints da API.
Algumas configurações foram movidas para novos locais para melhorar a reutilização e a clareza.
Novas contas developer usarão a API v4 por padrão. Contas existentes serão migradas em ondas.
Durante a transição, você pode ver documentações com banners permitindo alternar entre as versões v3 e v4 de um recurso.
Após a migração da sua conta, não será mais possível utilizar os endpoints da API v3 ou criar novos Domains, Origins ou Error Responses. Você deverá utilizar os novos recursos equivalentes.

A API v4 representa um avanço tecnológico, fornecendo a base para futuras funcionalidades e maior eficiência operacional em toda a Azion Web Platform.

As alterações descritas neste documento serão aplicadas à sua conta somente após a migração da sua conta.

Migração da API

Todos os endpoints da API serão migrados para a v4 em ondas. Para visualizar os endpoints e parâmetros disponíveis, consulte a referência da API v4.

A API v3 está agora obsoleta e não receberá mais atualizações. Ela será descontinuada em uma data futura. Após essa data, todas as operações deverão ser realizadas exclusivamente utilizando a API v4.

Ações necessárias

Automatizações, scripts e pipelines de CI/CD conectados à Azion devem ser atualizados para utilizar a API v4 até o prazo especificado.

Novas funcionalidades

Autenticação JWT.
Histórico de atividades via GraphQL para auditoria completa.
Nova arquitetura orientada a eventos.

Benefícios da migração

Desempenho aprimorado
Maior flexibilidade
Acesso a updates futuros.
Parâmetros de consulta: Agora você pode usar parâmetros de consulta para personalizar solicitações de API. As opções suportadas incluem ordenar resultados por um campo específico e filtrar resultados por um termo de pesquisa ou por valor de campo. Isso permite que você recupere e organize dados de acordo com seus requisitos.

Mudanças nas Applications

A funcionalidade das Applications permanece inalterada. No entanto, algumas opções de configuração que antes eram gerenciadas dentro das Applications foram movidas para outros componentes como parte da migração.

Configuração	Novo local
Applications > Main Settings > Delivery Settings	Workloads
Applications > Origin Settings	Connectors
Applications > Error Responses	Custom Pages
Applications > Load Balancer	Connectors

Mudanças de cobrança e métricas

Ao migrar para a API v4, há mudanças importantes na forma como o uso é medido e cobrado. Essas mudanças podem afetar seu faturamento dependendo dos seus padrões de uso.

Workloads

Com a introdução dos Workloads, as métricas de Requests e Data Transfer passam a ser medidas no nível do Workload em vez do nível da Application.

Métrica	API v3 (Applications)	API v4 (Workloads)
Requests	Medidas por Application	Medidas por Workload
Data Transfer	Medidas por Application	Medidas por Workload

Após a migração, você verá as métricas de Requests e Data Transfer no dashboard e nos relatórios de faturamento do seu Workload. Os valores medidos permanecem os mesmos de antes da migração.

Connectors e Load Balancer

A métrica de Data Transfer do Load Balancer foi alterada significativamente:

Métrica	API v3	API v4
Load Balancer Data Transfer	Todo o tráfego da Application	Apenas tráfego entre Connector e Origin

API v3: Data Transfer era calculado com base em todo o tráfego que passava pela sua Application.
API v4: Data Transfer é calculado apenas sobre o tráfego entre seu Connector e seus servidores de origem (tráfego edge-to-origin).

Essa mudança pode resultar em otimização de custos, pois apenas o tráfego de backend passa a ser medido para fins de Load Balancer.

Firewall

O modelo de mensuração de requests do Firewall foi atualizado:

Métrica	API v3	API v4
Firewall Requests	Apenas firewalls com Network Shield habilitado	Todos os firewalls (todas as requests que passam)

API v3: Requests do Firewall eram mensuradas apenas para firewalls com o módulo Network Shield habilitado.
API v4: O Firewall mede todas as requests que passam por ele, incluindo:
- Requests processadas pelo WAF
- Requests processadas pelo Network Shield
- Todas as requests que transitam pelo Firewall

Essa abordagem consolidada significa que você pode ver um aumento na contagem de requests do Firewall após a migração, pois todas as requests que passam por qualquer Firewall agora são medidas, não apenas aquelas com Network Shield habilitado.

Origin Shield

Com a introdução dos Connectors na API v4, uma nova métrica de cobrança está disponível:

Métrica	API v3	API v4
Shielded Connectors	Não disponível	Número de Connectors com Origin Shield habilitado

API v3: Origin Shield estava disponível como um Add-On separado com uma Subscription. Nenhum Shielded Connector era medido.
API v4: Connectors com o módulo Origin Shield habilitado são contabilizados como Shielded Connectors e aparecem nos seus relatórios de faturamento.

Esta é uma nova métrica. Se você habilitar Origin Shield nos seus Connectors, verá Shielded Connectors nos seus relatórios de faturamento após a migração.

Comparação de Endpoints da API

Esta seção fornece uma comparação analítica detalhada entre os endpoints da API v3 e da API v4, incluindo URLs base, estruturas de requisição/resposta e diferenças comportamentais.

Visão Geral da Arquitetura

Aspecto	API v3	API v4
URL Base	`https://api.azionapi.net/`	`https://api.azion.com/v4/`
Arquitetura	Síncrona	Assíncrona (orientada a eventos)
Autenticação	Token no header	Token ou JWT no header
Formato de Resposta	Resultados diretos no objeto `results`	Baseado em estado com objetos `state` e `data`
Modelo de Recursos	Recursos aninhados sob Applications	Recursos independentes vinculados via Deployments
Header de Versão da API	`Accept: application/json; version=3`	Não é necessário

Mapeamento de Recursos

Recurso API v3	Endpoint API v3	Recurso API v4	Endpoint API v4
Domains	`/domains`	Workloads	`/workspace/workloads`
Origins	`/edge_applications/{id}/origins`	Connectors	`/edge_connector/connectors`
Error Responses	`/edge_applications/{id}/error_responses`	Custom Pages	`/workspace/custom_pages`
Applications	`/edge_applications`	Applications	`/edge_application/applications`
Rules Engine	`/edge_applications/{id}/rules_engine`	Rules Engine	`/edge_application/applications/{id}/rules_engine`
Cache Settings	`/edge_applications/{id}/cache_settings`	Cache Settings	`/edge_application/applications/{id}/cache_settings`
Device Groups	`/edge_applications/{id}/device_groups`	Device Groups	`/edge_application/applications/{id}/device_groups`
Functions	`/edge_functions/functions`	Functions	`/edge_functions/functions`
Digital Certificates	`/digital_certificates`	Digital Certificates	`/digital_certificates/certificates`
Edge Firewall	`/edge_firewall`	Edge Firewall	`/edge_firewall/firewalls`
Network Lists	`/network_lists`	Network Lists	`/workspace/network_lists`

Domains (v3) → Workloads + Deployments (v4)

Na API v3, Domains eram um recurso único que conectava uma Application ao tráfego de usuários. Na API v4, esse conceito é dividido em Workloads (configuração de infraestrutura e protocolos) e Deployments (vinculação com Applications e outros componentes).

Comparação de Endpoints

Operação	API v3	API v4
Listar todos	`GET /domains`	`GET /workspace/workloads`
Obter um	`GET /domains/{domain_id}`	`GET /workspace/workloads/{workload_id}`
Criar	`POST /domains`	`POST /workspace/workloads`
Atualizar	`PATCH /domains/{domain_id}`	`PATCH /workspace/workloads/{workload_id}`
Deletar	`DELETE /domains/{domain_id}`	`DELETE /workspace/workloads/{workload_id}`
Vincular à Application	Incorporado na criação do Domain	`POST /workspace/workloads/{workload_id}/deployments`

Payload de Requisição: Criar Domain/Workload

API v3 (Domains):

{

"name": "string",

"cname_access_only": false,

"cnames": ["custom.example.com"],

"digital_certificate_id": null,

"edge_application_id": 1234,

"edge_firewall_id": null,

"is_active": true,

"environment": "production"

}

API v4 (Workloads):

{

"name": "string",

"active": true,

"infrastructure": 1,

"protocols": {

"http": {

"versions": ["http1", "http2"]

}

},

"tls": {

"certificate": null,

"ciphers": 7,

"minimum_version": "tls_1_3"

},

"domains": ["custom.example.com"],

"workload_domain_allow_access": true

}

Payload de Requisição: Vincular à Application (Deployment)

API v3: A vinculação ocorre automaticamente durante a criação do Domain através do campo edge_application_id.

API v4 (Deployments): Uma requisição separada é necessária:

{

"name": "string",

"active": true,

"current": true,

"strategy": {

"type": "default",

"attributes": {

"edge_application": 1234,

"edge_firewall": null,

"custom_page": null

}

Estrutura de Resposta

Resposta API v3 (Síncrona):

{

"results": {

"id": 5678,

"name": "string",

"cnames": ["custom.example.com"],

"cname_access_only": false,

"digital_certificate_id": null,

"edge_application_id": 1234,

"is_active": true,

"domain_name": "xxxxxxxxxx.map.azionedge.net",

"environment": "production"

}

Resposta API v4 (Assíncrona):

{

"state": "pending",

"data": {

"id": 5678,

"name": "string",

"active": true,

"infrastructure": 1,

"last_editor": "user@example.com",

"last_modified": "2025-01-15T10:30:00Z",

"domains": ["custom.example.com"],

"workload_domain": "xxxxxxxxxx.map.azionedge.net",

"workload_domain_allow_access": true,

"tls": { "certificate": null, "ciphers": 7, "minimum_version": "tls_1_3" },

"protocols": { "http": { "versions": ["http1", "http2"] } }

}

Principais Diferenças Comportamentais

Aspecto	API v3	API v4
Fluxo de criação	Única requisição cria Domain e vincula à Application	Dois passos: criar Workload, depois criar Deployment
Identificador	`id` numérico	`id` numérico (Workload) + ID de Deployment separado
CNAME Access	`cname_access_only` booleano	`workload_domain_allow_access` booleano
Ambiente	`environment: "production"` ou `"staging"`	`infrastructure: 1` (Produção) ou `2` (Staging)
Resposta	Imediata, síncrona	Assíncrona com `state: "pending"`
mTLS	Campos no Domain	Objeto `mtls` separado com verification, certificate, crl

Origins (v3) → Connectors (v4)

Na API v3, Origins eram recursos aninhados sob Applications. Na API v4, Connectors são recursos independentes de nível superior que podem ser reutilizados em múltiplas Applications.

Comparação de Endpoints

Operação	API v3	API v4
Listar todos	`GET /edge_applications/{app_id}/origins`	`GET /edge_connector/connectors`
Obter um	`GET /edge_applications/{app_id}/origins/{origin_key}`	`GET /edge_connector/connectors/{connector_id}`
Criar	`POST /edge_applications/{app_id}/origins`	`POST /edge_connector/connectors`
Atualizar	`PATCH /edge_applications/{app_id}/origins/{origin_key}`	`PATCH /edge_connector/connectors/{connector_id}`
Deletar	`DELETE /edge_applications/{app_id}/origins/{origin_key}`	`DELETE /edge_connector/connectors/{connector_id}`

Payload de Requisição: Criar Origin/Connector

API v3 (Origins - Single Origin):

{

"name": "My Origin",

"origin_type": "single_origin",

"addresses": [

{ "address": "origin.example.com" }

],

"origin_protocol_policy": "https",

"host_header": "www.example.com",

"origin_path": "/api",

"connection_timeout": 60,

"timeout_between_bytes": 120,

"hmac_authentication": false,

"hmac_region_name": "",

"hmac_access_key": "",

"hmac_secret_key": ""

}

API v3 (Origins - Load Balancer):

{

"name": "My Load Balanced Origin",

"origin_type": "load_balancer",

"addresses": [

{ "address": "origin1.example.com", "weight": 1, "server_role": "primary" },

{ "address": "origin2.example.com", "weight": 1, "server_role": "primary" }

],

"origin_protocol_policy": "https",

"host_header": "www.example.com"

}

API v4 (Connectors - Tipo HTTP):

{

"name": "My Connector",

"active": true,

"type": "http",

"attributes": {

"addresses": [

{

"active": true,

"address": "origin.example.com",

"http_port": 80,

"https_port": 443

}

],

"connection_options": {

"dns_resolution": "preserve",

"transport_policy": "force_https",

"http_version_policy": "http1_1",

"host": "www.example.com",

"path_prefix": "/api",

"following_redirect": false,

"real_ip_header": "X-Real-IP",

"real_port_header": "X-Real-PORT"

},

"modules": {

"load_balancer": {

"enabled": false,

"config": {

"method": "round_robin",

"max_retries": 0,

"connection_timeout": 60,

"read_write_timeout": 120

}

},

"origin_shield": {

"enabled": false,

"config": null

}

API v4 (Connectors - Tipo Object Storage):

{

"name": "My Storage Connector",

"active": true,

"type": "edge_storage",

"attributes": {

"bucket": "my-bucket",

"prefix": "/"

}

Estrutura de Resposta

Resposta API v3:

{

"results": {

"origin_id": 123,

"origin_key": "abc123def456",

"name": "My Origin",

"origin_type": "single_origin",

"addresses": [

{ "address": "origin.example.com", "weight": null, "server_role": "primary", "is_active": true }

],

"origin_protocol_policy": "https",

"host_header": "www.example.com",

"origin_path": "/api",

"connection_timeout": 60,

"timeout_between_bytes": 120

}

Resposta API v4:

{

"state": "pending",

"data": {

"id": 789,

"name": "My Connector",

"active": true,

"type": "http",

"last_editor": "user@example.com",

"last_modified": "2025-01-15T10:30:00Z",

"attributes": {

"addresses": [

{ "active": true, "address": "origin.example.com", "http_port": 80, "https_port": 443 }

],

"connection_options": {

"dns_resolution": "preserve",

"transport_policy": "force_https",

"host": "www.example.com",

"path_prefix": "/api"

},

"modules": { "load_balancer": { "enabled": false }, "origin_shield": { "enabled": false } }

}

Principais Diferenças Comportamentais

Aspecto	API v3	API v4
Escopo do recurso	Aninhado sob Application	Recurso independente de nível superior
Reutilização	Uma Origin por Application	Um Connector pode servir múltiplas Applications
Distinção de tipo	`origin_type: "single_origin"` ou `"load_balancer"`	`type: "http"` com módulo `load_balancer` habilitado para múltiplos endereços
Política de protocolo	`origin_protocol_policy`	`connection_options.transport_policy`
Host header	`host_header`	`connection_options.host`
Path	`origin_path`	`connection_options.path_prefix`
Timeouts	`connection_timeout`, `timeout_between_bytes`	`modules.load_balancer.config.connection_timeout`, `read_write_timeout`
HMAC Auth	Campos diretos na Origin	Requer módulo `origin_shield`
Portas	Não configuráveis	`http_port`, `https_port` por endereço
Identificador	`origin_key` usado para updates	`id` usado para todas as operações

Ativando um Connector/Origin em uma Application

API v3 - Rules Engine:

{

"name": "Set Origin Rule",

"behaviors": [

{ "name": "set_origin", "target": "<origin_id>" }

],

"criteria": [

[{ "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/api" }]

]

}

API v4 - Rules Engine:

{

"name": "Set Connector Rule",

"active": true,

"criteria": [

{ "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/api" }

],

"behaviors": [

{ "type": "set_edge_connector", "attributes": { "value": "<connector_id>" } }

]

}

Error Responses (v3) → Custom Pages (v4)

Na API v3, Error Responses eram aninhados sob Applications. Na API v4, Custom Pages são recursos independentes vinculados a Workloads via Deployments.

Comparação de Endpoints

Operação	API v3	API v4
Listar todos	`GET /edge_applications/{app_id}/error_responses`	`GET /workspace/custom_pages`
Obter um	`GET /edge_applications/{app_id}/error_responses/{error_id}`	`GET /workspace/custom_pages/{page_id}`
Criar	`POST /edge_applications/{app_id}/error_responses`	`POST /workspace/custom_pages`
Atualizar	`PATCH /edge_applications/{app_id}/error_responses/{error_id}`	`PATCH /workspace/custom_pages/{page_id}`
Deletar	`DELETE /edge_applications/{app_id}/error_responses/{error_id}`	`DELETE /workspace/custom_pages/{page_id}`
Vincular à Application	Aninhado sob Application	Via Workload Deployment

Payload de Requisição

API v3 (Error Responses):

{

"name": "My Error Pages",

"errors": [

{

"code": 404,

"uri": "/errors/404.html",

"ttl": 300,

"custom_status_code": 404,

"origin_id": 123

},

{

"code": 500,

"uri": "/errors/500.html",

"ttl": 60,

"custom_status_code": 500,

"origin_id": 123

}

]

}

API v4 (Custom Pages):

{

"name": "My Error Pages",

"active": true,

"pages": [

{

"code": "404",

"page": {

"type": "page_connector",

"attributes": {

"connector": 456,

"ttl": 300,

"uri": "/errors/404.html",

"custom_status_code": 404

}

},

{

"code": "500",

"page": {

"type": "page_connector",

"attributes": {

"connector": 789,

"ttl": 60,

"uri": "/errors/500.html",

"custom_status_code": 500

}

]

}

Estrutura de Resposta

Resposta API v3:

{

"results": {

"id": 100,

"name": "My Error Pages",

"errors": [

{ "code": 404, "uri": "/errors/404.html", "ttl": 300, "origin_id": 123 }

]

}

Resposta API v4:

{

"state": "pending",

"data": {

"id": 200,

"name": "My Error Pages",

"active": true,

"last_editor": "user@example.com",

"last_modified": "2025-01-15T10:30:00Z",

"pages": [

{

"code": "404",

"page": {

"type": "page_connector",

"attributes": { "connector": 456, "ttl": 300, "uri": "/errors/404.html" }

}

]

}

Principais Diferenças Comportamentais

Aspecto	API v3	API v4
Escopo do recurso	Aninhado sob Application	Recurso independente de nível superior
Origin por código de erro	Único `origin_id` para todos os erros	ID de `connector` diferente por código de página
Vinculação	Automática (aninhado)	Via Workload Deployment com atributo `custom_page`
Campo code	`code` (inteiro)	`code` (string)
Definição de página	Estrutura plana no array `errors`	Objeto `page` aninhado com `type` e `attributes`

Comparação do Rules Engine

A estrutura do Rules Engine teve mudanças significativas no formato do payload e na nomenclatura de behaviors.

Comparação de Endpoints

Operação	API v3	API v4
Listar regras de request	`GET /edge_applications/{id}/rules_engine/request/rules`	`GET /edge_application/applications/{id}/request_rules`
Listar regras de response	`GET /edge_applications/{id}/rules_engine/response/rules`	`GET /edge_application/applications/{id}/response_rules`
Obter uma	`GET .../rules_engine/{phase}/rules/{rule_id}`	`GET .../{phase}_rules/{rule_id}`
Criar	`POST .../rules_engine/{phase}/rules`	`POST .../{phase}_rules`
Atualizar	`PATCH .../rules_engine/{phase}/rules/{rule_id}`	`PATCH .../{phase}_rules/{rule_id}`
Deletar	`DELETE .../rules_engine/{phase}/rules/{rule_id}`	`DELETE .../{phase}_rules/{rule_id}`

Comparação de Payload de Requisição

Rules Engine API v3:

{

"name": "My Rule",

"phase": "request",

"behaviors": [

{ "name": "set_origin", "target": "123" },

{ "name": "redirect_to_https", "target": true }

],

"criteria": [

[

{ "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/path" }

]

],

"order": 1,

"description": "Rule description"

}

Rules Engine API v4:

{

"name": "My Rule",

"active": true,

"behaviors": [

{ "type": "set_edge_connector", "attributes": { "value": "456" } },

{ "type": "redirect_https", "attributes": { "enabled": true } }

],

"criteria": [

{ "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/path" }

],

"description": "Rule description"

}

Principais Diferenças Comportamentais

Aspecto	API v3	API v4
Path do endpoint	`/rules_engine/{phase}/rules`	`/{phase}_rules`
Formato de behavior	`{ "name": "...", "target": "..." }`	`{ "type": "...", "attributes": { ... } }`
Formato de criteria	Arrays aninhados `[[{...}]]`	Array plano `[{...}]`
Argumento do criteria	`input_value`	`argument`
Behavior Set Origin	`set_origin`	`set_edge_connector`
Campo order	Campo `order` explícito	Ordenação implícita por criação

Comparação de Fluxo de Criação

Esta seção ilustra o fluxo passo a passo para configurar uma aplicação completa.

Fluxo de Criação API v3 (4 requisições)

Criar Application:

POST /edge_applications
{ "name": "My App", "delivery_protocol": "http,https" }
Criar Domain:

POST /domains
{ "name": "My Domain", "edge_application_id": <app_id> }
Criar Origin:

POST /edge_applications/<app_id>/origins
{ "name": "My Origin", "origin_type": "single_origin", "addresses": [...] }
Criar Regra para ativar Origin:

POST /edge_applications/<app_id>/rules_engine/request/rules
{ "behaviors": [{ "name": "set_origin", "target": <origin_id> }] }

Fluxo de Criação API v4 (5 requisições)

Criar Application:

POST /edge_application/applications
{ "name": "My App" }
Criar Workload:

POST /workspace/workloads
{ "name": "My Workload", "infrastructure": 1 }
Criar Workload Deployment:

POST /workspace/workloads/<workload_id>/deployments
{ "strategy": { "type": "default", "attributes": { "edge_application": <app_id> } } }
Criar Connector:

POST /edge_connector/connectors
{ "name": "My Connector", "type": "http", "attributes": {...} }
Criar Regra para ativar Connector:

POST /edge_application/applications/<app_id>/request_rules
{ "behaviors": [{ "type": "set_edge_connector", "attributes": { "value": <connector_id> } }] }

Implicações de Billing por Endpoint

Mudança de Endpoint	Impacto no Billing
Domains → Workloads	Requests e Data Transfer medidos por Workload em vez de por Application
Origins → Connectors	Load Balancer Data Transfer agora mede apenas tráfego edge-to-origin, não todo o tráfego da Application
Error Responses → Custom Pages	Sem impacto direto no billing; depende do uso do Connector
Rules Engine	Sem impacto direto no billing

Workloads

A Azion adotou o conceito de Workload para centralizar a lógica da aplicação, separando regras de negócio da infraestrutura. Isso permite reutilização e aplicação consistente de políticas entre ambientes, seguindo um modelo inspirado no Kubernetes.

Workloads substituem os Azion Domains. Todas as configurações anteriormente gerenciadas em Azion Domains agora estão organizadas sob Workloads.

Mudanças operacionais e impacto para o usuário

As seguintes configurações foram movidas de Azion Domains para Workloads.

Configuração	Local anterior	Novo local na v4
Environment Type	Domains	Workload > Infrastructure
Domain Settings	Domains	Workload > Domains
Applications	Domains > Settings	Workload > Deployment Settings
Firewall	Domains > Settings	Workload > Deployment Settings
CNAME (text input box)	Domains > Settings	Workload > Domains
Digital Certificate	Domains > Settings	Workload > Protocol Settings
CNAME Access Only	Domains > Settings	Workload > Domains
mTLS (Mutual TLS) Settings	Domains	Workload > Mutual Authentication Settings

Delivery Settings que antes eram configuradas dentro de uma Applications agora podem ser encontradas em Workloads em Protocol Settings:

Protocol Settings
Delivery Ports
Minimum TLS version
TLS Ciphers

Mudanças comportamentais notáveis

CNAME Access Only
- Comportamento anterior: Quando ativado, a aplicação só podia ser acessada via CNAME (por exemplo, app.example.com).
- Novo comportamento: Substituído por “Workload Domain Allow Access”, permitindo acesso pela URL gerada automaticamente do workload (por exemplo, xxxxxxxx.map.azionedge.net).

Uso da API

Cada Workload está implicitamente associado a um Deployment. O Deployment define a relação entre o Workload e a Applications (obrigatório), além de componentes opcionais como Firewall e Custom Pages.

Ao criar um Workload via API, você também deve criar um Workload Deployment para vincular o Workload a uma Applications. Essa associação garante que o Workload esteja corretamente vinculado à Applications desejada.

Ao utilizar o Console, essa associação é criada automaticamente ao selecionar Deployment Settings.

Exemplos de requisições

Criando um Workload:

curl --request POST --url https://api.azion.com/v4/workspace/workloads --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "Example Workload",

"active": true,

"infrastructure": 1,

"protocols": {

"http": {

"versions": [

"http1",

"http2"

]

}

},

"workload_domain_allow_access": true

}

Criando um Workload Deployment:

curl --request POST --url https://api.azion.com/v4/workspace/workloads/<workload_id>/deployments --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "Workload Deployment Example",

"current": true,

"active": true,

"strategy": {

"type": "default",

"attributes": {

"edge_application": <edge_application_id>

}

Para mais informações sobre os parâmetros da API, visite a referência da API de Workloads.

O que acontece com meus Domains existentes?

Os Domains serão automaticamente convertidos em Workloads em fases, garantindo compatibilidade com as configurações originais. A migração ocorrerá em ondas.

Após a migração da sua conta, não será mais possível criar novos Domains.

Ação necessária

Se você possui automações que atualmente utilizam os endpoints da API de Domains, é necessário atualizá-las para utilizar os endpoints de Workloads da v4.

Novas funcionalidades

Custom Pages: Substitui e expande o antigo recurso de Error Responses. Mais detalhes são fornecidos abaixo.
Azion Custom Domain: Permite configurar um domínio personalizado da Azion para sua aplicação no formato example.azion.app.

Benefícios da migração

Organização aprimorada: Agrupe logicamente todos os recursos relacionados a uma aplicação ou serviço em uma única unidade (Workload), tornando o gerenciamento, visualização e navegação mais eficientes. Essa estrutura cria relações claras entre os componentes.
Escalabilidade e flexibilidade: Simplifica o deploy, atualizações e escalabilidade de aplicações complexas ao permitir que todos os componentes necessários sejam gerenciados como parte de um Workload.
Gestão simplificada: Centraliza a configuração e o controle de diferentes elementos da aplicação, reduzindo a complexidade operacional.
Base para novas capacidades: Essencial para recursos futuros, como versionamento de configuração e conexões de serviço mais intuitivas, por exemplo, vincular um domínio diretamente ao Object Storage sem depender de uma Applications.

Acesse a Referência de Workloads

Connectors

O Connectors centraliza as configurações de conexão com backends, permitindo reutilizá-las em múltiplas aplicações e fornecendo controle granular sobre desempenho, segurança e roteamento por meio de uma interface unificada para conectar Applications a uma origem (seu backend), incorporando nativamente recursos como balanceamento de carga, autenticação HMAC e Origin Shield.

O Connectors substitui as configurações de Origin das Applications. Todas as configurações anteriormente gerenciadas na aba Origins das Applications agora estão organizadas sob o Connectors.

Mudanças operacionais e impacto para o usuário

Todas as configurações anteriormente gerenciadas na aba Origins das Applications agora estão organizadas sob o Connectors.

Configuração	Local anterior	Novo local na v4
Type	Applications > Origins > Host Settings	Connector Type
Protocol Policy	Applications > Origins > Host Settings	Connector Options > Transport Protocol Policy
Host Header	Applications > Origins > Host Settings	Connector Options > Host
Address	Applications > Origins > Host Settings	Connector Options > Address Management > Address
Path	Applications > Origins > Host Settings	Connector Options > Path
HMAC Authentication	Applications > Origins > Host Settings	HMAC
Connection Timeout	Applications > Origins > Host Settings > Timeouts	Load Balancer Configuration > Connection Timeout
Between Bytes Timeout	Applications > Origins > Host Settings > Timeouts	Load Balancer Configuration > Read/Write Timeout

Mudanças comportamentais notáveis

Connector Type
- Comportamento anterior: As opções incluíam Single Origin e Load Balancer. Isso definia se era possível configurar uma ou múltiplas origens.
- Novo comportamento: Os tipos Single Origin e Load Balancer foram unificados no tipo HTTP. Ao usar múltiplas origens, é necessário habilitar o Load Balancer Module para adicionar mais origens.
HMAC Authentication
- Comportamento anterior: Disponível ao configurar uma Origin.
- Novo comportamento: Agora é necessário habilitar o Origin Shield Module ao configurar um connector do tipo HTTP.
Timeouts
- Comportamento anterior: Connection Timeout e Between Bytes Timeout tinham valores fixos.
- Novo comportamento: Agora é possível configurar os valores de Connection Timeout e Read/Write Timeout na seção de Load Balancer Configuration do connectors.

Uso da API

Você pode gerenciar Connectors e suas configurações pela API utilizando os endpoints v4 disponíveis. Consulte a referência da API para detalhes sobre operações e parâmetros suportados.

Exemplos de requisições

Criando um connector com o tipo Object Storage:

curl --request POST --url https://api.azion.com/v4/edge_connector/connectors --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "object storage connector",

"active": true,

"type": "edge_storage",

"attributes": {

"bucket": "app-origin",

"prefix": "/"

}

Criando um connector com o tipo HTTP:

curl --request POST --url https://api.azion.com/v4/edge_connector/connectors --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "example.com",

"active": true,

"type": "http",

"attributes": {

"addresses": [

{

"active": true,

"address": "example.com",

"http_port": 80,

"https_port": 443,

"modules": null

}

],

"connection_options": {

"dns_resolution": "preserve",

"transport_policy": "preserve",

"http_version_policy": "http1_1",

"host": "example.com",

"path_prefix": "/",

"following_redirect": true,

"real_ip_header": "X-Real-IP",

"real_port_header": "X-Real-PORT"

},

"modules": {

"load_balancer": {

"enabled": false,

"config": null

},

"origin_shield": {

"enabled": false,

"config": null

}

Para mais informações sobre os parâmetros da API, visite a referência da API de Connectors.

O que acontece com meus Origins existentes?

As Origins existentes serão migradas de acordo com um cronograma, que será comunicado para cada caso. A migração ocorrerá em fases.

Ação necessária

Se você possui automações que atualmente utilizam os endpoints da API de Applications - Origins, é necessário atualizá-las para utilizar os endpoints da v4.

Novas funcionalidades

Reutilização de configuração: O mesmo Connectors pode ser conectado a múltiplas Applications.
Timeouts configuráveis: Os valores de Connection Timeout e Read/Write Timeout podem ser configurados na seção de Load Balancer Configuration do Connectors.

Benefícios da migração

Gestão simplificada de backend: O Connectors centraliza todas as definições de conexão de backend, reduzindo a complexidade de configuração. Múltiplas Applications podem usar um único Connectors, facilitando a manutenção e garantindo consistência de configuração.
Arquitetura pronta para o futuro: O Connectors fornece a base para novos recursos e otimizações da Azion Web Platform, garantindo que suas Applications estejam prontas para aproveitar novas capacidades assim que estiverem disponíveis.

Acesse a Referência de Connectors

Custom Pages

O Custom Pages é um recurso da Azion que permite personalizar páginas de erro para os usuários com base no código de status recebido de um Connectors ao buscar o conteúdo da sua origem.

O Custom Pages substitui as configurações de Error Responses das Applications. Todas as configurações anteriormente gerenciadas na aba Error Responses das Applications agora estão organizadas sob Custom Pages.

Mudanças operacionais e impacto para o usuário

Todas as configurações anteriormente gerenciadas na aba Error Responses das Applications agora estão organizadas sob Custom Pages.

Configuração	Local anterior	Novo local na v4
Default Error Response	Applications > Error Responses	Custom Pages > Page Codes
Custom Error Response	Applications > Error Responses	Custom Pages
Status Code	Applications > Error Responses > Custom Error	Custom Pages > Status Configuration > Page Code
Page Path	Applications > Error Responses > Custom Error	Custom Pages > Response Details > Page Path (URI)
Default Response TTL	Applications > Error Responses > Custom Error	Custom Pages > Response Details > Response TTL
Set Origin	Applications > Error Responses > Set Origin	Custom Pages > Response Details > Page Path (URI)

Mudanças comportamentais notáveis

Relacionamento
- Comportamento anterior: As páginas de erro faziam parte de uma Applications.
- Novo comportamento: Custom Pages são recursos separados e são vinculados a um Workload.
Connectors por código de página
- Comportamento anterior: Todas as respostas de erro precisavam ter a mesma Origin.
- Novo comportamento: Agora é possível atribuir um Connectors específico para cada código de página de erro em Custom Pages. Isso permite personalizar a resposta para cada código de erro individualmente.

Uso da API

Você pode gerenciar Custom Pages e suas configurações pela API utilizando os endpoints v4 disponíveis. Consulte a referência da API para detalhes sobre operações e parâmetros suportados.

Para utilizar uma Custom Page, é necessário vinculá-la a um Workload usando o endpoint de Workload Deployment. Ao utilizar o Console, essa associação é criada na configuração de deployment do Workload.

Exemplos de requisições

Criando uma Custom Page:

curl --request POST --url https://api.azion.com/v4/workspace/custom_pages --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "401 error page",

"active": true,

"pages": [

{

"code": "401",

"page": {

"type": "page_connector",

"attributes": {

"connector": <edge_connector_id>,

"ttl": 300,

"uri": "/path/error_page.html",

"custom_status_code": 100

}

]

}

Vinculando uma Custom Page a um Workload Deployment:

curl --request POST --url https://api.azion.com/v4/workspace/workloads/<workload_id>/deployments --header 'Accept: application/json' --header 'Authorization: Token [TOKEN VALUE]' --header 'Content-Type: application/json' -- {

"name": "Workload Deployment Example",

"current": true,

"active": true,

"strategy": {

"type": "default",

"attributes": {

"edge_application": <edge_application_id>,

"custom_page": <custom_page_id>

}

Para mais informações sobre os parâmetros da API, visite a referência da API de Custom Pages.

O que acontece com meus Error Responses existentes?

Os Error Responses existentes serão automaticamente convertidos em Custom Pages em fases, mantendo a compatibilidade com as configurações originais. A migração ocorrerá em ondas.

Novas funcionalidades

Detalhes da resposta: Personalize a resposta para cada código de status. Especifique o URI, código de status, TTL a ser retornado ao cliente.
Atribuição de Connectors por código de status: Atribua um connector específico para cada código de página de erro em Custom Pages. Isso permite personalizar a resposta para cada código de erro individualmente.

Benefícios da migração

Opções de configuração abrangentes:
- Defina um código de status personalizado para cada página.
- Configure o tempo de vida (TTL) da resposta.
- Especifique o caminho para a página personalizada.
- Vincule cada página personalizada a um ou mais connectors.
Ativação e gerenciamento:
- Ative ou desative qualquer Custom Page usando um controle de status.
- Visualize e gerencie uma lista paginada de todos os códigos de status configurados pela interface do usuário.

Acesse a Referência de Custom Pages

Cronograma planejado de migração

O processo de migração ocorrerá nos próximos seis meses.

Recomendações

Aqui estão ações recomendadas para garantir uma migração tranquila:

Acompanhe as comunicações da Azion: Mantenha-se informado sobre datas de migração, guias e quaisquer ferramentas fornecidas para a transição.
Planeje sua migração: Avalie como suas configurações atuais se encaixarão na nova estrutura e planeje estrategicamente a migração dos seus recursos.
Prepare sua equipe: Garanta que sua equipe compreenda o conceito de Workloads e seu impacto no desenvolvimento e deploy de aplicações na Azion Web Platform.
Teste as novas funcionalidades: À medida que os novos recursos forem implementados, teste as novas capacidades para otimizar suas aplicações e serviços.

Perguntas e Respostas

Como posso testar as novas funcionalidades?

Novas contas Developer terão acesso aos recursos atualizados. Para avaliar essas funcionalidades, você pode criar uma conta pessoal que não esteja associada à conta da sua organização. Isso permite testar as novas funcionalidades de forma independente.

Preciso fazer alguma coisa?

A maioria dos usuários não precisará tomar nenhuma ação, pois o processo de migração é automático e preserva as configurações existentes. No entanto, se você utiliza automações personalizadas, scripts ou pipelines de CI/CD que interagem com os endpoints antigos da API, será necessário atualizá-los para utilizar os novos endpoints da v4. Revise suas integrações para garantir a compatibilidade após a migração.

O que devo fazer se precisar de assistência?

Você pode entrar em contato com nossa equipe de suporte ou perguntar diretamente ao Azion Copilot.