As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # HTTP A ação HTTPS (`http`) envia dados de uma mensagem MQTT para um endpoint HTTPS, que pode apontar para um aplicativo ou serviço web. ## Requisitos Esta ação de regra tem os seguintes requisitos: + Você deve confirmar e ativar os endpoints HTTPS antes que o mecanismo de regras possa usá-los. Para obter mais informações, consulte [Destinos de ação HTTP](http-action-destination.md). ## Parâmetros Ao criar uma AWS IoT regra com essa ação, você deve especificar as seguintes informações: `url` O endpoint HTTPS para o qual a mensagem é enviada usando o método HTTP POST. Se você usar um endereço IP no lugar de um nome de host, ele deverá ser um IPv4 endereço. IPv6 endereços não são suportados. Compatível com [modelos de substituição](iot-substitution-templates.md): Sim `confirmationUrl` (Opcional) Se especificado, AWS IoT usa o URL de confirmação para criar um destino de regra de tópico correspondente. Você deve habilitar o destino da ação HTTP antes de usá-la em uma ação HTTP. Para obter mais informações, consulte [Destinos de ação HTTP](http-action-destination.md). Se você usar modelos de substituição, deverá criar manualmente um destino de ação HTTP antes que a `http` ação possa ser usada. `confirmationUrl`deve ser um prefixo de. `url` A relação entre `url` e `confirmationUrl` é descrita pelo seguinte: + Se `url` estiver codificado e não `confirmationUrl` for fornecido, tratamos implicitamente o `url` campo como o. `confirmationUrl` AWS IoT cria um destino de regra de tópico para`url`. + Se `url` e `confirmationUrl` estiverem codificados, `url` deve começar com. `confirmationUrl` AWS IoT cria um destino de regra de tópico para`confirmationUrl`. + Se `url` contiver um modelo de substituição, você deverá especificar `confirmationUrl` e `url` deverá começar com `confirmationUrl`. Se `confirmationUrl` contiver modelos de substituição, você deverá criar manualmente um destino de ação HTTP antes que a `http` ação possa ser usada. Se `confirmationUrl` não contiver modelos de substituição, AWS IoT cria um destino de regra de tópico para`confirmationUrl`. Compatível com [modelos de substituição](iot-substitution-templates.md): Sim `headers` (Opcional) A lista de cabeçalhos a serem incluídos nas solicitações HTTP para o endpoint. Cada cabeçalho deve conter as seguintes informações: `key` A chave do cabeçalho. Compatível com [modelos de substituição](iot-substitution-templates.md): Não `value` O valor do cabeçalho. Compatível com [modelos de substituição](iot-substitution-templates.md): Sim O tipo de conteúdo padrão é application/json quando a carga está no formato JSON. Caso contrário, é application/octet-stream. Você pode substituí-lo especificando o tipo de conteúdo exato no cabeçalho com o tipo de conteúdo da chave (sem distinção entre maiúsculas e minúsculas). `auth` (Opcional) A autenticação usada pelo mecanismo de regras para se conectar ao URL do endpoint especificado no argumento `url`. Atualmente, o Signature versão 4 é o único tipo de autenticação suportado. Para obter mais informações, consulte [Autorização HTTP](https://docs.aws.amazon.com/iot/latest/apireference/API_HttpAuthorization.html). Compatível com [modelos de substituição](iot-substitution-templates.md): Não `enableBatching` (Opcional) Se as mensagens de ação HTTP devem ser processadas em uma única solicitação para um determinado URL. O valor pode ser verdadeiro ou falso. Para obter mais informações sobre agrupamento em lotes, consulte Mensagens de [ação HTTP em lotes](http_batching.md). Valor booleano Compatível com [modelos de substituição](iot-substitution-templates.md): Não `batchConfig` (Opcional) Configurações para agrupamento em lotes. Depois de ativados, `batchConfig` os parâmetros devem ser especificados. Se `batchConfig` os parâmetros não forem especificados, os valores padrão serão usados. `maxBatchOpenMs` O tempo máximo (em milissegundos) que uma mensagem de saída espera por outras mensagens para criar o lote. Quanto maior a configuração, maior a latência da ação HTTP em lote. Valor mínimo: 5 ms. Valor máximo: 200 ms. Valor padrão: 20 ms Compatível com [modelos de substituição](iot-substitution-templates.md): Não `maxBatchSize` O número máximo de mensagens que são agrupadas em lotes em uma única execução de ação. Compatível com [modelos de substituição](iot-substitution-templates.md): Não Valor mínimo: 2 mensagens. Valor máximo: 10 mensagens Valor padrão: 10 mensagens `maxBatchSizeBytes` Tamanho máximo de um lote de mensagens, em bytes. Valor mínimo: 100 bytes. Valor máximo: 131.072 bytes Valor padrão: 5.120 bytes Compatível com [modelos de substituição](iot-substitution-templates.md): Não O tipo de conteúdo padrão é application/json quando a carga está no formato JSON. Caso contrário, é application/octet-stream. Você pode substituí-lo especificando o tipo de conteúdo exato no cabeçalho com o tipo de conteúdo da chave (sem distinção entre maiúsculas e minúsculas). ## Exemplos O exemplo de JSON a seguir define uma AWS IoT regra com uma ação HTTP. ``` { "topicRulePayload": { "sql": "SELECT * FROM 'some/topic'", "ruleDisabled": false, "awsIotSqlVersion": "2016-03-23", "actions": [ { "http": { "url": "https://www.example.com/subpath", "confirmationUrl": "https://www.example.com", "headers": [ { "key": "static_header_key", "value": "static_header_value" }, { "key": "substitutable_header_key", "value": "${value_from_payload}" } ] } } ] } } ``` ``` "http": { "url": "https://www.example.com/subpath", "confirmationUrl": "https://www.example.com", "headers": [ { "key": "Content-Type", "value": "application/json" } ], "enableBatching": true, "batchConfig": { "maxBatchOpenMs": 123, "maxBatchSize": 5, "maxBatchSizeBytes": 131072, } }, "errorAction": { "http": { "url": "https://www.example.com/subpath", "confirmationUrl": "https://www.example.com" // batchConfig is not allowed here } } ``` ## Lógica de repetição da ação HTTP O mecanismo de AWS IoT regras tenta novamente a ação HTTP de acordo com estas regras: + O mecanismo de regras tenta enviar uma mensagem pelo menos uma vez. + O mecanismo de regras tenta novamente no máximo duas vezes. O número máximo de tentativas é três. + O mecanismo de regras não fará uma nova tentativa se: + A tentativa anterior tiver fornecido uma resposta maior do que 16.384 bytes. + O serviço ou aplicativo web downstream fechar a conexão TCP após a tentativa. + O tempo total para concluir uma solicitação com repetições tiver excedido o limite de tempo limite da solicitação. + A solicitação retorna um código de status HTTP diferente de 429, 500–599. **nota** [Custos padrão de transferência de dados](https://aws.amazon.com/ec2/pricing/on-demand/) se aplicam a novas tentativas. ## Consulte também + [Agrupar mensagens de ação HTTP em lote](http_batching.md) + [Destinos de ação HTTP](http-action-destination.md) + [Encaminhe dados diretamente AWS IoT Core para seus serviços da Web](https://aws.amazon.com/blogs/iot/route-data-directly-from-iot-core-to-your-web-services/) na *Internet das Coisas no AWS* blog # Agrupar mensagens de ação HTTP em lote Você pode usar o agrupamento em lotes para enviar várias mensagens de ação HTTP em uma única solicitação. ## Visão geral do O agrupamento em lotes permite que você envie mensagens do AWS IoT Core Rules Engine para seus endpoints HTTP em lotes. Essa funcionalidade pode ajudar a reduzir seus custos diminuindo o número de execuções de ações HTTP, bem como melhorar a eficiência ao reduzir a sobrecarga associada ao estabelecimento de novas conexões. **nota** A ação HTTP em lote é medida como uma única ação. Você é medido em incrementos de 5 KiB, com base no tamanho da carga útil em lote de saída emitida pelo Mecanismo de AWS IoT Core Regras para o serviço downstream. Para obter mais informações, consulte a [página de definição de preços do AWS IoT Core](https://aws.amazon.com/iot-core/pricing/). Quando você ativa o agrupamento em lotes na definição de sua Ação de Regra de IoT, os seguintes parâmetros estarão disponíveis para configuração: `maxBatchOpenMs` O tempo máximo (em milissegundos) que uma mensagem de saída espera por outras mensagens para criar o lote. Quanto maior a configuração, maior a latência da ação HTTP em lote. Valor mínimo: 5 ms. Valor máximo: 200 ms. Valor padrão: 20 ms Compatível com [modelos de substituição](iot-substitution-templates.md): Não `maxBatchSize` O número máximo de mensagens que são agrupadas em lotes em uma única execução de ação de regra de IoT. Valor mínimo: 2 mensagens. Valor máximo: 10 mensagens Valor padrão: 10 mensagens Compatível com [modelos de substituição](iot-substitution-templates.md): Não `maxBatchSizeBytes` Tamanho máximo de um lote de mensagens, em bytes. Valor mínimo: 100 bytes. Valor máximo: 131.072 bytes Valor padrão: 5120 bytes Compatível com [modelos de substituição](iot-substitution-templates.md): Não **Importante** Quando você especifica vários parâmetros de lote, o lote é concluído quando o primeiro limite é atingido. Por exemplo, se você especificar 100 ms como o Tempo Máximo de Abertura do Lote e 5 KiB como o Tamanho Máximo do Lote, e o Rules Engine agrupar somente 2 KiB em 100 ms, um lote de 2 KiB será criado e enviado. ## Usando cabeçalhos HTTP em um lote Quando você usa cabeçalhos em sua ação HTTP, a solicitação em lote usa o valor do cabeçalho da última mensagem que foi adicionada ao lote (não necessariamente a última mensagem que você publicou). Recomendamos usar valores de cabeçalho que sejam: + Idêntico em todas as mensagens do lote + Aplicável a todas as mensagens (por exemplo, credenciais de autenticação) Os cabeçalhos são enviados com a solicitação HTTP e não fazem parte do corpo da mensagem. **nota** Quando o agrupamento em lotes está ativado: A solicitação em lote inclui automaticamente o `Content-Type: application/json` cabeçalho, pois o lote é enviado como uma matriz JSON. Não podemos garantir que a última mensagem do lote seja a última mensagem que você publicou. É a última mensagem que entrou no lote. ## Exemplo de carga O exemplo a seguir mostra a estrutura de uma carga de mensagens em lote enviada ao seu endpoint HTTP: ``` [ { "user_id": "user1", "steps_today": 1000 }, { "user_id": "user2", "steps_today": 21000 }, { "user_id": "user8", "steps_today": 1500 }, ... ] ``` ## Limitações A seguir estão as limitações do agrupamento em lotes: + AWS IoT Core não garante a ordem geral das mensagens. O agrupamento em lotes é realizado localmente em cada host, o que pode fazer com que as mensagens dentro de um lote sejam processadas em uma ordem diferente da que foram recebidas. + AWS IoT Core não fornece suporte ao processamento de mensagens no lado do receptor. Você é responsável por garantir que seu serviço downstream esteja configurado para aceitar e processar dados em lotes. + O agrupamento em lotes entre contas não é suportado, mesmo que as mensagens sejam destinadas ao mesmo identificador de recurso (URL HTTP ou ARN do recurso). + AWS IoT Core não garante que o tamanho do lote atenda à configuração especificada. Os lotes podem ser menores do que os limites configurados com base no tempo e no fluxo de mensagens. + Quando o agrupamento em lotes está ativado, cargas binárias (dados não UTF-8) não são suportadas. Somente cargas de texto UTF-8 (como JSON) são aceitas. Para enviar dados binários, codifice-os em base64 antes de enviá-los para a ação HTTP e, em seguida, decodifique-os no ponto final de recebimento. Por exemplo, você pode usar a [função de codificação](iot-sql-functions.html#iot-function-encode) nas regras de IoT para codificar a carga binária. Como alternativa, você pode codificar a carga binária em seu dispositivo de IoT e publicá-la no. AWS IoT Core ## Ações de erro para agrupamento em lotes Você não poderá definir uma lógica de lote separada em sua definição de Ação de Erro. No entanto, sua ação de erro suportará o agrupamento em lotes se você tiver definido a lógica de lote em sua ação principal. Quando uma solicitação em lote falha, o mecanismo de AWS IoT Core regras segue a [lógica de repetição da ação HTTP](https-rule-action.md#https-rule-action-retry-logic). Após a última tentativa de repetição, uma ação de erro será invocada para todo o lote com falha. Veja a seguir um exemplo de uma mensagem de ação de erro com o agrupamento em lotes ativado: ``` { "ruleName": "FailedTopicRule", "topic": "topic/rulesengine", "payloadsWithMetadata": [ { "id": 1, "cloudwatchTraceId": "bebd6d93-6d4a-899e-9e40-56e82252d2be", "clientId": "Test", "sourceIp": "10.0.0.0", "base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0=" }, { "id": 2, "cloudwatchTraceId": "af94d3b8-0b18-1dbf-2c7d-513f5cb9e2e1", "clientId": "Test", "sourceIp": "10.0.0.0", "base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0=" }, { "id": 3, "cloudwatchTraceId": "ca441266-c2ce-c916-6aee-b9e5c7831675", "clientId": "Test", "sourceIp": "10.0.0.0", "base64OriginalPayload": "eyJ1c2VyX2lkIjogInVzZXI1NjQ3IiwgInN0ZXBzX3RvZGF5IjogMTMzNjUsICJ0aW1lc3RhbXAiOiAiMjAyNS0xMC0wOVQwNzoyMjo1OC45ODQ3OTAxNzZaIn0=" } ], "failures": [ { "affectedIds": [ 1, 2, 3 ], "failedAction": "HttpAction", "failedResource": "https://example.foobar.com/HttpAction", "errorMessage": "HttpAction failed to make a request to the specified endpoint. StatusCode: 500. Reason: Internal Server Error." }, { "affectedIds": [ 3 ], "failedAction": "S3Action", "failedResource": "amzn-s3-demo-bucket", "errorMessage": "Failed to put S3 object. The error received was The specified bucket does not exist" }, { "affectedIds": [ 3 ], "failedAction": "LambdaAction", "failedResource": "arn:aws:lambda:us-west-2:123456789012:function:dummy", "errorMessage": "Failed to invoke lambda function. Received Server error from Lambda. The error code is 403" } ] } ``` **nota** Falhas de ação em lote também geram cargas de ação de erro maiores, o que pode aumentar a probabilidade de falhas de ação de erro devido ao tamanho. Você pode monitorar falhas na ação de erro usando a `ErrorActionFailure` métrica. Consulte [Métricas de ação da regra](metrics_dimensions.md#rule-action-metrics) para obter mais informações. ## Envio de mensagens de ação HTTP em lote com o AWS CLI ### Criação ou atualização de uma ação de regra com o agrupamento em lotes 1. Use o AWS CLI comando apropriado para criar ou atualizar uma regra: + Para criar uma nova regra, use o [create-topic-rule](https://docs.aws.amazon.com/cli/latest/reference/iot/create-topic-rule.html)comando: ``` aws iot create-topic-rule --rule-name myrule --topic-rule-payload file://myrule.json ``` + Para atualizar uma regra existente, use o [replace-topic-rule](https://docs.aws.amazon.com/cli/latest/reference/iot/replace-topic-rule.html)comando: ``` aws iot replace-topic-rule --rule-name myrule --topic-rule-payload file://myrule.json ``` 1. Ative os recursos de agrupamento em lotes definindo o parâmetro enableBatching como verdadeiro na carga útil da regra de tópico: ``` { "topicRulePayload": { "sql": "SELECT * FROM 'some/topic'", "ruleDisabled": false, "awsIotSqlVersion": "2016-03-23", "actions": [ { "http": { "url": "https://www.example.com/subpath", "confirmationUrl": "https://www.example.com", "headers": [ { "key": "static_header_key", "value": "static_header_value" }, { "key": "substitutable_header_key", "value": "${value_from_payload}" } ], "enableBatching": true, "batchConfig": { "maxBatchOpenMs": 100, "maxBatchSize": 5, "maxBatchSizeBytes": 1024 } } } ] } ``` 1. Configure os parâmetros de agrupamento em lotes. Você não precisa especificar todos os parâmetros do lote. Você pode optar por especificar 1, 2 ou todos os 3 parâmetros de lote. Se você não especificar um parâmetro de lote, o Mecanismo de Regras atualizará esse parâmetro com os valores padrão. Para obter mais informações sobre parâmetros de lote e seus valores padrão, consulte [Parâmetros HTTP](https-rule-action.md#https-rule-action-parameters). # Destinos de ação HTTP Um destino de ação HTTP é um serviço da Web para o qual o mecanismo de regras pode rotear dados de uma regra de tópico. Um AWS IoT Core recurso descreve o serviço web para AWS IoT. Os recursos de destino podem ser compartilhados por regras diferentes. Antes de AWS IoT Core poder enviar dados para outro serviço da Web, ele deve confirmar que pode acessar o endpoint do serviço. ## Visão geral do Um destino de ação HTTP se refere a um serviço da Web que oferece suporte a uma URL de confirmação e a uma ou mais coletas de dados URLs. O recurso de destino contém o URL de confirmação do seu serviço web. Ao configurar uma ação HTTP, você especifica a URL real do endpoint que deve receber os dados junto com a URL de confirmação do serviço web. Após a confirmação do destino, a regra do tópico envia o resultado da instrução SQL para o endpoint HTTPS (e não para a URL de confirmação). O destino de uma ação HTTP pode estar em um dos seguintes estados: ENABLED O destino foi confirmado e pode ser usado por uma ação de regra. Um destino deve estar no estado `ENABLED` para que seja usado em uma regra. Você só pode habilitar destinos com status DISABLED. DISABLED O destino foi confirmado mas não pode ser usado por uma ação de regra. Isso é útil se você quiser impedir temporariamente o tráfego para seu endpoint sem precisar passar pelo processo de confirmação novamente. Você só pode desabilitar destinos com status ENABLED. IN\$1PROGRESS A confirmação do destino está em andamento. ERRO A confirmação do destino expirou. Depois que um destino de ação HTTP for confirmado e ativado, ele poderá ser usado com qualquer regra em sua conta. ## Gerenciando destinos de ações HTTP Você pode usar as operações a seguir para gerenciar seus destinos de ação HTTP. ### Criação de destinos de ação HTTP Você cria um destino de ação HTTP chamando a `CreateTopicRuleDestination` operação ou usando o AWS IoT console. Depois de criar um destino, AWS IoT envia uma solicitação de confirmação para o URL de confirmação. A solicitação de confirmação tem o seguinte formato: ``` HTTP POST {confirmationUrl}/?confirmationToken={confirmationToken} Headers: x-amz-rules-engine-message-type: DestinationConfirmation x-amz-rules-engine-destination-arn:"arn:aws:iot:us-east-1:123456789012:ruledestination/http/7a280e37-b9c6-47a2-a751-0703693f46e4" Content-Type: application/json Body: { "arn":"arn:aws:iot:us-east-1:123456789012:ruledestination/http/7a280e37-b9c6-47a2-a751-0703693f46e4", "confirmationToken": "AYADeMXLrPrNY2wqJAKsFNn-…NBJndA", "enableUrl": "https://iot.us-east-1.amazonaws.com/confirmdestination/AYADeMXLrPrNY2wqJAKsFNn-…NBJndA", "messageType": "DestinationConfirmation" } ``` O conteúdo do pedido de confirmação inclui as seguintes informações: arn O Amazon Resource Name (ARN) do destino da ação HTTP a ser confirmado. confirmationToken O token de confirmação enviado por AWS IoT Core. O token no exemplo é truncado. Seu token será mais longo. Você precisará desse token para confirmar seu destino em AWS IoT Core. enableUrl O URL para o qual você navega para confirmar um destino de regra de tópico. messageType O tipo de mensagem. ### Confirmando destinos de ações HTTP Para concluir o processo de confirmação do endpoint, se você estiver usando a AWS CLI, deverá realizar as seguintes etapas após o URL de confirmação receber a solicitação de confirmação. 1. **Confirme se o destino está pronto para receber mensagens** Para confirmar se o destino da ação HTTP está pronto para receber mensagens de IoT, chame o `enableUrl` na solicitação de confirmação ou execute a operação da `ConfirmTopicRuleDestination` API e transmita a `confirmationToken` partir da solicitação de confirmação. 1. **Defina o status da regra de tópico como ativado** Depois de confirmar que o destino pode receber mensagens, você deve realizar a operação de API `UpdateTopicRuleDestination` para definir o status da regra de tópico como `ENABLED`. Se você estiver usando o AWS IoT console, `confirmationToken` copie e cole na caixa de diálogo de confirmação do destino no AWS IoT console. Em seguida, você pode ativar a regra do tópico. ### Enviando uma nova solicitação de confirmação Para acionar uma nova mensagem de confirmação para um destino, faça uma chamada para `UpdateTopicRuleDestination` e defina o status do destino da regra de tópico como `IN_PROGRESS`. Repita o processo de confirmação depois de enviar uma nova solicitação de confirmação. ### Desabilitando e excluindo um destino de ação HTTP Para desativar um destino, chame `UpdateTopicRuleDestination` e defina o status do destino da regra de tópico como `DISABLED`. Uma regra de tópico no estado DISABLED pode ser ativada novamente sem a necessidade de enviar uma nova solicitação de confirmação. Para excluir um destino de ação HTTP, chame`DeleteTopicRuleDestination`. ## Support da Autoridade Certificadora **nota** Não há suporte para certificados autoassinados. Os endpoints HTTPS em um destino de ação HTTP oferecem suporte a certificados emitidos pela [Autoridade de Certificação AWS Privada](https://www.amazontrust.com/repository/) e pela [Lets Encrypt](https://letsencrypt.org/certificates/).