La toute première étape de l'utilisation du Web consiste à envoyer des données à votre application serveur. Et si l'analyse d'une douzaine de petites lignes peut être confiée au framework, qu'en est-il du téléchargement des fichiers?
Prenons l'exemple de PHP, bien que ce qui est décrit soit vrai pour 99% des autres langages et technologies. Supposons que nous voulons permettre à l'utilisateur de télécharger des images sur le site, pour cela, nous créons un formulaire avec un champ de type fichier et ... Extérieurement, tout est très simple, quelques octets dans le formulaire et dans le code ont changé, mais maintenant vous pouvez travailler avec des fichiers au lieu du texte des formulaires! Mais tout n'est pas si simple, votre fichier doit d'abord s'installer quelque part dans / tmp / jusqu'à ce que la demande arrive complètement, votre script ne prend tout simplement pas le contrôle et vous ne pouvez rien y faire. Par exemple, au lieu d'une image, l'utilisateur a téléchargé un fichier exe, mais vous ne le découvrirez qu'une fois le téléchargement terminé. Ainsi, un attaquant peut pendant un certain temps marteler un canal et le temps de votre sous-système de disque, en faisant semblant de charger des fichiers utiles, et vous ne le saurez même pas. Si le serveur de mise en cache est devant le serveur d'applications, la situation est encore pire: par exemple, nginx crée des fichiers temporaires, c'est-à-dire tout d'abord, la demande de l'utilisateur se déposera sur le disque, une fois terminé, le fichier est relu et rapidement remis au serveur d'applications (dans notre cas, php), où il est enregistré sur le disque UNE FOIS DE PLUS. Triple utilisation totale du disque, même si l'utilisateur n'a qu'à afficher le message "vous avez oublié de saisir captcha".
Je ne parle pas du fait que des choses plus amusantes avec cette approche ne peuvent pas être faites. Une fonctionnalité simple comme la «barre de progression de téléchargement de fichier» n'est plus disponible. Pour des exemples plus complexes: Youtube montre des images d'un film qui est toujours en cours de chargement mais pas entièrement chargé. Vous n'aurez aucun contrôle (et même des notifications!) Avant le téléchargement du film entier (2 gigaoctets, par exemple). Vous ne savez même pas que quelqu'un a consommé 1,5 gigaoctet de votre disque, mais vous avez ensuite fermé le navigateur ou cliqué sur le bouton d'actualisation dans le navigateur sans rien attendre.
Bien sûr, il existe différentes béquilles de divers degrés de courbure qui vous permettent de résoudre des tâches typiques, telles que «recevoir des statistiques de demande via json», implémentées en tant que modules de serveurs Web, mais vous devez faire ces choses vous-même et / ou ainsi vous attacher à l'environnement, l'application cesse d'être indépendante et devient dépendant d'applications spécifiques et de leurs bibliothèques.
Cache
Les caches sont vitales. La technique de mise en cache vous permet d'accélérer la réactivité de votre site et de réduire la charge sur celui-ci, éliminant ainsi la nécessité d'effectuer les mêmes opérations pour de nombreuses requêtes. Par exemple, combien ne font pas 2 + 2, il y en aura toujours 4, mais le calcul 2 + 2 prend les ressources du serveur, il est beaucoup plus rentable de calculer cette valeur 1 fois, lorsque le premier visiteur arrive, puis d'écrire quelque part, afin de donner à cet autre utilisateur résultat.
Ne confondez pas cette mise en cache avec les en-têtes http, ils n'ont d'effet que sur un client spécifique (dans l'original également sur les proxys intermédiaires), tandis que la mise en cache sur le serveur est conçue pour donner le même contenu à de nombreux utilisateurs.
Hélas, il n'est pas rentable de donner la mise en cache à un serveur intermédiaire, en cas de moindre mise à jour sur une page, vous devrez créer une page à partir de zéro, et compte tenu des réalités modernes, lorsqu'il y a beaucoup d'éléments dynamiques sur une page, alors en fait chaque page sera unique, et d'autre part, une demande du formulaire GET / somepage.html? someshit = 12345 va percer le cache et une nouvelle page sera formée qui ne prendra même pas en compte ce paramètre, mais néanmoins il y aura des coûts pour sa création, qui peuvent à nouveau être utilisés par un attaquant. Par conséquent, peu de gens utilisent des serveurs de cache intermédiaires et il est déjà très difficile de s'y fier.
Il reste à tout mettre en cache dans l'application, presque chaque framework fournit ses propres béquilles, ainsi que celles prêtes à l'emploi comme toutes sortes de memosheds et autres. En règle générale, les développeurs novices écrivent simplement dans l'eau bouillante lorsqu'ils découvrent que lors de la génération d'une page, vous pouvez faire 500 demandes au memcached et il n'y aura rien pour cela (contrairement au mysql préféré de tout le monde). En conséquence, tout le code est couvert par des wrappers, qui vérifient d'abord le résultat de la demande dans le memcache, puis montent après le résultat dans mysql. Je ne dis pas, un contrôle manuel du cache est nécessaire, mais un contrôle complètement manuel conduit à des erreurs possibles, où vous pouvez simplement oublier d'activer la mise en cache, qui, selon la loi de la méchanceté, sera un endroit critique.
Interfaces
Quelle interface doit avoir le site? Ne dites pas ça vert.
Auparavant, en règle générale, la présentation du site était unique et indivisible. Cependant, sur les grands portails, il y avait des boutons «version imprimée», ou même «version wap», qui a ensuite été remplacé par la «version PDA» - déjà du HTML simple, mais plus simple. Bien que selon où, si vous utilisez Twitter, c'est la seule version lisible de celui-ci. Le temps a passé et il fallait éditer des sites non seulement pour les imprimantes et les téléphones, mais aussi pour toutes sortes d'iPad et de réfrigérateurs avec prise en charge HTML5. Naturellement, tout cela est tombé en amour avec les développeurs, car ils devaient en fait faire 10 versions d'un site chacun, et ils ont décidé de faire quelque chose d'universel. Une sorte d'API pour le site.
Qu'est-ce qu'une API - je ne sais pas. Honnêtement, je ne sais pas. Habituellement, c'est une sorte de merde lorsque vous crachez sur un serveur avec un morceau de chaîne codée en url, et en retour vous obtenez un morceau de texte json / xml / plain, quelle chance cela a. Bien sûr, aucune norme, même des types de données primitifs, ne peut être n'importe quoi, un résultat vide peut également être n'importe quoi, de null à "" (guillemets vides), ou même être absent en conséquence. C'est bien si les auteurs lisent un mot comme REST et se précipitent pour l'implémenter, mais dans le contexte de tout le reste, cela n'a aucun sens. La fonctionnalité n'est pas claire non plus, si en demandant une page HTML nous pouvons tout obtenir en même temps (dernières nouvelles, commentaires, likes, etc.), alors combien de demandes nous devons faire en cas d'une API - seul l'auteur de cette API le sait, c'est tout à fait possible que les commentaires peuvent être reçus, mais les aime - non. En fait, une API est un moyen de diviser le développement client et serveur en équipes de développement complètement différentes qui interagissent mal entre elles. Et on ne peut pas parler de l'utilité de cette API.
Et il arrive souvent que l'accès à l'API nécessite une certaine clé. Les clés peuvent souvent être obtenues gratuitement. Pourquoi ne pas obtenir une telle clé? Le problème est que cela nous conduit à une comptabilité explicite des demandes, à une comptabilité interne. Et qui sait quand l'auteur veut monétiser tout cela? Il est possible qu'après un certain temps les clés gratuites soient désactivées ou sévèrement limitées, offrant d'utiliser un tarif payé. Et parfois en général, l'émission de toutes les clés est suspendue et le service est arrêté, même sur une base commerciale, cela se produit également. Eh bien, pourquoi une API? C’est plus facile pour moi d’étirer la page et de l’analyser avec des habitués que d’endurer une telle honte. Par conséquent, je n'utilise presque jamais celles de vos API, d'autant plus que je ne vais pas m'occuper de leurs fonctionnalités.