[MÚSICA]
Déjame darte un breve descanso.
¡Te tengo ahí!
Lo que quise decir fue,
permítanme darles una breve visión general de la transferencia de estado representacional.
¿Qué es exactamente el descanso?
¿Cómo lo hacemos en nuestra aplicación angular y
cómo hacemos uso de esto para comunicarnos con el servidor?
¿Cómo admite un servidor REST API y
cómo accedemos a la API REST desde nuestra aplicación angular?
Hablemos de eso un poco más en esta lección.
En esta conferencia en particular, les daré una breve visión general de REST.
Estoy seguro de que ha escuchado el término Servicios Web siendo mencionado
en el mundo de TI muy a menudo.
¿Qué son exactamente los servicios web?
Los servicios web son una forma de diseñar sistemas que soporten la interoperabilidad entre sistemas
conectados a través de una red, como Internet como vemos hoy.
Esto es lo que nos referimos como una arquitectura orientada al servicio.
Ahora, lo que esto significa es que usted proporciona una forma estandarizada para que dos máquinas
que están conectadas a Internet puedan comunicarse entre sí.
Su nivel de diseño de aplicaciones para aplicaciones de base de datos
usando estándares abiertos.
Ahora, he usado mucha jerga allí.
Vamos a tratar de descomponerlos 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 el protocolo de acceso a objetos simples,
que utiliza el lenguaje de descripción de servicios web para
especificando cómo los dos puntos finales se comunican entre sí.
Y normalmente, soap se basa en el uso de XML como
el formato para los mensajes que se intercambian entre los dos extremos.
La transferencia de estado de presentación o descanso también utiliza estándares web, pero el intercambio
de datos entre los dos extremos podría ser XML o cada vez más.
Usando 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 los servicios web que quedan.
Normalmente, la comunicación con el servidor cliente se facilita mediante REST
, donde el servidor admite la API REST y el cliente puede invocar sus extremos de API REST
para obtener información o cargar información en el servidor.
Una vez más, he mencionado la palabra, invoque ese punto final de la API REST.
Así que estos son algunos términos que he usado.
Aclaremos algunos de estos 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.
Ahora esto fue introducido por primera vez por Roy Fielding en su tesis doctoral.
Ahora, esta es una de esas tesis doctorales que realmente produjo
algo útil para el mundo.
Así que esto ha encontrado de nuevo mucha 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 se puede acceder a estos recursos desde los clientes
identificando los recursos utilizando los puntos finales de la API REST.
Dentro de la Transferencia de Estado Representacional hay cuatro principios básicos de diseño.
En primer lugar, REST se basa en el protocolo HTTP.
Así 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 completar la comunicación.
Así que cuando un servidor recibe la solicitud, el servidor responde y
después de eso, no recuerda nada más sobre esa conversación
entre el cliente y el servidor.
En tercer lugar, la forma REST de proporcionar recursos es
exponer una estructura de directorio como URL de localizadores de recursos uniformes URL.
Y en cuarto lugar, su formato para el intercambio de datos es típicamente JSON o
XML, o ambos que pueden ser compatibles con REST.
Una de las motivaciones para subir sugiriendo REST como una forma de apoyar servicios web
es que captura todo lo que es bueno de toda la World Wide Web.
Y eso hizo que Word Wide Web fuera un éxito.
El uso de Indicadores Uniformes de Recursos o Localizadores Uniformes de Recursos, URL,
que le permiten dirigir recursos especificándolos como una URL,
el segundo es un protocolo que se desplaza sobre el protocolo HTTP.
HTTP ya ha encontrado una amplia implementación en Internet.
Tercero, el ciclo de respuesta de solicitud por el que HTTP es bien conocido.
Así que usted envía una solicitud, el servidor recibe su solicitud, procesa la solicitud,
envía la respuesta a la solicitud, y ese 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 el protocolo HTTP Web THe en todo el mundo como hemos visto anteriormente,
vamos a utilizar todos los verbos que HTTP proporciona.
Específicamente, la puerta puso post eliminar.
Para poder especificar las operaciones a realizar
en los recursos que se almacenan en el lado del servidor.
Entonces, por ejemplo, si realiza una solicitud HTTP GET, está pidiendo
el servidor para devolver el origen.
Si realiza una solicitud POST, está pidiendo que el servidor cree un nuevo recurso.
Si realiza una solicitud PUT, está pidiendo al servidor que actualice
un recurso existente y si emite una solicitud de eliminación, está pidiendo
el servidor para eliminar el recurso identificado por esa URL en particular.
Además, trata de preservar la idempotencia.
Algunas operaciones cuando se realizan
Incluso repetidamente no causarán ningún cambio de estado.
Otras operaciones, si las haces sucesivamente,
pueden causar un cambio de estado.
Así que debe tener cuidado con qué operaciones se pueden repetir sin
ninguna consecuencia perjudicial.
Y que hay que hacer 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.
sustantivos, específicamente, están llenos de recursos y
estos recursos suelen ser identificados por sus URL y estos son sin restricciones.
Los verbos están restringidos y estas acciones especificadas se deben realizar en los recursos.
Y las presentaciones 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.
Resource es la abstracción clave a la que REST trabaja para que
la información se abstrae en el recurso.
Y el recurso se identifica especificándolo mediante un URI.
Por lo tanto, cualquier información que pueda ser encapsulada y
estar disponible puede ser identificada como un recurso.
Un pedazo de información como ese 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.
Así que cualquier cosa que definas como una información en la que un cliente puede estar
interesado, puede ser identificado como un recurso.
Incluso puede tratar con recursos como colección de recursos
que ese servidor puede enviar hasta ese cliente.
Aquí se ilustra un ejemplo de cómo nombra recursos.
Así que usamos URI para identificar la fuente.
Una lectura rápida de la especificación o las URL aquí
le permitirá comprender fácilmente a qué nos referimos mediante el uso de estas URL.
Así, por ejemplo, algo que termina con platos/,
automáticamente asumes que esto se refiere a una colección de platos.
Como platos/123 por ejemplo,
podría significar el plato número 123, en este caso y así sucesivamente.
Así que es muy fácil decir que puede especificar una colección de recursos, y
ser capaz de identificarlos como una colección, y luego descargarlos como una colección.
O bien, puede identificar un recurso individual, y
decir que desea ese recurso en particular.
Ahora estos recursos se pueden organizar en una jerarquía
esa especificación de este URI.
Así que a medida que atraviesas el camino,
vas de lo más general a lo más específico de ese recurso.
Esta estructura de directorios le permite identificar fácilmente los recursos que
proporciona desde su sitio de servicio.
La segunda parte de la API REST son las palabras.
En particular estamos interesados en los 4 verbos de HTTP para obtener,
poner, publicar y eliminar.
En este caso, estos verbos serán siesta en las acciones que
queremos realizar en el recurso en el lado del servidor.
GetT significaría que desea realizar una operación de lectura en el recurso, lo que significa
que un cliente que envía una solicitud get indica al servidor que desea
obtener esa presentación del origen de datos desde el sitio del servidor al sitio del cliente.
POST significa que desea crear un nuevo recurso y luego lo hará.
Especifique los detalles del recurso en la representación, pero se utiliza para
especificando el recurso.
A continuación, envíe la información al lado del servidor, de modo que
el servidor creará el recurso en su nombre.
Un PUT sería una modificación de recursos, y
eliminar, como era de esperar, es la eliminación de las fuentes.
Así que, como se puede ver los cuatro Verbos obtener, publicar, poner y
delete se asignan a las cuatro operaciones CRUD que puede llevar a cabo
en una base de datos que almacena estos recursos en el lado del servidor.
Las operaciones de lectura, creación, actualización y eliminación.
Elaborando más, HTTP GET es una forma de especificar.
Que desea que la información o su presentación del recurso sea
devuelta al cliente desde el sitio del servidor.
Entonces, cuando emita una solicitud GET a un punto final de API REST.
Usted está pidiendo ya sea una colección de recursos que se presentan por
Uri o un recurso específico que se identifica por el ID de
que los recursos particulares especificados dentro de la URL tal como se ve en este ejemplo,
si 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 posterior, como vimos, se usa para crear el recurso.
Entonces, cuando crea el recurso, el contenido de describir el recurso sería
en forma de una representación JSON o una representación XML, y eso sería
incluido en el cuerpo del mensaje de solicitud que se envía al lado del servidor.
Por lo tanto, una operación posterior espera una representación
del recurso en formato JSON o XML en el cuerpo del mensaje de solicitud.
Y el servidor recibe dicho mensaje de solicitud, el servidor crea ese recurso
en el lado del servidor y luego devuelve una confirmación o
un error para indicar que la creación del recurso falló.
Del mismo modo, puso la operación fácil de usar 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 recurso
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.
operación DELETE como era de esperar elimina el recurso existente.
Ahora, en este caso particular, por supuesto, una operación de eliminación sería porque
si intenta eliminar un recurso y el recurso existe, se eliminará.
Si intenta eliminar un recurso no existente,
no causará ninguna modificación adicional en el lado del servidor Excepto
que el servidor responderá con un error diciendo que el recurso no existe.
Pero sin embargo, es un ejemplo de una operación en este caso.
Del mismo modo, la operación get también funcionará porque no es
haciendo ninguna modificación en el recurso en el sitio del servidor.
Post input, por supuesto, va a modificar el recurso en el lado del servidor.
Necesita crear un nuevo recurso o
modificar el recurso existente en el lado del servidor y, por supuesto, presentaciones de datos del curso.
Como he estado enfatizando, los dos retrocesos comunes para
que representa es JSON XML, la última parte
que debemos enfatizar es que el lado del servidor debe ser completamente apátrida.
Lo que significa que el lado del servidor no realiza un seguimiento del estado del cliente.
Porque, si el servidor necesita realizar un seguimiento del estado del cliente, no será escalable.
Entonces, para una implementación escalable del lado del servidor,
normalmente usa un servidor sin estado en el lado del servidor.
Así que si la solicitud de los clientes enviados al servidor será tratada como
una solicitud independiente, y no reflejará en las solicitudes
anteriores que ya han sido manejadas por el servidor desde el cliente en particular.
Así que es responsabilidad del cliente rastrear su propio estado.
Ya sea en forma de uso de cookies o utilizando una base de datos del sitio cliente.
Lo que significa que es adecuado.
Ahora, este enfoque en el que el cliente realiza un seguimiento de su propio estado es mucho más escalable,
porque su cliente será responsable del seguimiento del suyo propio.
Y aquí es donde la configuración MVC del lado del cliente nos ayuda en este sentido.
Y finalmente aún no hemos terminado con REST, veremos más de
REST en los ejercicios que siguen en esta lección particular.
Y luego también,
veremos más detalles sobre el uso de REST en el resto de este curso.
[MÚSICA]