¿Cómo y por qué evolucionaron los marcos de las aplicaciones web modernas para desacoplar las rutas URL del sistema de archivos?

En su forma más básica, un sitio web sirve archivos estáticos. Asignar la ruta URL a una ruta de archivo es la opción más obvia; Básicamente, es un sitio FTP de solo lectura.

Luego la gente quería cambiar el contenido de la página con algunas secuencias de comandos. La forma más sencilla es incrustar un lenguaje de scripting en la página y ejecutarlo a través de un intérprete. De nuevo, dada la ruta ya existente - > enrutamiento de la ruta del archivo, esto era lo suficientemente simple.

Pero realmente, está ejecutando ese archivo como un argumento para el intérprete ahora. Debe identificar cuándo la solicitud es para un archivo estático y cuándo es algo que necesita interpretar.

Una vez que comienzas a usar idiomas compilados más avanzados, estás aún más divorciado de la ubicación del archivo.

Además, su servidor web ya está almacenando en caché archivos estáticos y haciendo todo tipo de optimizaciones, lo que significa que golpear el sistema de archivos es la excepción y no la regla. En este punto, la antigua ruta del sistema de archivos de enlace es más un obstáculo que una ayuda.

Pero creo que el verdadero cambio radical se produjo cuando los usuarios querían deshacerse de la extensión de archivo de la ruta. Obtener myPage.asp o myPage.php fue algo que confundió a las personas "normales" e interfirió con el SEO.

Debido a que el usuario ve el camino, se ha convertido en parte de la interfaz de usuario de la web y, como tal, debe estar completamente libre de cualquier limitación técnica. Hemos perdido el 'www' y prácticamente todo es un '.com'. Múltiples URL apuntarán a la misma página.

Si gano más dinero con mydomain.com/sale vs www.mydomain.co.uk/products/sale.aspx, entonces no quiero que ninguna limitación técnica se interponga en mi camino.

Puede consultar un documento técnico de Roy Fielding en Transferencia de estado representativa (REST) en cuanto a cuándo y por qué . El primer marco que tenía conocimiento de que hacía la distinción entre un recurso y un archivo era Ruby on Rails, introduciendo el concepto de URL para el enrutamiento de código.

Los conceptos principales detrás de REST que fueron transformacionales fueron:

• Una URL representa un recurso
• Ese recurso puede tener múltiples representaciones
• La URL no debe romperse si la aplicación se reestructura
• Las aplicaciones deben abarcar la apatridia de la web

El principal inconveniente de que la URL sirva los archivos directamente es que experimenta los siguientes problemas:

• Los enlaces de recursos se rompen constantemente a medida que se reorganizan los sitios web
• El recurso y la representación están vinculados

Creo que también es importante proporcionar un equilibrio justo:

• No todos los recursos son iguales en importancia. Es por eso que todavía tiene recursos basados en estilos directamente (CSS, JavaScript / EcmaScript, imágenes)
• Hay mejoras en REST como HATEOAS que mejor admiten aplicaciones de una sola página.

No creo que sea un artefacto de los marcos de aplicaciones web modernas , es principalmente un artefacto de servicio dinámico de páginas en general.

En los viejos días había en su mayoría páginas web estáticas, donde un software servía archivos individuales del sistema de archivos por su ruta. Lo hicieron principalmente porque la opción obvia era la asignación 1: 1 de las rutas URL a las rutas del sistema de archivos (con un directorio designado como raíz web), aunque la reescritura de URL (por ejemplo, para hacer redirecciones después de mover archivos) también era común. / p>

Luego llegó la edad de servir contenido dinámico. Los scripts CGI (y todo lo que evolucionó de ellos) crearon las páginas sobre la marcha, respaldadas por una base de datos de algún tipo. Los parámetros GET en la URL se volvieron comunes, por ejemplo, en.wikipedia.org/w/index.php? title = Path_ (informática) .

Sin embargo, es más fácil para el usuario tener una URL legible que consiste solo en segmentos de ruta. Así que las aplicaciones dinámicas trazaron rutas simples (por ejemplo, es.wikipedia.org/wiki/Path_(computing) ) a los parámetros, y estas asignaciones se conocen como "rutas".

Tal vez este enfoque se sienta más reciente a medida que ganó popularidad cuando la importancia de la usabilidad se reconoció más ampliamente y también se convirtió en parte de SEO. Esta es probablemente la razón por la que se integró directamente en los grandes marcos web.

Una de las razones es que la carga de un archivo desde el disco en cada solicitud es lenta, por lo que los servidores web comenzaron a crear formas de almacenar en la memoria caché los archivos, luego, si va a intentar mantenerlo en la memoria, ¿por qué importa dónde? estaba en el disco?

Una razón es que muchos marcos web están escritos en lenguajes compilados, por lo que ni siquiera tiene una estructura de archivos en el disco, solo un archivo jar o lo que sea. Los idiomas interpretados tomaron prestadas las ideas que les gustaron de los compilados.

Una razón es el deseo de más rutas semánticas y dinámicas, como https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes . Obviamente, no quieres un archivo /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.php . Solía hacer reglas de reescritura de URL en la configuración del servidor web para crear rutas como esta. Ahora es solo un cambio de código, que es mucho más simple operativamente.

Una de las principales razones es probable que este enfoque de mapear URIs a rutas de archivos haya dado lugar a un gran número de liberaciones accidentales de datos a través de File Path Traversal

Cuando asigna la ruta al sistema de archivos, significa que luego debe verificar que cada ruta que recibe como solicitud se asigna a archivos que deberían ser accesibles a los clientes. Un enfoque simple para garantizar que no ocurra es eliminar el mapeo transparente y hacerlo de manera más explícita.

Esto no es un problema solo de PHP. Como evidencia aquí hay una sección relevante de una guía de endurecimiento de Apache .

No puedo responder por la industria, pero puedo decirte por qué me mudé del sistema de archivos URL = a principios de los 2000 hacia las 'rutas' virtuales.

Trabajando con PHP 'de la vieja escuela', si tienes 1000 páginas PHP, tendrías 1000 archivos PHP que representan esas páginas. Cada encabezado / pie de página duplicado incluye y posiblemente alguna otra lógica. Ahora digamos que necesitas cambiar eso. ¡Qué desastre tienes ahora en tus manos! Tienes que cambiar los 1000 archivos o terminar con un montón de código muy feo en el encabezado / pie de página para manejar todos los casos. Usando rutas virtuales, la lógica de encabezado / pie de página, la lógica de conexión de la base de datos y otra inicialización se incluyen una vez , punto. Mucho mejor para trabajar.

Otra razón es evitar la ambigüedad. A medida que crecen las aplicaciones, los encabezados / pies de página que se incluyen se vuelven más complejos. Por lo general, tenían anidaciones incluidas que dependían de varias cosas. En el archivo PHP para la 'página', a menudo se encontró con la ambigüedad acerca de si una variable es isset () o no. Al usar rutas virtuales y una aplicación donde todo lo que necesita se carga en cada carga de página, ya no tiene esa preocupación.

Por último (aunque hay otras razones, pero es la última que enumeraré), muchas de esas 1000 páginas representan códigos que se duplicarían. Entonces, después de refactorizar en un conjunto adecuado de clases y plantillas, el código se simplifica enormemente y puedes hacer todo lo que quieras sin tener esos 1000 archivos.

No voy a entrar en demasiados detalles sobre por qué esta separación es beneficiosa. El argumento principal es que separa la semántica (a qué intenta acceder) de la implementación subyacente.

Teniendo en cuenta que los beneficios superan los costos como un hecho, lo que sería una pregunta aparte, no es difícil ver por qué se adoptó gradualmente. No creo que haya un solo evento que haya causado esto, aunque ciertamente estaría abierto a ser educado sobre esto.

Al menos en mi experiencia, inicialmente esto a menudo se hacía a través de la configuración de Apache, y presumiblemente otros servidores web también lo soportaban. Sin embargo, conceptualmente no hay una buena razón para que el servidor deba encargarse de esto. Después de todo, las rutas son específicas de la aplicación real, por lo que tiene sentido definirlas allí.

Esto cambió globalmente, pero a medida que lo señala, gradualmente. La razón de esto es casi ciertamente muy simple: las buenas ideas se difunden a lo largo del tiempo. Esta es la razón por la que no es tan sorprendente que el cambio haya ocurrido a nivel mundial. No es que todos se reunieron y decidieron hacerlo de esta manera. Más bien, todos los proyectos adaptaron este enfoque cuando pensaron que sería beneficioso (y los proyectos que no lo apoyaron finalmente desaparecieron).

Los RFC ya construyeron los conceptos desde cero, con URI (que no adjuntaban ninguna semántica a la parte local) y las URL como un caso especial que introdujo una semántica parecida a una ruta para permitir que los documentos HTML usen enlaces relativos a la URL base de documentos.

La implementación obvia es mapear la parte local de la URL directamente al sistema de archivos, así que esto es lo que hicieron las configuraciones simples, ya sea que use una base de datos relacional dedicada para buscar un documento, o aproveche la baja optimizada. -el almacén de valor-clave que tiene ya no importa al exterior, pero ciertamente afecta su estructura de costos para la entrega de los documentos.

Si tiene una aplicación web con datos persistentes, esa estructura de costos cambia: siempre tiene la sobrecarga de ejecutar la aplicación y la integración de la decodificación de URL hace que sea más fácil implementar muchas funciones, lo que reduce los costos.

Al principio de los tiempos, las URL se asignaron directamente a las rutas de los archivos en el servidor porque es fácil, y no hay otra forma de hacerlo, ¿verdad? Si solicito /path/to/index.php , obtendré /path/to/index.php a partir del directorio raíz del sitio web (por lo general, no del servidor en sí, el sitio web debe mantenerse en un directorio o un subdirectorio más abajo).

Luego, después de un par de años, comenzamos a aprender sobre la reescritura, que está sirviendo a un recurso diferente al que aparentemente se solicitó. /request/path/to/index.php puede servir realmente /response/path/to/index.php .

Otro truco es esconder index.php . Si pido /index.php?foo=bar&baz=qux , el servidor puede responder ocultando index.php así: /?foo=bar&baz=qux , mientras que al mismo tiempo sirvo index.php de todos modos.

El siguiente paso, que es el más importante, es que aprendimos a redireccionar todas las URL a /index.php . Así que ahora, /path/to/some/page se redirige silenciosamente a /index.php?path/to/some/page . Esto es un poco complicado, porque normalmente cada barra representa un nuevo subdirectorio, pero en este caso el servidor web está configurado para enviar la ruta como un parámetro, en lugar de buscarlo.

Ahora que tenemos esto, necesitamos una forma de pensar completamente diferente acerca de cómo está organizado el sitio web. Antes, era una colección suelta de diferentes páginas. Ahora, todo se enruta a través de una sola página de entrada. Esto hace que el sitio sea mucho más complicado, pero brinda oportunidades que antes no estaban disponibles, como la autenticación de usuarios en todo el sitio, la aplicación uniforme de encabezados, pies de página y estilos, etc.

Convierte de manera efectiva sus cientos o miles de sitios web de aplicaciones (si considera que cada archivo es su propia aplicación) en una aplicación única, mucho más complicada pero mucho más consistente.

Este es un gran salto, ya que ya no se puede saber qué código se ejecutará simplemente mirando la URL. Ahora debe tener una comprensión profunda de cómo su marco particular traduce las rutas URL en rutas de código, y aunque existen similitudes entre marcos, la mayoría son lo suficientemente diferentes como para que necesite cierta familiaridad para poder trabajar con el código.

En pocas palabras, fue una evolución gradual del descubrimiento, no un salto repentino, y cada desarrollador tuvo que pasar por el mismo viaje de descubrimiento. La curva de aprendizaje es bastante pronunciada, a menos que pueda captar conceptos abstractos muy rápidamente.

Como un webdev de larga data, creo que el advenimiento de control de historial sin navegación ( history.pushState() ) en la época de HTML5 hizo esto práctico. Antes de eso, tenías que volver a cargar la página para actualizar la barra de URL, a menos que solo actualizaras el fragmento ( /path#fragment ). Este fragmento era invisible para el servidor (no está enrutado), por lo que la única forma de actualizar o marcar una página dinámica era a través de JavaScript.

Esto tiene implicaciones importantes para SEO, y llevó a Google a desarrollar "hashbang" esquema que requería una asignación del lado del servidor de hashes dinámicos a URL físicas. Esto fue difícil de manejar y no universal entre los robots, liderando el (falso) axioma: "las arañas no pueden rastrear el contenido de ajax". Pero los beneficios del contenido ajax son tangibles: intente utilizar google maps w / o JS por ejemplo.

La solución fue una forma de actualizar la barra de URL con un valor que se puede reflejar en el servidor (permitiendo que los marcadores se actualicen sin JS), SIN volver a cargar la página. Una vez que esta capacidad estuviera disponible, los desarrolladores podían "navegar" por un sitio simplemente actualizando una "sección de contenido principal", barra de URL y rutas de navegación. Esto significó que todo el JS + CSS no necesitó ser revisado + analizado, lo que permite una transferencia MUCHO más rápida de página a página.