Como pudiste notar en el tema anterior, en la respuesta de una solicitud web, se involucran distintos archivos.

De hecho, son incluso más de los que tú puedes ver y de los que nosotros como desarrolladores programamos. El flujo que sigue una petición web desde que la recibimos hasta que le damos respuesta es la siguiente.

Primero, vamos a definir una serie de conceptos, la parte final de la URL, a la que usualmente llamamos el path, es un indicador del recurso al que quiere acceder el usuario, por ejemplo, si estamos en codigofacilito.com/cursos /cursos es el recurso que estamos buscando.

Decimos entonces que en codigofacilito.com vamos a pedir un recursos con el identificador cursos.

Esta petición se transporta a través de la red usando una serie de convenciones, o protocolo como lo llamamos, de nombre http. En estas convenciones se define cómo debe de hacerse la solicitud y qué información debemos recibir para poder entregar una respuesta.

Rails recibe la solicitud, y cual proceso refinado de burocracia la hace pasar por muchos departamentos a los que llamaremos middlewares, el concepto de middlewares es un poco complejo por lo que no voy a profundizar mucho en él, solo ten en cuenta que la solicitud va pasado de middleware en middleware, y en cada proceso Rails agrega más información, arregla datos, lee otros y al final, nos hace llegar una petición mucho más robusta, con toda la información que necesitamos para darle respuesta.

En este punto, entran las rutas, misma que definimos en el archivo routes.rb, este archivo recibe la solicitud y se da a la tarea de buscar una ruta que corresponda al recurso solicitado, su trabajo principal es encontrar un controlador para dicha petición.

En las rutas nosotros declaramos qué recurso es manejado por cuál controlador, de manera que una vez que encuentra el controlador definido para la ruta correspondiente, la solicitud pasa hacia el controlador.

En el controlador es donde nosotros tenemos que declarar los pasos para responder a cada solicitud, en algunos casos, la respuesta es solo una página, en otros una imagen, en otros un reporte, etc.

El controlador debe de definir, construir y enviar la respuesta, en nuestro ejemplo anterior simplemente toma la vista, un archivo de HTML, y lo envía de vuelta hacia el navegador.

Luego, la respuesta pasa por otra serie de departamentos o middlewares que la maquillan, transforman, adaptan y dejan lista para volver a ser enviada por la red, siguiendo los protocolos establecidos, en este caso el protocolo http.

Esa respuesta se envía al navegador quien se encarga de mostrar dicha vista.

Y así de simple, es por esto que cada vez que queramos agregar un nuevo recurso, una nueva página, un nuevo reporte, una nueva vista, etc. a nuestra aplicación web, debemos de registrar la ruta con su correspondiente controlador, y definir en el controlador la respuesta que enviaremos.

En muchas ocasiones, el controlador usará información de los modelos para construir la respuesta, pero eso lo veremos más adelante.

Continuemos.