Déjame darte un breve descanso. Te tengo ahí.
Lo que quise decir es que les dé
una breve visión general de la Transferencia Estatal Representacional.
¿ Qué es exactamente REST?
¿ Cómo hacemos uso de ella en nuestra aplicación React,
y cómo hacemos uso de esto para comunicarnos con el servidor?
¿ Cómo admite un servidor la API REST
y cómo accedemos a la API REST desde nuestra aplicación React?
Hablemos de eso un poco más en esta lección.
Estoy seguro de que ha escuchado el término servicios web que se menciona en el mundo de TI muy a menudo.
¿ Qué son exactamente los servicios web?
Los servicios web son una forma de diseñar sistemas para apoyar la interoperabilidad
entre sistemas que están conectados a través de una red como Internet, tal como vemos hoy en día.
Esto es a lo que nos referimos como una arquitectura orientada a servicios.
Ahora, lo que esto significa es que proporciona
una forma estandarizada para que dos máquinas que están conectadas a Internet puedan
comunicarse entre sí a
nivel de aplicación para aplicaciones basadas en web utilizando estándares abiertos.
Ahora, he usado mucha jerga allí.
Tratemos de desglosarlos y entender
un poco acerca de cada uno de ellos en esta conferencia.
Dos enfoques comunes que se utilizan para admitir servicios web son SOAP.
Los servicios web basados en Protocolo simple de acceso a objetos que utiliza
el lenguaje de descripción de servicios web para
especificar cómo los dos extremos se comunican entre sí.
Normalmente, SOAP se basa en
el uso de XML como formato para los mensajes que se intercambian entre los dos extremos.
Representational State Transfer o REST también utiliza estándares web,
pero el intercambio de datos entre los dos extremos podría ser XML o
utilizar cada vez más JSON como formato.
La forma REST de interoperabilidad es más simple en comparación con SOAP y, por lo tanto,
REST ha encontrado una implementación mucho más amplia en el mundo de los servicios web.
Normalmente, la comunicación cliente-servidor se
facilita mediante REST, donde el servidor admite una API REST y
el cliente puede entonces invocar los extremos de la API REST
para obtener información o cargar información en el servidor.
Una vez más, he mencionado la palabra invocar los extremos de la API REST,
por lo que estos son algunos términos que he usado.
Vamos a aclarar algunas de estas en las próximas diapositivas.
La transferencia de estado representacional es un estilo de arquitectura de software
que está especialmente diseñado para hipermedios distribuidos a través de la World Wide Web.
Esto fue introducido por primera vez por Roy Fielding en su tesis doctoral.
Esta es una de esas tesis de doctorado
que realmente produjo algo útil para el mundo.
Así que esto ha encontrado de nuevo una gran cantidad de tracción en el mundo de los servicios web.
Esta es una colección de principios de red que describen cómo
los recursos pueden estar disponibles en los servidores
y a estos recursos se puede acceder desde los clientes
mediante la identificación de los recursos mediante extremos de API de descanso.
Dentro de la Transferencia de Estado Representacional,
existen cuatro principios básicos de diseño.
En primer lugar, REST se basa en el protocolo HTTP,
por lo que utiliza todos los métodos HTTP que ya hemos visto en la lección anterior.
En segundo lugar, REST está diseñado para ser sin estado,
lo que significa que el servidor no almacena ninguna información sobre
el estado después de que se complete la comunicación.
Entonces, cuando un servidor recibe la solicitud, el servidor responde,
y luego no recuerda
nada más sobre la conversación entre el cliente y el servidor.
En tercer lugar, la forma REST de proporcionar recursos es
exponer una estructura de directorios como URLs (Uniform Resource Locators - URLs).
En cuarto lugar, el formato para el intercambio de datos suele ser JSON
o XML o ambos pueden ser compatibles con REST.
Una de las motivaciones para que Roy sugiera REST como una forma de apoyar los servicios web
es que captura todas las cosas que son buenas sobre
la World Wide Web y que hizo que la World Wide Web tuviera éxito.
El uso de indicadores uniformes de recursos o
localizadores uniformes de recursos (URL) que permiten
abordar los recursos especificándolos como una dirección URL.
El segundo, siendo un protocolo que vive en la parte superior del protocolo HTTP.
HTTP ya ha encontrado una amplia implementación en Internet.
En tercer lugar, el ciclo de respuesta de solicitud por el que HTTP es conocido.
Por lo tanto, envía una solicitud,
el servidor recibe su solicitud, procesa
la solicitud, envía la respuesta a la solicitud,
y el cliente recibe la respuesta,
actúa sobre eso y puede generar más solicitudes.
Por lo tanto, este enfoque del ciclo de respuesta de solicitudes está muy
bien establecido con HTTP y la World Wide Web.
Ahora, el protocolo HTTP como hemos visto anteriormente,
vamos a utilizar todos los diversos verbos que HTTP proporciona.
específicamente, GET,
PUT, POST y DELETE para poder
especificar las operaciones que se deben realizar en los recursos que se almacenan en el lado del servidor.
Entonces, por ejemplo, si hace una solicitud HTTP GET,
está pidiendo que el servidor devuelva el recurso.
Si realiza una solicitud POST,
está pidiendo que el servidor cree un nuevo recurso.
Si realiza una solicitud PUT,
solicita al servidor que actualice un recurso existente.
Y si emite una solicitud DELETE,
está pidiendo al servidor
que elimine el recurso identificado por la URL en particular.
Además, trata de preservar Idempotencia.
Algunas operaciones, cuando se realizan incluso repetidamente,
no causarán ningún cambio de estado.
Algunas otras operaciones, si las hace sucesivamente,
pueden causar un cambio de estado.
Por lo tanto, debe tener cuidado con qué operaciones se pueden repetir
sin consecuencias perjudiciales y cuáles deben hacerse con mucho cuidado.
En el mundo REST a menudo escuchas a la gente hablando de sustantivos, verbos y representaciones.
Ahora, aclararemos cada una de ellas con un poco más de detalle en las próximas diapositivas.
Los sustantivos se refieren específicamente a los recursos y estos recursos
suelen ser identificados por sus direcciones URL y estos no están restringidos.
Los verbos son restricciones y estos especifican las acciones que se deben
realizar en los recursos y representaciones como vemos.
Cuando la información necesita ser transmitida desde
el servidor al cliente o desde el cliente al servidor,
cómo codifica la información.
Normalmente, ya sea usando JSON o usando XML. El
recurso es la abstracción clave en la que REST trabaja.
Por lo tanto, la información se abstrae en forma de un recurso y el recurso
se identifica especificándolo mediante una URL.
Por lo tanto, cualquier información que se pueda encapsular y poner a disposición,
se puede identificar como un recurso.
Una información como el clima actual en Hong Kong podría ser un recurso, una
imagen podría ser un recurso,
una información sobre el precio de las acciones podría ser un recurso y así sucesivamente. Por
lo tanto, lo que defina como una pieza de información en la que un cliente puede estar interesado,
puede ser identificado como un recurso.
Incluso puede tratar con los recursos como colección de
recursos que el servidor puede enviar al cliente.
Aquí se ilustra un ejemplo de cómo se asignan nombres a los recursos.
Así que usamos URI para identificar la fuente.
Una lectura rápida de estas especificaciones o de los URI aquí
le permitirá comprender fácilmente a qué nos estamos refiriendo mediante el uso de estos URI.
Entonces, por ejemplo, algo que termina con platos/,
automáticamente asumes que esto se refiere a una colección de platos.
Pero platos/123, por ejemplo,
podría significar plato número 123 en este caso y así sucesivamente. Por
lo tanto, es muy fácil de guardar y puede especificar
una colección de recursos y ser capaz de
identificarlos como una colección y luego descargarlos como una colección o puede
identificar un recurso individual y decir que desea ese recurso en particular.
Ahora, estos recursos se pueden organizar en una jerarquía de la especificación de este URI.
Por lo tanto, a medida que atraviesa
la ruta, pasa de lo más general a lo más específico del recurso.
Esta estructura de directorios le permite identificar
fácilmente los recursos que utiliza o proporciona desde el lado del servidor.
La segunda parte de la API REST son los verbos.
En particular, estamos interesados en los cuatro verbos de HTTP el GET,
PUT, POST y DELETE.
En este caso, estos verbos se asignarán a acciones que
queremos realizar en el recurso, en el lado del servidor.
Un GET significaría que desea realizar una operación de lectura en el recurso.
Por lo tanto, lo que significa que un cliente que envía una solicitud GET está indicando
al servidor que desea obtener una representación
de ese recurso desde el lado del servidor al lado del cliente.
Un POST significa que desea crear
un nuevo recurso y, a continuación, especificará los detalles del recurso
en la representación que se utiliza para
especificar el recurso y, a continuación, enviará esa información al lado del servidor, de
modo que el servidor creará ese recurso en su nombre.
Un PUT sería una modificación de los recursos y
un DELETE como cabría esperar es la eliminación de los recursos.
Así, como puede ver, los cuatro verbos:
GET, POST, PUT y DELETE,
se asignan a las cuatro operaciones CRUD que se pueden
realizar en una base de datos que almacena estos recursos en el lado del servidor,
las operaciones READ, CREATE, UPDATE y DELETE.
Más adelante, HTTP GET es una forma de especificar que
desea que la información o la representación
del recurso se devuelva al cliente desde el lado del servidor.
Por lo tanto, cuando emite una solicitud GET a un extremo de API REST,
está pidiendo una colección de recursos representados por
URI o un recurso específico que se identifica mediante el ID de ese recurso en particular,
especificado dentro de la URL. Por
lo tanto, como puede ver en este ejemplo,
si dice, platos/452,
quiere decir que el plato número 452 con
el ID 452 debe devolverse al lado del cliente.
Del mismo modo, la operación POST tal como vimos se utiliza para crear el recurso.
Por lo tanto, al crear el recurso,
el contenido de describir el recurso sería en forma de una representación JSON o
una representación XML y que se incluirá en
el cuerpo del mensaje de solicitud que se envía al lado del servidor.
Por lo tanto, una operación POST espera una representación
del recurso en formato JSON o XML en el cuerpo del mensaje de solicitud.
Cuando el servidor recibe ese mensaje de solicitud,
el servidor crea ese recurso en el lado del servidor y, a continuación, devuelve
una conformación o un error para indicar que la creación del recurso falló.
Del mismo modo, se utiliza una operación PUT para actualizar un recurso.
Cuando realiza una operación PUT en un recurso en el lado del servidor,
puede devolver la modificación
especificando sólo la modificación parcial que desea aplicar en
el recurso particular en el cuerpo del mensaje de respuesta o puede enviar
la representación completa del en el cuerpo del mensaje.
Dependiendo de la disposición entre el cliente y el servidor,
el servidor espera que la información se transmita en el cuerpo del mensaje de solicitud.
Una operación DELETE como cabría esperar elimina el recurso existente.
Ahora, en este caso particular,
por supuesto, una operación DELETE sería idempotente porque si
intenta eliminar un recurso y el recurso existe, se eliminará.
Si está intentando eliminar un recurso no existente,
no causará ninguna modificación adicional en el lado del servidor,
excepto que el servidor responderá con un error que indica que el recurso no existe.
Pero, sin embargo, DELETE es un ejemplo de una operación idempotente en este caso.
Del mismo modo, la operación GET también es una operación idempotente porque
no está realizando ninguna modificación en el recurso en el lado del servidor.
POST y PUT, por supuesto, van a modificar el recurso en el lado del servidor,
ya sea crear un nuevo recurso o modificar un recurso existente en el lado del servidor.
Por supuesto, las representaciones,
como he estado enfatizando,
los dos formatos comunes para representar son JSON o XML.
La última parte que debemos enfatizar es
que el lado del servidor debe ser completamente sin estado,
lo que significa que el lado del servidor no realiza un seguimiento
del estado del cliente porque si el servidor necesita rastrear el estado de los clientes,
no será escalable.
Por lo tanto, para una implementación escalable del lado del servidor,
normalmente usa un servidor sin estado en el lado del servidor.
Por lo tanto, cada solicitud que el cliente envía al servidor será
tratada como una solicitud independiente y
no se reflejará en solicitudes anteriores
que ya han sido manejadas por el servidor desde ese cliente en particular.
Por lo tanto, es responsabilidad del cliente rastrear su propio estado,
ya sea en forma de uso de cookies o utilizando una base de datos del lado del cliente,
cualquiera que sea el medio adecuado.
Ahora, este enfoque donde el cliente realiza
un seguimiento de su propio estado es mucho más escalable porque cada cliente individual
será responsable de rastrear su propio estado.
Aquí es donde la configuración de MVC del lado del cliente nos ayuda en este sentido.
Por último, aún no hemos terminado con REST.
Veremos más de REST en los ejercicios que siguen en esta lección en particular
y luego también veremos más detalles sobre el uso de REST en el resto de este curso.