Presentación sobre el protocolo RESTAPI.

ESTANDARIZANDO
LAWEB
UNIVERSIDADAUTÓNOMADEQUERÉTARO
SISTEMASDISTRIBUIDOS -FACULTADDEINFORMÁTICA

Modelo arquitectónico para el
funcionamiento de la web.
Arquitectura web deseada, identifica,
compara soluciones y evalúa
restricciones.
Desarrollado en 1993 se inicio la
especificación de protocolos web
como HTTP/1.0, HTTP/1.1 y URI.
La web se basaba en notas informales,
tuvo que evolucionar con la aparición
de navegadores como Mosaic.
Optimizar aspectos esenciales de sistemas de
hipertexto para cumplir con los requisitos de
comportamiento y rendimiento de, optimizando
casos comunes de la web.
INTRODUCCIONAREST
La estandarización a través de
organizaciones como el IETF y el W3C,
definiendo estándares como HTTP,
URI y HTML.
Define la conducta para una
aplicación web, interconectadas,
navegación por enlaces y
transiciones de estado.

RESTYURL
URI
Identificadores
Uniformes de Recursos,
Se definieron como
identificadores de
documentos
REST
Redefine el concepto de
recurso URI. Basado en
la intención del autor y
no en el valor al crear la
referencia.
Recursos
En Rest, las
representaciones de
recursos se manipulan
en lugar de los recursos
mismos.
Autonomi
a
Se basa en la autoría
independiente de
hipertexto
interconectado a través
de múltiples dominios de
confianza.

AUTORÍAREMOTA.
La autoría remota a través de la interfaz
uniforme de la web busca la separación entre
la representación que un cliente puede
recuperar y el mecanismo que el servidor
puede utilizar para almacenar, generar o
recuperar el contenido de esa representación.
01.
Asociación de recursos y
representaciones.
02. Obtención de URI de
recursos fuente.
03. Derivación de recursos.
04.
Naturaleza de los
recursos.
05. Ocultamiento de detalles de
implementación
06. Ejemplo: Migración de
servidor.

VINCULACIÓNDE
SEMÁNTICAAURI
La web semántica se trata de enriquecer la información
en la web con metadatos significativos para que las
máquinas puedan comprender y procesar la información
de manera más eficaz.
La arquitectura web consta de restricciones en el
modelo de comunicación entre componentes.
Evita que los componentes asuman algo más allá de
la abstracción de recursos.
Oculta los mecanismos reales a ambos lados de la
interfaz abstracta.

RESTNOCOINCIDE
ENURI
Los desajustes ocurren cuando:
Se hace una implementación de software que viola
las restricciones arquitectónicas ya establecidas.
El software intenta tratar a la Web como un sistema
de archivos distribuido.
Los intentos de reflejar el contenido de un servidor
web como archivos fracasarán porque la interfaz de
recursos no siempre coincide con la semántica de un
sistema de archivos

RESTAPLICADOA
HTTP
REST se utilizó para:
Identificar problemas con las
implementaciones HTTP existentes.
La planificación para la implementación de
nuevas versiones de protocolo.
La separación del análisis de mensajes de la
semántica HTTP.
La distinción entre respuestas autorizadas y
no autorizadas.
Un control detallado de almacenamiento en
caché.

EXTENSIBILIDAD
Uno de los principales objetivos de REST es
respaldar la implementación gradual y
fragmentada de cambios dentro de una
arquitectura ya implementada.
HTTP se modificó para:
Respaldar ese objetivo mediante la
introducción de requisitos de versiones
Reglas para ampliar cada uno de los
elementos de sintaxis del protocolo.

VERSIONESDEPROTOCOLO
La versión HTTP de un mensaje indica las
capacidades del remitente y la compatibilidad
bruta del mensaje.
Las conexiones pueden operar a su mejor nivel de
protocolo, independientemente de limitaciones en
clientes o servidores.
El servidor responde con la versión menor
compatible dentro de la misma versión principal
del mensaje del cliente.

ELEMENTOSDEPROTOCOLO
EXTENSIBLES
Espacios de nombres separados: estos incluye valores
de conjuntos de caracteres, etiquetas de idioma, nombres
de métodos, códigos de estado de respuesta
Extensión de métodos: siempre que se pueda compartir
un conjunto estandarizable de semántica entre el cliente,
el servidor y cualquier intermediario.
Separación de reglas de análisis y semántica: permite
la introducción de nuevos métodos y elementos
Regla de extensibilidad de códigos de estado: regla
general para interpretar nuevos códigos de estado de
respuesta.

MENSAJESAUTODESCRIPTIVOS
ENRESTYHTTP
HTPP temprano (viejito) tenia falta de identificación del
host dentro de las solicitudes.
Falta de distinción sintáctica entre datos de control
de mensajes y metadatos.
Falta de soporte para extensiones obligatorias

MEJORAENLAIDENTIFICACIÓN
DELHOSTENHTTP
Problema Inicial:
1.
HTTP no enviaba el URI completo en las solicitudes.
Suposición errónea: El servidor identificaría su autoridad de
nombres basándose en la IP y el puerto TCP.
Problema crítico con el crecimiento exponencial de la web y
la limitación de direcciones IP.
Solución Implementada:
2.
Inclusión de información del host de la URL de destino en
un campo de encabezado 'Host'.
Aplicación en HTTP/1.0 y obligatorio en HTTP/1.1.
Rechazo de solicitudes sin campo 'Host' en HTTP/1.1.
Impacto:
3.
Posibilidad de alojar miles de sitios web con nombres de
dominio distintos en una sola dirección IP.

CODIFICACIONESEN
CAPASYMETADATOSEN
HTTP
Herencia de MIME:
1.
HTTP adoptó la sintaxis de MIME para describir
metadatos de representación.
MIME incluye solo la etiqueta del tipo de medio más
externo en el campo 'Content-Type'.
Limitaciones y Desafíos:
2.
Dificultad para determinar la naturaleza de
mensajes codificados sin decodificar las capas.
Problema con las primeras extensiones de HTTP
que cambiaban la semántica de 'Content-Type'.

EVOLUCIÓNYMEJORASEN
LASCODIFICACIONESPOR
CAPASDEHTTP
Solución Propuesta:
1.
Tratar 'Content-Type' como el tipo de
medio más externo.
Uso de un nuevo campo para describir
tipos anidados.
Codificación de Transferencia:
2.
Introducción del concepto de
codificación de transferencia, similar a
MIME.
Permite codificar mensajes para su
transferencia sin alterar la semántica
de la representac

INDEPENDENCIASEMÁNTICAEN
ELANÁLISISDEMENSAJESHTTP
01.
Separación del Análisis y la Semántica:
Análisis de mensajes HTTP separado de su significado semántico.
Incluye la búsqueda y agrupación de campos de encabezado.
02.
03.
Beneficios para Intermediarios:
Permite a los intermediarios procesar y reenviar mensajes HTTP
de manera eficiente.
Facilita la rápida transmisión y gestión de mensajes.
Impacto en Extensiones y Análisis:
Las extensiones pueden implementarse sin afectar a los analizadores
existentes.
Mejora la compatibilidad y flexibilidad en la evolución de HTTP.

GESTIÓNDELÍMITES
DETAMAÑOENHTTP
Flexibilidad sobre Límites de Tamaño:
1.
HTTP no especifica límites de tamaño para URI, campos de encabezado, representaciones
o valores de campos.
Evita restricciones innecesarias, permitiendo una mayor adaptabilidad.
Consideraciones Prácticas:
2.
Aunque existen límites prácticos (como la memoria disponible), no se imponen límites
rígidos en el protocolo.
Problemas conocidos con URI largos en clientes web más antiguos, pero abordados en la
especificación sin limitar a todos los servidores.
Códigos de Estado en HTTP/1.1:
3.
Introducción de códigos de estado para elementos del protocolo demasiado largos.
Incluyen: URI demasiado largo, campo de encabezado demasiado largo y cuerpo
demasiado largo.
Limitaciones en la comunicación con dispositivos con recursos limitados, como PDAs.

CONTROLDECACHÉY
TRANSPARENCIA
SEMÁNTICAENHTTP
Equilibrio entre Eficiencia y Transparencia:
1.
REST busca un equilibrio entre eficiencia de bajo retardo y
transparencia semántica en caché.
HTTP permite que las aplicaciones determinen los requisitos de caché.
Importancia de la Descripción Precisa de Datos:
2.
Esencial describir completamente y con precisión los datos
transferidos.
Evita confusiones sobre el contenido real de los datos en las
aplicaciones.
Implementación en HTTP/1.1:
3.
Adición de campos de encabezado para control de caché: Cache-
Control, Age, Etag, Vary.
Estos campos facilitan la gestión detallada y flexible de la caché.

FUNDAMENTOSDE
LANEGOCIACIÓNDE
CONTENIDOENHTTP
Asignación de Recursos:
1.
Relación entre solicitudes y respuestas en HTTP.
Diferentes representaciones para una única solicitud.
Concepto de Negociación de Contenido:
2.
Proceso de selección de contenido más que
negociación.
Determina la representación más adecuada para las
necesidades del cliente.

TIPOSDE
NEGOCIACIÓNDE
CONTENIDOENHTTP
Negociación Preventiva (Controlada por el Servidor):
1.
El servidor selecciona la representación basada en las capacidades del
cliente.
Limitaciones debido a la variabilidad de las necesidades y preferencias
del usuario.
Negociación Reactiva (Impulsada por el Agente):
2.
El servidor proporciona una lista de representaciones disponibles.
El cliente elige la representación más adecuada.
Negociación Transparente:
3.
Intermediarios seleccionan la mejor representación en nombre de
otros agentes.
Uso de la información 'Vary' para evitar confusiones en cachés.

DESAFÍOSYVENTAJAS
ENLANEGOCIACIÓN
DECONTENIDO
Desafíos Comunes:
1.
Dificultad para comunicar las características exactas
de las dimensiones de representación.
Ventajas de la Negociación Reactiva:
2.
Menos carga en cada solicitud.
Mayor contexto para tomar decisiones informadas.
No interfiere con el funcionamiento de las cachés.

CONEXIONES
PERSISTENTES.
En las primeras versiones de HTTP:
Única solicitud/respuesta por conexión.
Simple pero ineficiente debido a costos
de configuración y algoritmo de gestión
en el protocolo TCP.
Propuestas iniciales para combinar
múltiples solicitudes y respuestas.
Problemas con nuevos métodos que
violaban restricciones REST.

CONEXIONES
PERSISTENTES.
¿Cuál fue la solución?
Conexiones persistentes usando mensajes
delimitados por una longitud.
Problemas de compatibilidad con “keep-
alive” en HTTP/1.0
Las conexiones persistentes solo son posibles
después de redefinir mensajes de HTTP como
autoexplicativos e independientes del protocolo
de transporte que estén usando.

CACHÉDEESCRITURA
DIRECTAENHTTP
Desafío de la caché de escritura inversa en
HTTP.
HTTP no permite que una caché almacene el
cuerpo de una solicitud PUT para su
reutilización en una respuesta GET.
Razones:
Los metadatos no pueden generarse en
segundo plano.
No se puede determinar el control de
acceso.

DESVENTAJASRESTEN
HTTP
Nacen las desventajas a partir de los
desajustes arquitectónicos en HTTP. Algunos se
deben a extensiones de terceros fuera del
proceso de estándar. Otros se deben a la
necesidad de mantener la compatibilidad con
componentes de HTTP/1.0 ya implementados.

DIFERENCIACIÓNDE
RESPUESTASNO
AUTORITATIVAS
Dificultad para diferenciar respuestas
autoritativas y no autoritativas.
Importancia para aplicaciones críticas y para
identificar la causa de errores.
HTTP/1.1 introdujo la directiva ‘no-caché’ en
las solicitudes para forzar la comunicación
con el servidor de origen.

DIFERENCIACIÓNDE
RESPUESTASNO
AUTORITATIVAS
Uso constante de ‘no-caché’ afecta el
rendimiento de la caché.
La solución general a este problema fue
marcar respuestas como no autoritativas
cunado no se está llamando al servidor de
origen.

COOKIESENHTTP
"Las cookies en HTTP desempeñan un papel
fundamental en la interacción entre los
navegadores y los servidores web. Son
pequeños elementos de información que se
almacenan en el navegador de un usuario y se
utilizan para diversas finalidades.
01.
Problema de falta de
coherencia en el modelo
REST
02.
Falta de coincidencia entre
el estado de la aplicación y
las cookies al usar la
funcionalidad de historial
del navegador.
03.
Las cookies violan los
principios de la arquitectura
REST y permiten el rastreo
de usuarios entre sitios.

EXTENSIONES
OBLIGATORIAS
Los nombres de campos de encabezado
se pueden extender, solamente si la
información no es esencial para la
comprensión del mensaje.
Las extensiones obligatorias requieren
cambios importantes en el protocolo o
en la semántica de los métodos.
Se esperaba que las extensiones de
nombres de campo obligatorias sean
admitidas en una futura revisión
importante de HTTP.

MEZCLADEMETADATOS
Incapacidad para distinguir sintácticamente
entre metadatos de representación y datos de
control de mensajes, ambos transmitidos
como campos de encabezado.
Limitación en la superposición de metadatos
para realizar comprobaciones de integridad
de mensajes.

MEZCLADEMETADATOS
Anticipar problemas en la implementación de
características como conexiones persistentes
y autenticación por digestión.
Solución propuesta: Agregar el campo de
encabezado "Connection" para identificar
datos de control por conexión que no deben
reenviarse por intermediarios y desarrollar un
algoritmo para el tratamiento canónico de los
resúmenes de campos de encabezado.

SINTAXISMIMEENHTTP
HTTP heredó la sintaxis de mensajes MIME
para mantener la compatibilidad entre
protocolos de internet reutilizando campos
estandarizados.
MIME y HTTP tienen distintos objetivos,
MIME para enviar información coherente
para destinatarios desconocidos, HTTP
para recuperar objetos de manera
eficiente mediante solicitudes separadas.

SINTAXISMIMEENHTTP
La sintaxis MIME es ineficiente para
sistemas que no se basan en un transporte
propenso a perdidas.
En futuras versiones HTTP, es posible que
no sea necesario conservar la sintaxis
MIME, aunque puede que se sigan usando
elementos de protocolo para metadatos de
representación.

COINCIDENCIADE
RESPUESTASCON
SOLICITUDES
Los mensajes HTTP no son auto
explicativos con respecto a la
correspondencia entre respuesta-
solicitud.
Durante las primeras etapas de HTTP, se
basaba en una única solicitud con una
única respuesta por conexión.
El orden de las solicitudes determina el
orden de las respuestas en HTTP.

COINCIDENCIADE
RESPUESTASCON
SOLICITUDES
Aunque HTTP se define como
independiente del protocolo de
transporte, aun usa una comunicación
asíncrona.
Esta extensión sería útil en situaciones de
difusión o multidifusión y podría permitir
al servidor elegir el orden de transmisión
de respuestas, priorizando las respuestas
más pequeñas/significativas.

TRANSFERENCIADE
TECNOLOGIA
Aunque REST tuvo su influencia más directa sobre
la creación de estándares web, la validación de su
uso como modelo de diseño arquitectónico se
produjo mediante la implementación de los
estándares en forma de implementaciones de
nivel comercial.

EXPERIENCIADE
IMPLEMENTACIÓNCON
LIBWWW-PERL
¿Que es LIBWWW-PERL?
Siguiendo el modelo del libwww original desarrollado
por Tim Berners-Lee y el proyecto WWW del CERN,
libwww-perl proporcionó una interfaz uniforme para
realizar solicitudes web e interpretar respuestas web
para aplicaciones cliente escritas en lenguaje Perl
Fue la primera biblioteca de protocolos web
desarrollada independientemente del proyecto original
del CERN, lo que refleja una interpretación más
moderna de la interfaz web que la que estaba presente
en bases de código más antiguas. Esta interfaz se
convirtió en la base para diseñar REST.

COMOFUNCIONA
LIBWWW-PERL
libwww-perl constaba de una única interfaz de
solicitud que utilizaba Perl para cargar dinámicamente
el paquete de protocolo de transporte apropiado
según el esquema del URI solicitado. Por ejemplo,
cuando se le pide que realice una solicitud "GET"
libwww-perl extraerá el esquema de la URL ("http") y
lo usará para construir una llamada. a
wwwhttp'request ( ), utilizando una interfaz común a
todo tipo de recursos (HTTP, FTP, WAIS, archivos
locales, etc.).

EXPERIENCIADE
IMPLEMENTACIÓN
CONAPACHE
El proyecto Apache es un esfuerzo colaborativo de
desarrollo de software destinado a crear una
implementación de software de código abierto, sólida, de
calidad comercial y con todas las funciones de un servidor
HTTP.
Apache se hizo conocido tanto por su comportamiento
robusto en respuesta a las variadas demandas de un
servicio de Internet como por su rigurosa implementación
de los estándares del protocolo HTTP.

IMPLEMENTACIÓNDE
URIYSOFTWARE
COMPATIBLECON
HTTP/1.1
En su momento Microsoft Internet Explorer superó a Netscape
Navigator en la cuota de mercado de navegadores web poco
después de ser el primer navegador importante en
implementar el estándar de cliente HTTP/1.1. Además, muchas
de las extensiones HTTP individuales que se definieron durante
el proceso de estandarización, como el campo de encabezado
Host, ahora han alcanzado una implementación universal.
El estilo arquitectónico REST logró guiar el diseño y la
implementación de la arquitectura web moderna. Hasta la
fecha, no ha habido problemas significativos causados por la
introducción de los nuevos estándares

LECCIONESDE
ARQUITECTURAYLAS
VENTAJASDEUNAAPI
BASADAENRED
Hay una serie de lecciones arquitectónicas generales que se
pueden aprender de la arquitectura web moderna y de los
problemas identificados por REST.
Lo que distingue a la Web moderna de otros middleware es la
forma en que utiliza HTTP como interfaz de programación de
aplicaciones (API) basada en red. Este no fue siempre el caso.
El diseño web inicial hizo uso de un paquete de biblioteca,
CERN libwww , como biblioteca de implementación única para
todos los clientes y servidores. CERN libwww proporcionó una
API basada en biblioteca para crear componentes web
interoperables.

APIBASADAENRED
Una API basada en red es una sintaxis integrada, con
semántica definida, para interacciones de
aplicaciones. Una API basada en red no impone
ninguna restricción al código de la aplicación aparte
de la necesidad de leer/escribir en la red, pero sí
impone restricciones al conjunto de semánticas que
se pueden comunicar de manera efectiva a través de
la interfaz. En el lado positivo, el rendimiento sólo
está limitado por el diseño del protocolo y no por
ninguna implementación particular de ese diseño.

COSASATENEREN
CUENTA
Es importante tener en cuenta que existen varias
capas involucradas en cualquier arquitectura,
incluida la de la Web moderna. Los sistemas como la
Web utilizan una biblioteca API (sockets) para
acceder a varias API basadas en red (por ejemplo,
HTTP y FTP), pero la API del socket en sí está por
debajo de la capa de aplicación. Del mismo modo,
libwww es un cruce interesante porque ha
evolucionado hasta convertirse en una API basada en
biblioteca para acceder a una API basada en red y,
por lo tanto, proporciona código reutilizable sin
asumir que otras aplicaciones de comunicación
también están usando libwww .

HTTPNOESRPC
HTTP no es RPC: Aunque ambos implican peticiones y
respuestas, se diferencian en cómo se manejan estas
peticiones y respuestas.
HTTP vs RPC: Lo que distingue a HTTP de RPC no es la
sintaxis, sino que las peticiones en HTTP se dirigen a
recursos utilizando una interfaz genérica con semántica
estándar que puede ser interpretada por intermediarios casi
tan bien como por las máquinas que originan los servicios.
Por otro lado, los mecanismos RPC se definen en términos
de APIs de lenguaje, no de aplicaciones basadas en red.

HTTPNOESUNPROTOCOLODE
TRANSPORTE
HTTP está diseñado para ser un protocolo de
transferencia, no un protocolo de transporte. Los
mensajes en HTTP reflejan la semántica de la
arquitectura web al realizar acciones sobre recursos
mediante la transferencia y manipulación de
representaciones de esos recursos.
Una verdadera aplicación de HTTP mapea las acciones
del usuario del protocolo a algo que puede expresarse
utilizando la semántica de HTTP. Esto crea una API
basada en la red para servicios que pueden ser
entendidos por agentes e intermediarios sin ningún
conocimiento de la aplicación.

ESTADODELAAPLICACIÓNEN
UNSISTEMABASADOENRED
Modelo REST: REST define un modelo de comportamiento para las
aplicaciones que son en gran medida inmunes a las condiciones de fallo
parcial que acosan a la mayoría de las aplicaciones basadas en red. Sin
embargo, los desarrolladores de aplicaciones pueden introducir
características que violan este modelo, especialmente en lo que respecta a
las restricciones sobre el estado de la aplicación y la interacción sin estado.
Estado indirecto de la aplicación: Tanto en el caso de los marcos como en el
de las cookies, el fallo radicaba en proporcionar un estado indirecto de la
aplicación que no podía ser gestionado o interpretado por el agente de
usuario. Un diseño que colocara esta información dentro de una
representación primaria podría haber logrado las mismas tareas sin violar las
restricciones REST, conduciendo a una mejor interfaz de usuario y a una
menor interferencia con el almacenamiento en caché.

JAVAFRENTEAJAVASCRIPT
Aunque Java es un lenguaje de programación popular y recibió un
gran apoyo de la prensa y críticas favorables de los desarrolladores,
no ha logrado ser ampliamente adoptado para el código bajo
demanda en la Web. Por otro lado, JavaScript, a pesar de las críticas
iniciales, ha visto un aumento constante en su uso desde su
introducción.
JavaScript se adapta mejor al modelo de despliegue de la tecnología
web. Tiene una barrera de entrada más baja y afecta menos a la
visibilidad de las interacciones. Además, provoca menos latencia
percibida por el usuario ya que suele descargarse como parte de la
representación primaria y puede ejecutarse mientras se descarga el
resto de la página HTML.

Presentación sobre el protocolo RESTAPI.

Recomendados

Recomendados

Más contenido relacionado

Similar a Presentación sobre el protocolo RESTAPI.

Similar a Presentación sobre el protocolo RESTAPI. (20)

Último

Último (13)

Presentación sobre el protocolo RESTAPI.