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.

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.

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.

Connectors e Load Balancer

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

• 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:

• 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

Origin Shield

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

• 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.

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

Mapeamento de Recursos

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

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

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

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

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

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

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

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

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)

1. Criar Application:

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

2. Criar Domain:

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

3. Criar Origin:

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

4. 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)

1. Criar Application:

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

2. Criar Workload:

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

3. Criar Workload Deployment:

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

4. Criar Connector:

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

5. 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

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.

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>
  }
}
}'

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.

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.

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
      }
    }
  }
}'

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.

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.

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>
  }
}
}'

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.

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.