Introducción a las tecnologías Web

Perspectiva histórica de Internet.

Es la red de redes. Es el Sistema mundial de redes de computadoras interconectadas. Fue concebida

a fines de la década de 1960 por el Departamento de Defensa de los Estados Unidos; más
precisamente, por la ARPA.

Se la llamó primero ARPAnet y fue pensada para cumplir funciones de investigación. Su uso se
popularizó a partir de la creación de la World Wide Web. Actualmente es un espacio público
utilizado por millones de personas en todo el mundo como herramienta de comunicación e
información.

Historia de Internet

1957

La Unión Soviética lanza el Sputnik, el primer satélite artificial. En respuesta a este hecho, Estados
Unidos crea el ARPA (Organismo de Proyectos de Investigación Avanzada) dentro del Ministerio de
Defensa a fin de establecer su liderazgo en el área de la ciencia y la tecnología aplicada a las fuerzas
armadas.

1965

El ARPA promueve un estudio sobre “Redes cooperativas de computadoras de tiempo compartido”.

El TX-2 en el laboratorio Lincoln del MIT y el AN/FSQ-32 de la System Development Corporation

quedan vinculadas directamente (sin conmutación por paquetes) por medio de una línea telefónica
dedicada de 1200 bps; más tarde se agrega la computadora de la Digital Equipment Corporation
(DEC) en ARPA y así conforma la red experimental.

1968

Se presenta la red conmutada por paquetes (PS - Network) ante el ARPA.

1969

Se ponen en servicio los nodos a medida que BBN construye cada IMP [Honeywell DDP-516 con
12 K de memoria]; AT&T provee líneas de 50 kpbs

El procesador de mensajes de interfaz (IMP) fue la de conmutación de paquetes nodo utiliza para
interconectar las redes de los participantes a la ARPANET de los años 1960 a 1989. Fue la primera
generación de gateways, que hoy se conocen como routers.

Nodo 1: UCLA - Universidad de Los Ángeles, California. (30 de Agosto)

Función: Centro de evaluación de redes.

Sistema, Sistema operativo:SDS SIGMA 7,

 Nodo 2: Instituto de Investigaciones de Stanford.(SRI) (1 de Octubre)

Centro de Información de Redes (Network Information Center)(NIC)

SDS 940/Genie

Proyecto de Doug Engelbart sobre “Debate sobre el intelecto humano”.

Nodo 3: Universidad de California Santa Bárbara (UCSB) (1 de Noviembre)

Matemática Interactiva de Culler - Fried.

IBM 360/75, OS/MVT

Nodo 4: Universidad de Utah. (Diciembre)

Gráficos.

DEC PDP-10, Tenex

1971

15 nodos (23 hosts): UCLA, SRI, UCSB, Universidad de Utha, BBN, MIT, RAND, SDC, Harvard,
Laboratorio Lincoln, Stanford, UIU©, CWRU, CMU, NASA/Ames.

Ray Tomlinson de BBN inventa un programa de correo electrónico para mandar mensajes en redes
distribuidas. El programa original es producto de otros dos: un programa interno de correo
electrónico (SENDMSG) y un programa experimental de transferencia de archivos (CPYNET).

1972

Ray Tomlinson modifica el programa de correo electrónico para ARPANET donde se transforma en
un éxito. Se elige el signo @ entre los signos de puntuación de la máquina de teletipos Tomlinson
Modelo 33 para representar el “en”.

Larry Roberts crea el primer programa de administración de correo electrónico para listar, leer
selectivamente, guardar, re enviar y responder mensajes.

RFC 318: Especificación Telnet

1980

ARPANET deja de funcionar por completo el 27 de Octubre a raíz de una advertencia de virus
propagada accidentalmente

1983

El servidor de nombres desarrollado en la Universidad de Wisconsin ya no requiere que el usuario

conozca la ruta exacta para acceder a otros sistemas.

Paso de NCP a TCP/IP (1 Enero)

NCP: Protocolos de Control de Red de ARPANET

TCP/IP: Protocolo de Control de Transmisión / Protocolo de Internet

TCP/IP es un modelo de descripción de protocolos de red creado en la década de 1970 por DARPA.
Desaparecen los IMPs Honeywell o Pluribus; los TIPs son reemplazados por TACs

1984

Se introduce el Domain Name System(DNS) (Sistema de nombre de dominio)

1986

Se crea la NSFNET (Con una velocidad principal de 56Kbps).

NSF establece 5 centros de super computadoras para proveer alto poder de proceso.
(JVNC@Princeton, PSC@Pittsburgh, SDSC@UCSD, NCSA@UIUC, Theory Center@Cornell).

Esto permite una explosión de conexiones, especialmente por parte de las universidades.

1990

ARPANET deja de existir.

1991

CERN lanza la World-Wide Web (WWW)creada por Tim Berners - Lee.

1993

La Casa Blanca se conecta en línea ( http://www.whitehouse.gov/):

Presidente Bill Clinton: president@whitehouse.gov

Vicepresidente Al Gore: vice-president@whitehouse.gov

Worms (gusanos) de una nueva clase aparecen en la Red - los Worms WWW (W4) a los que se les
unen los Spiders (arañas) , Wanderers (vagabundos) , Crawlers (orugas) y Snakes (serpientes)…

Mosaic genera un crecimiento asombroso: la WWW crece a una tasa del 341.634% anual para el
flujo de servicio. Gopher crece a una tasa del 997%.

Sun lanza JAVA el 23 de Mayo

Real Audio, una tecnología de audio, permite que los usuarios de la Red reciban el sonido casi en
tiempo real.
WWW supera a ftp-data en Marzo y se transforma en el servicio de mayor flujo en la NSF Net? en
base al conteo de paquetes y en Abril en base al conteo de bytes.

2000

El Controlador de tiempo de los EE. UU. (USNO) y otros pocos servicios de tiempo de todo el
mundo reportan el nuevo año como 19100 el primero de Enero.

Un ataque de rechazo de servicio masivo es lanzado contra importantes sitios web, incluyendo a
Yahoo, Amazon, y eBay a comienzos de Febrero.

El tamaño de la Web estimado por NEC-RI e Inktomi sobrepasa los mil millones de páginas
susceptibles de ser catalogadas.

2011

En cuanto al número de URL´s creadas cada día, esta cifra ha crecido un 21% en los dos últimos
años de 3.7 millones mensuales en 2009 a los 4.5 millones mensuales en el año 2011, con una
media de 150.000 nuevas URL´s al día en Junio.

Protocolo http (protocolo de transferencia de hipertexto).

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo

cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores
HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el RFC 1945. Fue
propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución
de información como el World Wide Web.

Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión
TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX:
un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las
solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP
se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión

con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un
mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las
operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento
HTML, fichero multimedia o aplicación CGI) es conocido por su URL.

Etapas de una transacción HTTP.

Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos:

• Un usuario accede a una URL, seleccionando un enlace de un documento HTML o

introduciéndola directamente en el campo Location del cliente Web.
 • El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el
protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor
por defecto es 80) y el objeto requerido del servidor.

• Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.Se
realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la
dirección del objeto requerido (el contenido de la URL que sigue a la dirección del
servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto
variable de información, que incluye datos sobre las capacidades del browser, datos
opcionales para el servidor,…

• El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato

MIME de la información de retorno, seguido de la propia información.

• Se cierra la conexión TCP.

Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un documento
HTML en cuyo interior están insertadas cuatro imágenes, el proceso anterior se repite cinco veces,
una para el documento HTML y cuatro para las imágenes.

El estándar HTTP/1.0 recoge únicamente tres comandos, que representan las operaciones de
recepción y envío de información y chequeo de estado:

GET: Se utiliza para recoger cualquier tipo de información del servidor. Se utiliza siempre que se
pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP envía
el documento correspondiente a la URL seleccionada, o bien activa un módulo CGI, que generará a
su vez la información de retorno.

HEAD: Solicita información sobre un objeto (fichero): tamaño, tipo, fecha de modificación… Es
utilizado por los gestores de cachés de páginas o los servidores proxy, para conocer cuándo es
necesario actualizar la copia que se mantiene de un fichero.

POST: Sirve para enviar información al servidor, por ejemplo los datos contenidos en un
formulario. El servidor pasará esta información a un proceso encargado de su tratamiento
(generalmente una aplicación CGI). La operación que se realiza con la información proporcionada
depende de la URL utilizada. Se utiliza, sobre todo, en los formularios.

“Un cliente Web selecciona automáticamente los comandos HTTP necesarios para recoger la
información requerida por el usuario. Así, ante la activación de un enlace, siempre se ejecuta una
operación GET para recoger el documento correspondiente. El envío del contenido de un
formulario utiliza GET o POST, en función del atributo de <FORM METHOD="...">. Además, si
el cliente Web tiene un caché de páginas recientemente visitadas, puede utilizar HEAD para
comprobar la última fecha de modificación de un fichero, antes de traer una nueva copia del
mismo.

Posteriormente se han definido algunos comandos adicionales, que sólo están disponibles en
determinadas versiones de servidores HTTP, con motivos eminentemente experimentales. La última
versión de HTTP, denominada 1.1, recoge estas y otras novedades, que se pueden utilizar, por
ejemplo, para editar las páginas de un servidor Web trabajando en remoto”.
Localizador Uniforme de Recursos (URL).

Un localizador uniforme de recursos, más comúnmente denominado URL (sigla en inglés de

uniform resource locator), es una secuencia de caracteres, de acuerdo a un formato modélico y
estándar, que se usa para nombrar recursos en Internet para su localización o identificación, como
por ejemplo documentos textuales, imágenes, vídeos, presentaciones, presentaciones digitales, etc.

Los localizadores uniformes de recursos fueron una innovación fundamental en la historia de la

Internet. Fueron usadas por primera vez por Tim Berners-Lee en 1991, para permitir a los autores de
documentos establecer hiperenlaces en la World Wide Web. Desde 1994, en los estándares de la
Internet, el concepto de URL ha sido incorporado dentro del más general de URI (uniform resource
identifier, en español identificador uniforme de recurso), pero el término URL aún se utiliza
ampliamente.

Aunque nunca fueron mencionadas como tal en ningún estándar, mucha gente cree que las iniciales
URL significan universal resource locator (localizador universal de recursos). Esta interpretación
puede ser debida al hecho de que, aunque la U en URL siempre ha significado "uniforme", la U de
URI significó en un principio "universal", antes de la publicación del RFC 2396.

El URL es la cadena de caracteres con la cual se asigna una dirección única a cada uno de los
recursos de información disponibles en la Internet. Existe un URL único para cada página de cada
uno de los documentos de la World Wide Web, para todos los elementos de Gopher y todos los
grupos de debate USENET, y así sucesivamente.

El URL de un recurso de información es su dirección en Internet, la cual permite que el navegador

la encuentre y la muestre de forma adecuada. Por ello el URL combina el nombre del ordenador que
proporciona la información, el directorio donde se encuentra, el nombre del archivo, y el protocolo
a usar para recuperar los datos.

El formato general de un URL es:

esquema://máquina/directorio/archivo

También pueden añadirse otros datos:

esquema://usuario:contraseña@máquina:puerto/directorio/archivo

Por ejemplo: http://es.Wikipedia.org/

Esquema URL

Un URL se clasifica por su esquema, que generalmente indica el protocolo de red que se usa para
recuperar, a través de la red, la información del recurso identificado. Un URL comienza con el
nombre de su esquema, seguido por dos puntos, seguido por una parte específica del esquema'.

Algunos ejemplos de esquemas URL:

 http - recursos HTTP

 https - HTTP sobre SSL

  ftp - File Transfer Protocol

 mailto - direcciones de correo electrónico

 ldap - búsquedas LDAP Lightweight Directory Access Protocol

 file - recusos disponibles en el sistema local, o en una red local

 news - grupos de noticias Usenet (newsgroup)

 gopher - el protocolo Gopher (ya en desuso)

 telnet - el protocolo telnet

 data - el esquema para insertar pequeños trozos de contenido en los documentos Data: URL

Algunos de los esquemas URL, como los populares "mailto", "http", "ftp", y "file", junto a los de
sintaxis general URL, se detallaron por primera vez en 1994, en el Request for Comments RFC
1630, sustituido un año después por los más específicos RFC 1738 y RFC 1808.

Algunos de los esquemas definidos en el primer RFC aún son válidos, mientras que otros son
debatidos o han sido refinados por estándares posteriores. Mientras tanto, la definición de la sintaxis
general de los URL se ha escindido en dos líneas separadas de especificación de URI: RFC 2396
(1998) y RFC 2732 (1999), ambos ya obsoletos pero todavía ampliamente referidos en las
definiciones de esquemas URL.

El estándar actual es STD 66 / RFC 3986 (2005).

Qué es una aplicación Web.

En la ingeniería de software se denomina aplicación web a aquellas aplicaciones que los usuarios
pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un
navegador. En otras palabras, es una aplicación software que se codifica en un lenguaje soportado
por los navegadores web en la que se confía la ejecución al navegador.

Las aplicaciones web son populares debido a lo práctico del navegador web como cliente ligero, a
la independencia del sistema operativo, así como a la facilidad para actualizar y mantener
aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen
aplicaciones como los webmails, wikis, weblogs, tiendas en línea, que son ejemplos bien conocidos
de aplicaciones web.

Es importante mencionar que una página Web puede contener elementos que permiten una
comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a los
datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones, como por
ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a gestores de base de
datos de todo tipo.
Cliente web. Servidor Web.

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se

reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes,
llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta.
Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque
es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de
computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores,
aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la
gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño
del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se
ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos
específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del
correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica
seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en
diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el
grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución,

tanto a nivel físico como a nivel lógico.

La red cliente-servidor es aquella red de comunicaciones en la que todos los

clientes están conectados a un servidor, en el que se centralizan los diversos
recursos y aplicaciones con que se cuenta; y que los pone a disposición de los
clientes cada vez que estos son solicitados. Esto significa que todas las gestiones
que se realizan se concentran en el servidor, de manera que en él se disponen los

requerimientos provenientes de los clientes que tienen prioridad, los archivos que
son de uso público y los que son de uso restringido, los archivos que son de sólo
lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red
puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta.

Ejemplo:

La mayoría de los servicios de Internet son tipo de cliente-servidor. La acción de visitar un sitio
web requiere una arquitectura cliente-servidor, ya que el servidor web sirve las páginas web al
navegador (al cliente). Al leer este artículo en Wikipedia, la computadora y el navegador web
del usuario serían considerados un cliente; y las computadoras, las bases de datos, y los usos
que componen Wikipedia serían considerados el servidor. Cuando el navegador web del usuario
solicita un artículo particular de Wikipedia, el servidor de Wikipedia recopila toda la
información a mostrar en la base de datos de Wikipedia, la articula en una página web, y la
envía de nuevo al navegador web del cliente.

Otro ejemplo podría ser el funcionamiento de un juego online. Si existen dos servidores de
juego, cuando un usuario lo descarga y lo instala en su computadora pasa a ser un cliente. Si
tres personasj juegan en un solo computador existirían
 dos servidores, un cliente y tres usuarios. Si cada usuario instala el juego en su propio
ordenador existirían dos servidores, tres clientes y tres usuarios.

Transferencia de páginas web.

FTP (siglas en inglés de File Transfer Protocol, 'Protocolo de Transferencia de Archivos') en

informática, es un protocolo de red para la transferencia de archivos entre sistemas conectados a una
red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un
equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle
archivos, independientemente del sistema operativo utilizado en cada equipo.

El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario,
utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado
para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el
intercambio de información, desde el login y password del usuario en el servidor hasta la
transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que
un posible atacante puede capturar este tráfico, acceder al servidor y/o apropiarse de los archivos
transferidos.

Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el
paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico.
Ejemplo del Uso de HTTP

La siguiente conversación es la que por ejemplo tiene lugar cuando quieres acceder a la última tira
cómica publicada por el sitio xkcd:

Figura 1.1 Flujo HTTP para obtener la tira cómica más reciente de Xkcd
Y aunque el lenguaje realmente utilizado es un poco más formal, sigue siendo bastante simple.
HTTP es el término utilizado para describir este lenguaje simple basado en texto. Y no importa
cómo desarrolles en la web, el objetivo de tu servidor siempre es entender las peticiones de texto
simple, y devolver respuestas en texto simple.
Symfony2 está diseñado en base a esa realidad. Aunque a veces no te des cuenta, HTTP es algo que
usas todos los días. Con Symfony2, aprenderás a dominarlo.

Paso 1: El cliente envía una petición

Todas las conversaciones en la web comienzan con una petición. La petición es un mensaje de texto
creado por un cliente (por ejemplo un navegador, una aplicación para el iPhone, etc.) en un formato
especial conocido como HTTP. El cliente envía la petición a un servidor, y luego espera la
respuesta.
Echa un vistazo a la primera parte de la interacción (la petición) entre un navegador y el servidor
web del sitio xkcd:

Figura 1.2 Petición HTTP para obtener la tira cómica más reciente de Xkcd
Utilizando el lenguaje HTTP, esta petición en realidad sería algo parecido a lo siguiente:
GET / HTTP/1.1
Host: xkcd.com
Accept: text/html
User-Agent: Mozilla/5.0 (Macintosh)

Este sencillo mensaje comunica todo lo necesario sobre qué recursos exactamente solicita el cliente.
La primera línea de una petición HTTP es la más importante y contiene dos cosas: la URI y el
método HTTP.
La URI (por ejemplo, /, /contacto, etc.) es la dirección o ubicación que identifica unívocamente
al recurso que solicita el cliente. El método HTTP (por ejemplo, GET) define lo que quieres hacer
con el recurso. Los métodos HTTP son los verbos de la petición y definen las pocas formas en que
puedes actuar sobre el recurso:

Método Acción
GET Recupera el recurso desde el servidor
POST Crea un recurso en el servidor
PUT Actualiza el recurso en el servidor
DELETE Elimina el recurso del servidor

Teniendo esto en cuenta, puedes imaginar cómo sería por ejemplo la petición HTTP necesaria para
borar un artículo específico de un blog:
DELETE /blog/15 HTTP/1.1

Nota En realidad, hay nueve métodos HTTP definidos por la especificación HTTP, pero muchos de
ellos no se utilizan o no están soportados. De hecho, muchos navegadores modernos no soportan los
métodos PUT y DELETE.

Además de la primera línea, una petición HTTP contiene también otras líneas de información
conocidas como cabeceras de petición. Las cabeceras proporcionan mucha información, como el
servidor (o host) solicitado, los formatos de respuesta que acepta el cliente (Accept) y la
aplicación que utiliza el cliente para realizar la petición (User-Agent).

Paso 2: El servidor devuelve una respuesta

Una vez que un servidor ha recibido la petición, sabe exactamente qué recursos necesita el cliente (a
través de la URI) y lo que el cliente quiere hacer con ese recurso (a través del método). Por ejemplo,
en el caso de una petición GET, el servidor prepara el recurso y lo devuelve en una respuesta HTTP.
Considera la respuesta del servidor web del sitio xkcd:
Figura 1.3 Respuesta HTTP para obtener la tira cómica más reciente de Xkcd
Traducida a HTTP, la respuesta enviada de vuelta al navegador es similar a lo siguiente:
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2011 21:05:05 GMT
Server: lighttpd/1.4.19
Content-Type: text/html

<html>
<!-- HTML de la tira cómica de Xkcd -->
</html>

La respuesta HTTP contiene el recurso solicitado (en este caso, el contenido HTML de una página
web), así como otra información acerca de la respuesta. La primera línea es especialmente
importante y contiene el código de estado HTTP (200 en este caso) de la respuesta. El código de
estado indica el resultado global de la petición devuelta al cliente. ¿Tuvo éxito la petición? ¿Hubo
algún error? Existen diferentes códigos de estado que indican éxito, error o qué más se necesita
hacer con el cliente (por ejemplo, redirigirlo a otra página).
Al igual que la petición, una respuesta HTTP contiene datos adicionales conocidos como cabeceras
HTTP. Por ejemplo, una cabecera importante de la respuesta HTTP es Content-Type. Un mismo
recurso se puede devolver en varios formatos diferentes (HTML, XML, JSON, etc.) y la cabecera
Content-Type dice al cliente qué formato se ha utilizado (para ello utiliza valores estándar como
text/html que se conocen como Internet Media Types).

Existen muchas otras cabeceras, algunas de las cuales son muy importantes. Por ejemplo, ciertas
cabeceras se pueden usar para crear un sistema de memoria caché bastante interesante.

Peticiones, respuestas y desarrollo web

Esta conversación petición-respuesta es el proceso fundamental en el que se basa toda la
comunicación en la web. Y a pesar de ser tan importante y poderoso, al mismo tiempo es muy
sencillo.
El concepto más importante es el siguiente: independientemente del lenguaje que utilices, el tipo de
aplicación que construyas (web, móvil, API), o la filosofía de desarrollo que sigas, el objetivo final
de una aplicación siempre es entender cada petición y crear y devolver la respuesta adecuada.