PHP 8.4 est sorti en novembre, et vous et votre équipe n'en doutez pas J'ai travaillé dur pour comprendre les nouvelles fonctionnalités, les dépréciations et les changements qui accompagnent cette dernière itération du langage. Ce inclut des modifications apportées aux verbes HTTP non POST.
Dans ce blog, je marche à travers l'arrière-plan des verbes HTTP en PHP, expliquant pourquoi le HTTP les changements de verbes dans PHP 8.4 sont importants. Je fournis ensuite un guide aux développeurs à référencer lors de la mise en œuvre de ces modifications dans leur code.
PHP a été développé en pensant au Web et prend en charge la gestion des formulaires depuis sa version premiers jours. À l'origine, en HTTP, il n'y avait essentiellement que deux méthodes via lesquelles un navigateur pourrait demander une page Web : via GET ou POST. Bien que les formulaires HTML ne prennent encore réellement en charge que ces deux méthodes, JavaScript a la capacité d'envoyer des requêtes HTTP en utilisant n'importe quelle méthode HTTP, et un certain nombre de boîtes à outils (par exemple HTMX) peuvent même gérer cela de manière transparente pour les développeurs.
Une requête GET transmet les données du formulaire via la chaîne de requête de l'URL. Cela signifie que les résultats du formulaire peuvent être ajoutés à vos favoris, répétés et même mis en cache. Pour cette raison, les requêtes GET ne sont généralement utilisées que pour des actions qui demandent un état sans modifier l'état : recherches, résultat tri, filtrage des résultats, pagination, etc.
Si vous souhaitez effectuer une action qui pourrait apporter des modifications au sein d'une application - par exemple, traiter un panier, envoyer un message d'assistance, télécharger un image, etc. — vous utiliserez la méthode HTTP POST. Les requêtes POST sont considérés comme non idempotents, ce qui signifie qu'ils ne peuvent pas être mis en cache et ne doivent pas être répétés, car ils ont des effets secondaires. Ces effets peuvent signifier des insertions, des modifications ou des suppressions dans une base de données, des opérations sur le système de fichiers, des requêtes Web ou autre chose.
Dans Afin d'automatiser la gestion des données de formulaire, PHP propose plusieurs variables superglobales qu'il remplit à partir de la requête entrante. $_GET est renseigné avec des arguments de chaîne de requête URL et peut être renseigné à partir de n'importe quelle méthode de requête. $_POST, cependant, n'est renseigné qu'à partir du corps des requêtes POST effectuées à l'aide du type de contenu application/x-www-form-urlencoded, qui pourrait ressembler à ceci :
title=HTTP Verbs Changes in PHP 8.4&url=https://example.org/blog/php-8.4-http-verbs&author=Just Some Guy&tags[0]=php&tags[1]=http
PHP prenez cela et remplissez le superglobal $_POST de telle sorte qu'il devienne ce qui suit :
<?php $_POST = [ 'title' => 'HTTP Verbs Changes in PHP 8.4', 'url' => 'https://example.org/blog/php-8.4-http-verbs', 'author' => 'Just Some Guy', 'tags' => ['php', 'http'], ];
Le fait que PHP fasse cela en coulisses pour vous, cela fait partie de ce qui rend PHP si facile à apprendre et à démarrer.
De plus, il peut également gérer le type de contenu multipart/form-data, qui permet à un navigateur de télécharger des fichiers en plus de fournir un formulaire. données. Ce faisant, il remplira un $_FILES supplémentaire superglobal, qui fournit des informations sur les fichiers téléchargés ; les développeurs peuvent ensuite valider et prétraiter ces fichiers avant de les stocker dans un emplacement permanent.
Il existe beaucoup plus de méthodes HTTP que GET et POST, et de développeurs pour le web ils voudront souvent choisir différentes méthodes pour fournir un contexte à ce qui ils tentent de faire :
Bien que les navigateurs ne les prennent pas en charge nativement (encore !), de nombreux frameworks et bibliothèques JavaScript le font.
Mais il y a un hic : PHP ne gère pas automatiquement ces requêtes. Dans En fait, vous devez gérer vous-même leur analyse, ce qui peut être extrêmement problématique lorsque vous commencez également à gérer les téléchargements de fichiers comme ainsi que les données de formulaire. (Ne lancez jamais vos propres analyseurs !)
PHP 8.4 introduit la méthode request_parse_body() :
[$_POST, $_FILES] = request_parse_body(?array $options = null);
Le
La fonction analyse la requête entrante de la même manière qu'elle l'a toujours fait.
pour les requêtes POST, mais vous permet de spécifier des variables alternatives à
stocker les données du formulaire et les téléchargements de fichiers (ou écraser les superglobales,
si vous préférez). Vous pouvez également modifier le comportement de l'analyseur via l'argument $options, avec plus d'informations à ce sujet ci-dessous.
Un modèle courant sera probablement :
<?php if (in_array($_SERVER['REQUEST_METHOD'], ['PUT', 'PATCH', 'DELETE'], true)) { [$_POST, $_FILES] = request_parse_body(); }
(Bien que si vous Si vous utilisez un framework, attendez-vous à ce que le framework s'occupe de ce détail pour vous.)
C'est littéralement l'intégralité de la fonctionnalité. Une fonction simple à fournir un comportement clé en main que vous connaissez déjà en tant que développeur PHP. Il Il n'y a pas beaucoup mieux que ça !
Maintenant que nous avons parlé des modifications apportées aux verbes HTTP dans PHP 8.4, parlons jetez un œil à quelques exemples sur la façon dont vous pouvez les utiliser et les appliquer mises à jour dans votre code.
Tout comme les requêtes POST, request_parse_body() analysera uniquement les requêtes avec le contenu suivant types :
Dans le cas d'application/x-www- form-urlencoded, l'équivalent $_FILES Le tableau (index 1 dans le tableau renvoyé) sera vide. Si le contenu type n'est pas pris en charge, la fonction lancera une InvalidArgumentException.
PHP vous permet d'inspecter le contenu brut de la requête via le flux php://input. Il s'agit d'un flux mis en mémoire tampon qui peut être (à partir de PHP 7.4) lu plusieurs fois. Cependant, lors de la réception de données multipart/form contenu, PHP devient un peu destructeur, pour une très bonne raison : la mise en mémoire tampon les fichiers pourraient conduire à ce que le contenu du fichier soit écrit deux fois sur le disque, conduisant à plus de mémoire, de stockage et d'utilisation d'E/S.
En tant que tel, request_parse_body() NE DOIT PAS être appelé deux fois, car il consommerait de manière destructrice php://input.
Le paramètre $options de request_parse_body() vous permet de modifier son comportement au moment de l'exécution, au lieu de vous fier à des éléments codés en dur Configuration php.ini.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!