Resumen

  • La RFC 6690 adaptó los enlaces tipados de la RFC 5988 a una representación compacta, application/link-format. Registró /.well-known/core bajo el esquema de URI conocidas como entrada al descubrimiento.
  • Cada enlace puede describir tipo de recurso rt, interfaz if, formato de contenido ct y tamaño máximo estimado sz. Se puede solicitar una lista filtrada, aunque el servidor no está obligado a implementar filtros.
  • La lista indica dónde hacer la siguiente solicitud. La lectura o el resultado llega en la respuesta del recurso elegido. CoAP incorporó después el descubrimiento a su modelo de transferencia para nodos limitados.

Ninguna persona atiende el mostrador

Una persona navega de enlace en enlace. Un pequeño controlador escondido en la instalación eléctrica no tiene pantalla ni alguien que le busque el camino a un termómetro. La RFC 6690 pensaba en microcontroladores de ocho bits y redes de poca energía. Memoria y tráfico escasean. Si cada controlador guarda rutas fijas, la sustitución de un sensor puede dejarlo llamando a una dirección que ya no sirve. Descubrir el recurso es una tarea propia, anterior a medir o actuar.

El estándar eligió una dirección común: /.well-known/core. Un servidor que implementa la especificación ofrece ese recurso en el puerto predeterminado del protocolo correspondiente. Un GET devuelve una representación CoRE Link Format, incluso de longitud cero cuando no hay enlaces. El ejemplo </sensors/temp>;rt="temperature-c";if="sensor" condensa ruta, tipo e interfaz. El controlador puede buscar otro enlace que describa luz y enviar a esa URI una segunda petición.

La primera respuesta es un plano, no la lectura. El sensor señalado puede estar dormido, haber cambiado de estado o exigir autorización cuando se le solicita algo. Separar los dos pasos permite que todos sepan dónde comenzar a buscar sin obligar a que cada recurso viva en la ventanilla. El plano lleva al cliente hasta una puerta; el recurso responde desde el otro lado.

El enlace dejó el encabezado

La RFC 5988 describió relaciones tipadas entre un contexto y un destino. La RFC 6690 tomó la sintaxis del campo HTTP Link y la hizo cuerpo de una representación con tipo de medio application/link-format. El destino aparece entre signos angulares; los atributos siguen detrás; las comas separan descripciones. Esa forma evita que un dispositivo escaso tenga que procesar un árbol XML para descubrir una dirección. Además, el índice se solicita como recurso propio en lugar de venir escondido en el encabezado de otra respuesta.

Cuatro atributos cortos resuelven preguntas diferentes. rt nombra un tipo de recurso elegido por la aplicación: una medida de temperatura, por ejemplo. if describe la interfaz para interactuar con él; una misma interfaz puede servir a tipos distintos. ct indica un formato de contenido. sz estima la representación más grande que devolvería GET, dato útil para elegir una estrategia de transferencia con poca memoria. rt no sustituye un nombre legible para una persona; el estándar reserva title para ese propósito. Ninguno de esos campos, por sí solo, confirma que el dispositivo haya producido una medida hoy.

Si falta rel, la relación tiene un valor predeterminado: hosts. El contexto del enlace aloja el destino. Una relación explícita o anchor puede describir otro vínculo, incluso hacia un recurso situado en otro servidor. Al copiar solo las URI y tirar el contexto, un índice externo podría parecer una lista de recursos alojados localmente. En un formato pequeño, esos pocos signos conservan quién está afirmando qué relación.

La ventanilla no tiene que mostrar todo el edificio

El servidor decide qué enlaces aparecen en /.well-known/core y cómo se organizan. Puede publicar únicamente la entrada /sensors, y dejar a esa colección la lista de sensores individuales. La ventanilla evita repetir todo el inventario del edificio ante cada cliente que pregunta por dónde empezar.

También puede pedirse una selección: GET /.well-known/core?rt=light-lux busca enlaces cuyo tipo de recurso sea light-lux. La RFC permite filtrar y describe cómo hacerlo; el servidor no tiene la obligación de responder con un filtro aplicado. Un resultado vacío exige averiguar si había enlaces anunciados, si el criterio fue entendido y qué vista ofreció el servidor a ese cliente. Los valores de rt e if son vocabulario de cada aplicación, no una lista universal de modelos de sensores.

Algunos dispositivos duermen y algunos enlaces tienen poco ancho de banda. Preguntar a todos los sensores cada vez sale caro. La RFC esboza entonces un directorio de recursos: una entidad más capaz guarda enlaces de otros servidores y permite consultarlos. Los detalles completos del directorio quedaron para otros documentos. El servidor original publica una descripción; el directorio conserva una copia; el cliente escoge un camino; el destino devuelve el dato. Una copia vieja puede seguir mostrando un camino que ya no funciona.

El plano tiene dueño

La arquitectura nació de acuerdos modestos. La RFC 5785 dio la convención de la URI conocida, la RFC 5988 aportó las relaciones y la RFC 6690 las convirtió en una representación ligera con un punto de entrada. La RFC 7252, de 2014, colocó el descubrimiento entre las funciones de CoAP. No se creó un registro mundial de todos los sensores. Se fijó dónde comienza una conversación con cada servidor.

El servidor controla su lista. Puede protegerla y mostrar enlaces diferentes según quién pregunte. Ocultar una URI, sin embargo, no impide la solicitud de quien ya la conoce o la adivina; el recurso debe aplicar su propio control de acceso. Si importa la procedencia del plano, el cliente debe autenticar al servidor que se lo entrega. La ventanilla, el directorio y el sensor son custodios distintos.

Los cuatro documentos oficiales prueban sintaxis, dirección registrada y secuencia de descubrimiento. Para demostrar que un edificio concreto la utilizó faltan firmware fechado, la respuesta /.well-known/core observada y la petición posterior al sensor. Nuestro controlador encontró una dirección. La cifra de luz todavía tiene que venir del aparato que está allí.