Serviços conectados

Desenhe APIs e integrações fiáveis com contratos claros, controlo de acesso e gestão de falhas.

52 artigos · Último artigo atualizado

A pesquisa abrange todos os artigos desta secção, incluindo o arquivo e o texto dos artigos.

Compreenda o tópico

Um guia prático para este tópico

Um recurso conectado depende de identidades, contratos de interface, fornecedores e modos de falha. Esta categoria conecta design de API, segurança, continuidade e a qualidade do serviço que os usuários recebem.

O que examinar
  • Identifique as chamadas essenciais para cada jornada e seus responsáveis.
  • Planeje prazos, erros, novas tentativas seguras e degradação visível.
  • Simule interrupções, recuperação e resposta a incidentes.
  • Compare as respostas reais com o contrato documentado antes de alterar uma interface.
  • Teste os direitos em cada objeto e campo GraphQL e, em seguida, vincule aninhamento, listas e aliases pelo custo real.
  • Transformar uma notificação recebida em um efeito comercial único e rastreável, recuperável após uma falha.
  • Separe caches compartilhados, privados e de aplicativos, inspecione chaves, revalidação e invalidação após alterações de direitos de acesso.
  • Importar um URL pode permitir acesso involuntário a recursos internos.
  • Os limites afetam capacidade, novas tentativas e distribuição entre clientes.
  • Definir o que se lê, quando continuar e como comprovar a cobertura.
  • Os ficheiros recebidos precisam de verificação antes de publicação ou processamento.
  • Um cache partilhado separa conteúdo público e respostas pessoais.
  • Um pedido aceite não demonstra que o trabalho terminou.
  • Distinguir eventos produzidos, recebidos e utilizáveis sem interpretar silêncio como ausência de incidentes.
  • Definir um contrato de mensagens de iframe ou popup que rejeite emissores e dados inesperados.
  • Validar caminhos, ligações e dados expandidos antes de promover os ficheiros extraídos.
  • Seguir a renovação até às terminações e clientes antes de concluir a alteração.
Perguntas úteis
  • O que acontece se um provedor parar de responder?
  • Uma nova tentativa pode repetir uma ação?
  • Quais evidências mostram que a recuperação funciona?
  • Quais clientes existentes seriam afetados por uma nova versão?
  • Um resolvedor pode retornar um campo privado depois que seu pai foi permitido?
  • Quais bytes são assinados?
  • A ausência de cache significa que nada é retido?
  • Verificar apenas o primeiro URL chega?
  • 429 prova que uma escrita anterior não aconteceu?
  • Uma página vazia termina a exportação?
  • Uma extensão permitida prova que o ficheiro é seguro?
  • Um cookie impede cache partilhada?
  • 202 prova que o trabalho terminará?
  • Três linhas recebidas provam três eventos guardados?
  • Basta verificar event.origin?
  • Um arquivo pequeno ou filtro garante segurança?
  • A renovação ACME bem-sucedida basta?

Exemplo ilustrativo de decisão

Situação
Exemplo fictício: estes dados não descrevem clientes nem resultados observados. Duas leituras são rápidas, mas uma ainda mostra disponibilidade antiga depois de a fonte mudar.
Verificar
Comparar valor, versão, local de leitura e tempo desde a alteração. Testar invalidação, expiração e acesso à fonte segundo o contrato do sistema.
Agir
Definir a atualidade aceitável por utilização e vigiar divergências. Menor latência não demonstra coerência dos dados servidos.

Cache de API: controlar frescura, isolamento e consistência

Cache HTTP: proteger respostas personalizadas

IETF — RFC 9111, HTTP Caching

Verificar destinatário e permissões

Um token assinado não autoriza automaticamente uma operação de objeto. Testar emissor, público-alvo, expiração e acesso entre contas; adicionar negações esperadas junto com os casos de sucesso.

Um token válido para outra API ou função é realmente rejeitado?

Explore os métodos

Ler os dados e decidir

Tentativas API: contar o orçamento completo de tempo

Quatro tentativas incluem três repetições.

Tentativas totais
41 + 3
Esperas acumuladas (ms)
700100 + 200 + 400
Orçamento modelado (ms)
17004 × 250 + 700

Caso pedagógico fictício: os números não representam a CIE nem clientes.

Experimentar um orçamento de tentativas

n × T + W × (2^(n−1) − 1)

Perguntas para preparar as suas decisões

Encontre respostas e verificações práticas nas análises desta secção.

Explorar o arquivo

Outras análises deste tema, além dos artigos recentes apresentados abaixo.

Referências: dados, usos e limites

Documentação consultada em .

As notas detalhadas desta edição estão disponíveis em inglês.

Threat intelligence: content, exchange and sharingThree distinct functions. STIX 2.1 · Describe. TAXII 2.1 · Exchange. TLP 2.0 · Share. None establishes truth alone. Objects and relationships. Collections and protocol. Permitted recipients. Local validation: origin, period, relevance and permissions.Threat intelligence: content, exchange and sharingThree distinct functionsNone establishes truth aloneSTIX 2.1 · DescribeObjects and relationshipsTAXII 2.1 · ExchangeCollections and protocolTLP 2.0 · SharePermitted recipientsLocal validation: origin, period, relevance and permissions
Threat intelligence: content, exchange and sharing
Referências: dados, usos e limites
Fonte e finalidadeDado ou referência verificadaComo utilizarLimite a preservar
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Aprofundar o método →

 A keyword in a report alone does not establish the correct CWE classification.
OASIS · STIX 2.1

Describe threat intelligence through structured objects and relationships.

 STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation. Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period.

Aprofundar o método →

 A syntactically valid object can still be stale, misattributed or weakly supported.
OASIS · TAXII 2.1

Exchange threat intelligence through an application protocol.

 TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed.

Aprofundar o método →

 TAXII transports data; it replaces neither the content model nor assessment of reliability.

Identidade: fatores, sessões e recuperação

As notas detalhadas desta edição estão disponíveis em inglês.

Identity APIs: separate authentication and authorisation

A valid token identifies a session or identity under its protocol. It does not automatically grant access to every business object. Recovery and revocation must be checked on the consuming backend.

  • Check applicable issuer, audience, expiry and permissions.
  • Replay access to an unauthorised object and a revoked session.
  • Record useful decisions without logging authentication secrets.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, cache HTTP e alterações concorrentes

As notas detalhadas desta edição estão disponíveis em inglês.

Specify conflicts in the API contract

The contract should explain which validator accompanies a representation and how clients handle refusals.

  • State whether PUT requires a conditional field and when 428 is issued.
  • Document strong If-Match, 412 and the conflict-resolution journey.
  • Support HEAD and 304 without content and test SDK behaviour.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: espera, orçamento e repetição

As notas detalhadas desta edição estão disponíveis em inglês.

Specify permission to repeat before retry timing

Retry-After describes waiting. The contract must also define replayable operations, keys, versions and unknown-result states.

  • State whether the field is seconds or a date and how clients handle absent or invalid values.
  • Name the retry controller and global budget to prevent overlapping attempts.
  • Retain parameters, context and the idempotency window without generalising Stripe to every API.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Explorar o catálogo KEV da CISA

As notas detalhadas desta edição estão disponíveis em inglês.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Explorar o catálogo e o método →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Extensões: permissões e acesso

As notas detalhadas desta edição estão disponíveis em inglês.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Códigos syslog e provas de recolha

As notas detalhadas desta edição estão disponíveis em inglês.

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Erros API: tipos, estados e provas

As notas detalhadas desta edição estão disponíveis em inglês.

Include errors in contract tests

A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.

  • Replay existing clients against representative refusals.
  • Check tolerance of unknown extensions and localised text.
  • Document migration of a problem identity and actually observed use.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL: erros, listas e dados parciais

As notas detalhadas desta edição estão disponíveis em inglês.

GraphQL API: contract, access and reading experience

Extend API checks with partial-response acceptance cases, field-access tests and a resource budget specific to the service.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

API: descontinuação e retirada

As notas detalhadas desta edição estão disponíveis em inglês.

Plan retirement beyond the version number

A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.

  • Distinguish Deprecation, Sunset and policy links.
  • Check that Sunset does not precede Deprecation when both dates are provided.
  • Measure remaining consumers and validate the replacement before cutover.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Fontes de referência

Documentos originais das organizações responsáveis por estes métodos e normas.