Servicios conectados

Diseña integraciones y API fiables, con contratos claros, control de acceso y respuestas ante fallos.

52 artículos · Último artículo actualizado

La búsqueda incluye todos los artículos de esta sección, también el archivo y el texto de los artículos.

Comprender el tema

Guía práctica sobre este tema

Una función conectada depende de identidades, contratos de interfaz, proveedores y modos de fallo. Esta categoría conecta el diseño de la API, la seguridad, la continuidad y la calidad del servicio que reciben los usuarios.

Qué examinar
  • Identifica las llamadas esenciales para cada recorrido y sus responsables.
  • Planifica plazos, errores, reintentos seguros y degradación visible.
  • Ensaya interrupciones, recuperación y respuesta a incidentes.
  • Compara las respuestas reales con el contrato documentado antes de modificar una interfaz.
  • Prueba los permisos de cada objeto y campo GraphQL, y luego limita el anidamiento, las listas y los alias según el coste real.
  • Convierta una notificación recibida en un efecto comercial único y rastreable, recuperable después de un fallo.
  • Separe las cachés compartidas, privadas y de la aplicación, inspeccione las claves, la revalidación y la invalidación después de los cambios en los derechos de acceso.
  • Importar una URL puede dar acceso involuntario a recursos internos.
  • Los límites condicionan capacidad, reintentos y reparto entre clientes.
  • Definir orden, tokens, permisos y recuperación cuando la colección cambia durante la lectura.
  • Los archivos recibidos deben verificarse antes de publicarse o procesarse.
  • Un caché compartido debe separar contenido público y respuestas personales.
  • Una solicitud aceptada no demuestra que el trabajo haya terminado.
  • Distinguir eventos producidos, recibidos y utilizables sin interpretar el silencio como ausencia de incidentes.
  • Definir el contrato de mensajes de una iframe o ventana para rechazar remitentes y datos inesperados.
  • Validar rutas, enlaces y datos descomprimidos antes de publicar los archivos obtenidos.
  • Seguir la renovación hasta los puntos de terminación y los clientes antes de cerrar el cambio.
Preguntas útiles
  • ¿Qué sucede si un proveedor deja de responder?
  • ¿Puede un reintento repetir una acción?
  • ¿Qué evidencia demuestra que la recuperación funciona?
  • ¿A qué clientes existentes afectaría una nueva versión?
  • ¿Puede un resolvedor devolver un campo privado después de que su padre haya sido autorizado?
  • ¿Qué bytes están firmados?
  • ¿Significa que no se conserva nada si no hay caché?
  • ¿Comprobar solo la primera URL es suficiente?
  • ¿429 garantiza que una escritura anterior no se realizó?
  • ¿Una página vacía indica el final?
  • ¿Una extensión admitida demuestra que el archivo es seguro?
  • ¿Una cookie evita el caché compartido?
  • ¿202 demuestra que el trabajo terminará?
  • ¿Tres filas recibidas prueban que se conservaron tres eventos?
  • ¿Basta con comprobar event.origin?
  • ¿Un archivo pequeño o un filtro garantiza seguridad?
  • ¿Basta la renovación ACME exitosa?

Ejemplo ilustrativo de decisión

Situación
Ejemplo ficticio: estos datos no describen clientes ni resultados observados. Dos lecturas son rápidas, pero una sigue mostrando disponibilidad antigua después de cambiar la fuente.
Comprobar
Comparar valor, versión, lugar de lectura y tiempo desde el cambio. Probar invalidación, caducidad y consulta de origen según el contrato del sistema.
Actuar
Definir la frescura aceptable por uso y vigilar discrepancias. Una latencia menor no demuestra coherencia de los datos servidos.

Caché de API: controlar frescura, aislamiento y coherencia

Caché HTTP: proteger respuestas personalizadas

IETF — RFC 9111, HTTP Caching

Verificar destinatario y permisos.

Un token firmado no autoriza automáticamente una operación de objeto. Probar el emisor, la audiencia, la caducidad y el acceso entre cuentas; agregar denegaciones esperadas junto con los casos exitosos.

¿Se rechaza realmente un token válido para otra API o rol?

Explorar los métodos

Leer los datos y decidir

Reintentos API: calcular el presupuesto completo

Cuatro intentos incluyen tres reintentos.

Intentos totales
41 + 3
Esperas acumuladas (ms)
700100 + 200 + 400
Presupuesto modelado (ms)
17004 × 250 + 700

Caso didáctico ficticio: las cifras no representan a CIE ni a un cliente.

Probar un presupuesto de reintentos

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

Preguntas para preparar sus decisiones

Encuentre respuestas y comprobaciones prácticas en los análisis de esta sección.

Explorar el archivo

Otros análisis de este tema, más allá de los artículos recientes que aparecen abajo.

Observabilidad API: conectar señales con decisiones

Un panel de disponibilidad no explica todas las operaciones lentas o incorrectas. Parta del recorrido del usuario y conecte las señales necesarias para diagnosticarlo.

Publicado Actualizado

Referencias: datos, usos y límites

Documentación consultada el .

Las notas detalladas de esta edición están disponibles en 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
Referencias: datos, usos y límites
Fuente y finalidadDato o referencia verificadaCómo utilizarlaLímite que debe conservarse
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.

Profundizar en el 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.

Profundizar en el 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.

Profundizar en el método →

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

Identidad: factores, sesiones y recuperación

Las notas detalladas de esta edición están disponibles en 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, caché HTTP y actualizaciones concurrentes

Las notas detalladas de esta edición están disponibles en 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, presupuesto y reintentos

Las notas detalladas de esta edición están disponibles en 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 el catálogo KEV de CISA

Las notas detalladas de esta edición están disponibles en 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 el catálogo y el método →

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

Extensiones: permisos y acceso

Las notas detalladas de esta edición están disponibles en 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 y pruebas de recogida

Las notas detalladas de esta edición están disponibles en 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

Errores API: tipos, estados y pruebas

Las notas detalladas de esta edición están disponibles en 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: errores, listas y datos parciales

Las notas detalladas de esta edición están disponibles en 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: obsolescencia y retirada

Las notas detalladas de esta edición están disponibles en 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

Fuentes de referencia

Documentos publicados por las organizaciones responsables de estos métodos y normas.