En el lenguaje REST, ¿cuál es la diferencia entre un recurso y una representación?

Comprendo REST que permite modelar operaciones de servicio como representación de estado y transición de un estado a otro haciendo uso de HTTP. Siempre he entendido los recursos como representaciones del estado del lado del servicio hasta hace poco cuando leí este artículo de Jimmy Bogard, a quien conozco como un desarrollador / arquitecto inteligente muy respetado por la comunidad. Para citar una declaración específica de esa publicación

La representación es un poco diferente: describe el estado actual del recurso (cuando se solicita).

Esto me ha dejado confundido. ¿Cuál es la opinión generalmente aceptada sobre el tema?

Respuesta corta

El mapa no es el territorio.

Respuesta más larga: como con cualquier cosa REST, el lugar para comenzar es con la tesis de Roy Fielding ; en particular el capítulo 5 . Para su pregunta actual, desea la sección 5.2.1.

REST está definido por cuatro restricciones de interfaz: identificación de recursos; manipulación de recursos a través de representaciones; mensajes autodescriptivos; e hipermedia como motor del estado de la aplicación.

Recurso

La abstracción clave de información en REST es un recurso. Cualquier información que se pueda nombrar puede ser un recurso: un documento o imagen, un servicio temporal (por ejemplo, "el clima de hoy en Los Ángeles"), una colección de otros recursos, un objeto no virtual (por ejemplo, una persona), etc. . En otras palabras, cualquier concepto que pueda ser el objetivo de la referencia de hipertexto de un autor debe ajustarse a la definición de un recurso. Un recurso es un mapeo conceptual a un conjunto de entidades, no la entidad que corresponde al mapeo en un punto particular en el tiempo.

Representación

Los componentes REST realizan acciones en un recurso utilizando una representación para capturar el estado actual o previsto de ese recurso y transfiriendo esa representación entre componentes. Una representación es una secuencia de bytes, más metadatos de representación para describir esos bytes. Otros nombres comúnmente utilizados pero menos precisos para una representación incluyen: documento, archivo y entidad, instancia o variante de mensaje HTTP.

Una representación consiste en datos, metadatos que describen los datos y, en ocasiones, metadatos para describir los metadatos (generalmente con el propósito de verificar la integridad del mensaje).

Entonces: "el clima de hoy en Los Ángeles" es un recurso. Las representaciones de los candidatos incluirían: un documento de texto con el último pronóstico del servicio meteorológico nacional; una representación visual del radar meteorológico y grabación de audio del pronóstico.

Un recurso es con lo que está trabajando. Por ejemplo, si tiene una API para cambiar una determinada lámpara, entonces el recurso es la propia lámpara. Un recurso puede ser físico (por ejemplo, lámpara, persona) o no físico (por ejemplo, artículo, rol, una fila en la base de datos), un recurso puede ser primario (por ejemplo, saldo) o derivado (por ejemplo, transacción). Un recurso puede referirse a una entidad específica (por ejemplo, la quinta lámpara instalada en este portalámparas), o puede referirse a un rol que se asigna a una entidad diferente en un momento diferente (por ejemplo, la lámpara instalada actualmente, la lámpara instalada el 5 de agosto de 2008) o puede mapearse a múltiples entidades (por ejemplo, todas las lámparas de la casa).

La representación de un recurso es la forma en que su servicio comunica el estado del recurso, por ejemplo, XML, JSON que representa el estado de la lámpara.

En la API REST, un recurso se identifica mediante un identificador uniforme (por ejemplo, URI). Un solo recurso puede tener múltiples representaciones, en la API REST de HTTP normalmente indicaría la representación que desea usar en los encabezados de tipo de contenido HTTP y Aceptar.

Una de las realizaciones clave en la arquitectura del servidor del cliente es que no puede llevar el recurso al cliente, y no debe intentar hacerlo como lo hace. En cambio, en la API REST, manipulas remotamente un recurso mediante la transferencia de representaciones del recurso. Piense en esto como si no le diera FedEx a la lámpara para que el cliente pueda manipular la lámpara directamente, sino que el servicio crea una representación XML / JSON / protobuf / CSV de la lámpara y el cliente envía una representación de las manipulaciones previstas. Luego, el servicio manipula el estado real de la lámpara en nombre del cliente, o rechaza la solicitud, por ejemplo, si el cliente no está autorizado para realizar las operaciones en la lámpara. Esto puede parecer obvio / dividir el cabello, pero lo importante a tener en cuenta es que, dado que la representación no es el recurso en sí,

Un recurso puede ser una factura.

Una representación es una factura en un momento específico en formato JSON o en formato XML. Puede obtener exactamente la misma factura en una fecha posterior, será el mismo recurso pero en un estado potencialmente diferente (cancelado, pagado, etc.).

Usted toma el estado actual de la factura (por ejemplo: todos los datos de la factura en la base de datos) y le da una representación específica (por ejemplo: html, xml, json) en un punto específico en el tiempo, para transferirla a otro dispositivo (por ejemplo: un navegador)