web services - sirve - ¿Qué significa el estado representacional en REST?
rest web services (7)
He estado leyendo en toda la red para obtener el significado exacto de dos palabras:
ESTADO REPRESENTACIONAL
Tengo una duda. Estoy malinterpretando estos términos. Quiero aclarar el entendimiento con alguien que tiene buena idea sobre esto.
Según entiendo, hay un recurso ubicado en el servidor. SO Rest significa eso, transfiriendo algún estado de representación de este recurso a un cliente.
si el servidor tiene un recurso x, entonces si podemos hacer el estado representativo y del recurso x, y transferirlo a través de la web es lo que REST significa, ¿es correcto o cuál es el significado correcto de él? podría alguien explicarme esto.
Aunque REST no tiene estado, tiene una transferencia de estado en su nombre. Es un poco confuso para todos.
Apátrida
Cuando abre una página web en el navegador, actuará como un consumidor de servicios y el servidor www actuará como un proveedor de servicios para servirle con una página web. Si se trata de una conexión normal, el cliente y el servidor realizarán un apretón de manos e iniciarán una sesión (llamada conexión TCP).
Después de eso, según el comportamiento del servidor y del cliente, el estado cambiará a ESTABLISHED, IDLE, TIMEOUT, etc. Pero en REST, estamos usando el protocolo HTTP, que es un sin estado, lo que significa que el servidor no almacenará ninguna información de sesión sobre el cliente. El cliente es responsable de enviar todos los detalles requeridos por el servidor para recibir el servicio, es decir, cuando invocamos el URI http://somedomain:8080/senthil/services/page1 del servidor, tiene suficientes detalles sobre el cliente para servir. página1 completamente.
Transferencia de estado
Usando el mismo ejemplo, cuando abre una página web usando algún URL para ver un archivo de imagen (RESOURCE) en el servidor, el servidor www le mostrará (al cliente) la imagen en algún formato, es decir, una REPRESENTACIÓN del RECURSO (archivo de imagen )
Durante este proceso, el estado de recursos constantes del servidor (es decir, el estado del archivo de imagen que se almacena en la base de datos del servidor) se representará al cliente en un formato comprensible, es decir , el estado de la aplicación del cliente. Por lo tanto, el estado del recurso permanecerá constante con respecto a los clientes, y solo la representación del recurso cambiará, lo que a su vez cambiaría el estado de la aplicación.
Finalmente, la representación del recurso (cómo se muestra la imagen al cliente), que cambia implícitamente el estado tanto del servidor como del cliente, se denomina REST.
Cada objeto tiene algún estado (datos) y comportamiento (métodos). Para transferir el estado del objeto en el servidor en un momento particular al cliente, se necesita algún tipo de representación como JSON o xml o cualquier otro formato.
Así que REST consiste en crear una representación del estado actual del objeto y transferir esa representación a través de la red.
Creo que toda la pregunta sobre la preocupación del estilo arquitectónico REST, gira en torno a la comprensión, que el autor, Roy Fielding, tuvo en mente sugerir en su disertación, un conjunto de principios arquitectónicos para construir arquitecturas basadas en el hipertexto o paradigma hipermedia.
Este paradigma, creo, es la clave central para entender este importante tema.
Detrás del estilo de organizar la arquitectura de una aplicación cliente-servidor propuesta por Roy Fielding, creo que hay una idea específica de una aplicación cliente-servidor moderna, que consiste en una especie de motor para gobernar la transición del estado de la aplicación, cuyos estados son potencialmente extensibles a infinito.
En esta visión, Ipertext / Ipermedia es el centro de todo el estilo arquitectónico propuesto por Fielding y el concepto clave que permite que este paradigma funcione es la "transferencia de representación (estado)".
Creo que "representacional" se refiere al concepto sobre la "transferencia" , en lugar del concepto sobre "estado", es decir, que la transferencia es representativa (de tipo representativo), y eso es, en mi opinión, la causa principal del nombre "Transferencia de estado representativo".
Entonces, al diseñar una aplicación Restful, primero se diseña una arquitectura basada en una red de componentes, cada uno de ellos se comunica con otros en un modelo de arquitectura en capas cliente-servidor, enviando a cada uno de ellos una representación de su estado.
Y así, el front-end, el primer cliente de esta arquitectura, transita a través de sus estados que muestran la representación de los estados enviados por el componente, o componentes, que llama endosar en una interfaz consistente uniforme y no en una API privada.
Un tipo de aplicación de este tipo, en la mente del autor, es potencialmente extensible a estados infinitos, porque sus estados no dependen de una API privada, sino que dependen de un sistema identificador univoque (como URI) compartido por todos los agentes en esta arquitectura , en algunos algunos verbos para administrar la transición de sus estados y en un sistema de transferencia representacional compartido acordado, o más.
Esta transición finaliza con la comunicación de su representación al componente del servidor llamado a través de los verbos que componen la API "pública", que debe pertenecer al protocolo de comunicación sin estado utilizado por los componentes cliente-servidor.
De esta forma, esta interacción de componentes cliente-servidor consiste en intercambiar (comunicar) representaciones de estados de componentes de la utilización de un protocolo sin estado.
Y el concepto central que permite que todas estas arquitecturas se extiendan potencialmente al infinito es la transferencia representacional que avala su arquitectura.
El significado de la TRANSFERENCIA ESTATUTARIA REPRESENTATIVA es el RESTO
RESTful ha puesto VERBO DIRECTO en el servidor
En el ejemplo de la consideración real, el valor puesto en el VERBO tiene comúnmente de HTTP GET y POST
Tiene un protocolo SIMPLE parecido al SOAP (¡tiene mucho complejo!)
Si la respuesta no es satisfactoria, por favor, brinde una respuesta más elaborada a la pregunta
REST tiene mucho tema de discusión, es tema de muchos blog y libro
Imagine un diagrama de estado; lo siguiente será suficiente.
Si este fuera el conjunto de páginas web, comenzaría en la página de aterrizaje de pregrado para un estudiante. Según el diagrama, cuando haga clic en el enlace "Siguiente", lo llevará a la página Freshman , suponiendo que el alumno se ha graduado. Al hacer clic en "Siguiente" varias veces, se llega a la última página.
Por supuesto, podría haber otras transiciones como "Inicio" que le permiten saltar a la página predeterminada.
El estado visible del sitio web no tiene nada que ver con la forma en que el servidor implementa esta asociación internamente, es decir, los estados internos. Puede involucrar múltiples bases de datos, servidores y otras cosas. Un estudiante puede graduarse y su estado puede haberse actualizado a través de otros métodos. El cliente no tiene conocimiento de estos detalles, pero siempre puede esperar obtener un estado (conjunto) coherente y visible para el consumo humano (o máquina).
Otro ejemplo: cuando mira esta página, se encuentra en una "ubicación" identificable y reproducible particular en la jerarquía web de .
Entonces, RESTful State trata con la navegación.
Representational State Transfer se refiere a la transferencia de "representaciones". Está utilizando una "representación" de un recurso para transferir el estado de recursos que vive en el servidor al estado de aplicación en el cliente.
TL; DR
Representational state transfer o simplemente REST es un término para intercambiar datos en formatos bien definidos con el fin de aumentar la interoperabilidad. A través de la aplicación de ciertas restricciones, debe lograrse el desacoplamiento de los clientes a los servidores, lo que hace que el primero sea más robusto y el último más flexible a los cambios.
Una representación de recursos es el resultado de aplicar un mapeo desde el estado actual de los recursos a una estructura y sintaxis bien definidas. Por lo tanto, está muy acoplado con content-negotiation que define el proceso de acordar un tipo de medio para transformar el estado de los recursos en una representación solicitada (= sintaxis y estructura).
REST se puede ver como una técnica para desacoplar clientes de servidores / API en un sistema distribuido que le da libertad al lado del servidor para evolucionar y cambiar su estructura a sus necesidades sin romper las implementaciones de los clientes.
Para obtener un beneficio tan fuerte, es necesario contar con un par de condiciones previas, ya que casi nada es gratis. Aquí, Fielding definió un par de restricciones que luego aclaró (y explicó) en su publicación de blog conocida . Los servidores no podrán lograr dicha libertad si los clientes no siguen el enfoque REST, así como los clientes no podrán explorar dinámicamente otras posibilidades si el servidor no admite clientes en tal sentido. En resumen, ambas partes deben seguir los mismos principios. Si no se sigue el enfoque estricto, se mantendrá un acoplamiento directo entre el servidor y los clientes, lo que provocará fallas si el servidor va a cambiar alguna vez.
Pero, ¿cómo se logra realmente el desacoplamiento?
En primer lugar, un servidor debe ayudar a un cliente a seguir su tarea al incluir los URI que los clientes pueden usar. Tener un servidor que proporcione todos los URI que un cliente puede invocar desde el estado actual en el que se encuentra el cliente elimina la necesidad de que el cliente tenga un conocimiento a priori de la API y cómo están estructurados los URI.
En segundo lugar, en lugar de dejar que los clientes interpreten los URI, los servidores deberían devolver los URI en combinación con los nombres de las relaciones de enlace. En lugar de que un cliente use (e interprete) un URI como http://server.org/api/orders , debe usar una relación de enlace como new-order . Si el servidor cambia el URI anterior a, por ejemplo, http://server.org/api/new-orders por el motivo que sea, los clientes que utilizan los nombres de las relaciones de enlace podrán seguir su tarea, mientras que aquellos que usan el URI directamente necesitarán una actualización antes de pueden continuar
Que yo sepa, aún no existen estándares en los que tales nombres de relación de enlace deban definirse y documentarse. Para los enlaces de colección, la semántica de los nombres de relación como self , prev , next , first y last parecen ser lo suficientemente significativos, aunque algo más específico de dominio como order o product-xyz puede no product-xyz . Tal semántica puede describirse en tipos de medios especiales o nuevos estándares.
Hasta ahora, estos puntos abordan la restricción de HATEOAS, pero lamentablemente aún no es todo. De acuerdo con la publicación de blog de Fieldings:
Una API REST debería dedicar casi todo su esfuerzo descriptivo a definir los tipos de medios utilizados para representar los recursos y dirigir el estado de las aplicaciones, o al definir nombres de relaciones extendidas y / o márgenes habilitados para hipertexto para los tipos de medios estándar existentes.
Fielding además comentó que:
Una API REST nunca debe tener recursos "tipeados" que sean significativos para el cliente. Los autores de las especificaciones pueden usar tipos de recursos para describir la implementación del servidor detrás de la interfaz, pero esos tipos deben ser irrelevantes e invisibles para el cliente. Los únicos tipos que son importantes para un cliente son el tipo de medio de representación actual y los nombres de relación estandarizados.
Un recurso tipeado es un recurso donde un cliente tiene una preasunción del contenido. Es decir, un cliente que recibió un URI http://server.org/api/user/sam+sample con un nombre de relación de enlace, el user determina que los datos que pertenecen a ese recurso describen a una persona y, por lo tanto, puede intentar organizar una application/json representación application/json de los datos del recurso a un objeto Person .
El problema con los recursos tipados es que los clientes tienen ciertos supuestos o conocimientos preasignados sobre los datos contenidos en dichos recursos, es decir, un recurso de usuario que puede variar de un servidor a otro. Mientras que un servidor puede exponer un nombre de usuario como propiedad de name , otro servidor puede usar firstName y lastName y un cliente que quiera server cada posibilidad es casi imposible de mantener. Además, si el servidor cambia su lógica, los clientes pueden romper con cierta probabilidad. Para contrarrestar este acoplamiento, se deben usar tipos de medios en su lugar.
Los tipos de medios, que son descripciones textuales legibles por humanos de un formato de representación, definen la sintaxis utilizada así como la estructura y semántica de los elementos disponibles contenidos en los documentos intercambiados en ese formato. Las aplicaciones que siguen el modelo de arquitectura REST deben, por lo tanto, usar tipos de medios established o personalizados para aumentar la interoperabilidad. En lugar de acoplar directamente el cliente y el servidor, ambos se unen a los tipos de medios en realidad. Se puede proporcionar soporte para tales tipos de medios cargando bibliotecas existentes o implementando la especificación desde cero. Incluso cargando tales tipos de medios dinámicamente a través de complementos es posible, si es compatible.
Los clientes y servidores deben usar la content-negotiation para acordar un formato de tipo de medio común que ambas partes entiendan para intercambiar el estado actual de un recurso. La negociación del contenido se logra al proporcionar un encabezado HTTP Accept (y / o uno de sus hermanos), que enumera los tipos MIME que un cliente puede o desea procesar, dentro de la solicitud y respondiendo el servidor en uno de los formatos solicitados, incluido un encabezado de respuesta HTTP de Content-Type para informar al cliente qué representación de tipo de medio se utilizó en realidad o devolver una respuesta de fallo 406 .
Para el ejemplo de persona de arriba, los clientes podrían enviar un encabezado HTTP Accept con el siguiente contenido: application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1 para el servidor, que le pide al servidor devuelve el estado del recurso en una sintaxis y estructura definida por uno de los tipos de medios enumerados. Especifica además que el cliente prefiere recibir el estado formateado de acuerdo con la especificación de la application/vcard+json descripción del tipo de medio y si el servidor no puede, debería preferir hal + json a la sintaxis json tradicional. El servidor ahora asigna el estado del recurso actual a uno de los formatos solicitados o responde con un mensaje de error 406 apropiado si se desconocen todos los tipos de medios solicitados o si el estado no se pudo convertir a dicha estructura o representación predeterminada admitida por el cliente.
En resumen, REST es una técnica utilizada para lograr una alta interoperabilidad al depender de tipos de medios bien definidos y para separar a los clientes de los servidores mediante el uso de características como la negociación de contenido y HATEOAS. Como recompensa, los clientes se fortalecerán ante los cambios y, por lo tanto, necesitarán menos mantenimiento en general mientras que los servidores obtienen el beneficio de poder evolucionar y cambiar sin tener que temer que los clientes no puedan interactuar con él una vez que los cambios hayan comenzado.
Ciertas cosas como nombres de relación de enlace significativos estandarizados, tipos de medios dependientes de dominio personalizado y procesos de mapeo para transformar el estado en representaciones aplicables de tipos de medios deben configurarse primero, que es una tarea no trivial TBH, aunque una vez disponibles proporcionan los beneficios mencionados anteriormente.