El primer paso para trabajar con la web es enviar datos a la aplicación del servidor. Y si analizar una docena de pequeñas líneas se puede confiar al marco, ¿qué pasa con la descarga de archivos?
Tomemos PHP como ejemplo, aunque lo descrito es cierto para el 99% de otros lenguajes y tecnologías. Supongamos que queremos permitir que el usuario cargue imágenes en el sitio, para esto hacemos un formulario con un campo de archivo de tipo y ... Exteriormente, todo es muy simple, solo unos pocos bytes en el formulario y en el código han cambiado, ¡pero ahora puede trabajar con archivos en lugar de texto de los formularios! Pero no todo es tan simple, su archivo primero debe establecerse en / tmp / hasta que la solicitud llegue por completo, su script simplemente no obtiene el control y no puede hacer nada al respecto. Por ejemplo, en lugar de una imagen, el usuario cargó un archivo exe, pero solo lo descubrirá una vez que se complete la descarga. Por lo tanto, un atacante puede por algún tiempo forzar un canal y el tiempo de su subsistema de disco, pretendiendo cargar archivos útiles, y ni siquiera lo sabrá. Si el servidor de almacenamiento en caché está delante del servidor de aplicaciones, la situación es aún peor: por ejemplo, nginx crea archivos temporales, es decir primero, la solicitud del usuario se asentará en el disco, tan pronto como termine, el archivo se vuelve a leer y se entrega rápidamente al servidor de aplicaciones (en nuestro caso, php), donde se guarda en el disco UNA VEZ MÁS. Uso triple total del disco, incluso si el usuario solo necesita mostrar el mensaje "olvidó ingresar captcha".
No estoy hablando del hecho de que no se pueden hacer cosas más divertidas con este enfoque. Una característica simple como la "barra de progreso de carga de archivos" no está disponible. Para ejemplos más complejos: Youtube muestra fotogramas de una película que todavía se está cargando pero que no está completamente cargada. No obtendrá ningún control (¡ni siquiera notificaciones!) Antes de descargar toda la película (2 gigabytes, por ejemplo). Ni siquiera sabe que alguien ha comido 1,5 gigabytes de su disco, pero luego cerró el navegador o hizo clic en el botón Actualizar en el navegador sin esperar nada.
Por supuesto, hay varias muletas de diversos grados de curvatura que le permiten resolver tareas típicas, como "recibir estadísticas de solicitud a través de json", implementadas como módulos de servidores web, pero debe hacer esas cosas usted mismo y / o por lo tanto, conectarse al entorno, la aplicación deja de ser independiente y se vuelve dependiente de aplicaciones específicas y sus bibliotecas.
Caché
Los cachés son vitales. La técnica de almacenamiento en caché le permite acelerar la capacidad de respuesta de su sitio y reducir la carga, eliminando la necesidad de realizar las mismas operaciones para muchas solicitudes. Por ejemplo, cuántos no hacen 2 + 2, siempre habrá 4, pero calcular 2 + 2 consume recursos del servidor, es mucho más rentable calcular este valor 1 vez, cuando llega el primer visitante, y luego escribir en algún lugar, para entregar a este otro usuario resultado.
No confunda este almacenamiento en caché con encabezados http, tienen un efecto solo en un cliente específico (en el original también en servidores proxy intermedios), mientras que el almacenamiento en caché en el servidor está diseñado para dar el mismo contenido a muchos usuarios.
Por desgracia, no es rentable proporcionar almacenamiento en caché a un servidor intermedio, en el caso de la más mínima actualización en una página, tendrá que crear una página desde cero, y dadas las realidades modernas, cuando haya muchos elementos dinámicos en una página, de hecho, cada página será única y, por otro lado, una solicitud del formulario GET / somepage.html? someshit = 12345 romperá el caché y se formará una nueva página que ni siquiera tendrá en cuenta este parámetro, pero sin embargo habrá costos para su creación, que nuevamente puede ser utilizado por un atacante. Por lo tanto, pocas personas usan servidores de caché intermedios y ya es muy difícil confiar en ellos.
Queda por almacenar en caché todo dentro de la aplicación, casi cada marco proporciona sus propias muletas, así como las listas para usar, como todo tipo de memosheds y cosas por el estilo. Por lo general, los desarrolladores novatos simplemente escriben en agua hirviendo cuando descubren que al generar una página, puede hacer 500 solicitudes a la memoria caché y no habrá nada para ello (a diferencia del mysql favorito de todos). Como resultado, todo el código está cubierto con envoltorios, que primero verifican el resultado de la solicitud en la memoria caché, y luego escalan después del resultado en mysql. No discuto, el control manual de la memoria caché es necesario, pero el control completamente manual conduce a posibles errores, donde simplemente puede olvidarse de activar el almacenamiento en caché, que, según la ley de la maldad, será un lugar crítico.
Interfaces
¿Qué interfaz debe tener el sitio? Eso sí, no digas que verde.
Anteriormente, por regla general, la presentación del sitio era única e indivisible. Sin embargo, en portales grandes había botones "versión impresa", o incluso "versión wap", que luego fue reemplazada por la "versión PDA", que ya es HTML simple, pero más simple. Aunque dependiendo de dónde, si tomas Twitter, esta es la única versión legible. Pasó el tiempo y era necesario editar sitios no solo para impresoras y teléfonos, sino también para todo tipo de iPads y refrigeradores con soporte HTML5. Naturalmente, todo esto se enamoró de los desarrolladores, porque en realidad tenían que hacer 10 versiones de un sitio cada una, y decidieron hacer algo universal. Una especie de API para el sitio.
¿Qué es una API? No lo sé. Honestamente, no lo se. Por lo general, esto es una especie de mierda cuando escupes en un servidor con un trozo de cadena codificada, y a cambio obtienes un trozo de texto json / xml / sin formato, qué suerte tiene. Por supuesto, ningún estándar, incluso los tipos de datos primitivos, pueden ser cualquier cosa, un resultado vacío también puede ser cualquier cosa, desde nulo a "" (comillas vacías), o incluso puede estar ausente como resultado. Es bueno que los autores lean sobre una palabra como REST y se apresuren a implementarla, pero en el contexto de todo lo demás, no tiene sentido. La funcionalidad tampoco está clara, si al solicitar una página HTML podemos obtener todo de una vez (últimas noticias, comentarios, me gusta, etc.), entonces, ¿cuántas solicitudes debemos hacer en caso de una API? Solo el autor de esta API lo sabe, es muy posible que se pueden recibir comentarios, pero que les gustan, no. De hecho, una API es una forma de dividir el desarrollo de clientes y servidores en equipos de desarrollo completamente diferentes que interactúan mal entre sí. Y no se puede hablar de la utilidad de esta API.
Y a menudo sucede que acceder a la API requiere una clave determinada. Las llaves a menudo se pueden obtener de forma gratuita. ¿Por qué no obtener esa llave? El problema es que esto nos lleva a una contabilidad explícita de las solicitudes, a una contabilidad interna. ¿Y quién sabe cuándo el autor quiere monetizar todo esto? Es posible que después de algún tiempo las claves gratuitas se deshabiliten o se limiten severamente, ofreciendo usar una tarifa pagada. Y a veces, en general, la emisión de todas las claves se suspende y el servicio se detiene, incluso a nivel comercial, esto también sucede. Bueno, ¿por qué es una API? Es más fácil para mí estirar la página y analizarla con clientes habituales que soportar tal desgracia. Por lo tanto, casi nunca uso estas API, especialmente porque no voy a tratar sus características.