Maison > Article > développement back-end > Le côté serveur PHP utilise l'analyse du principe de l'API
Cette fois je vais vous apporter une analyse des principes d'utilisation des API côté serveur PHP Quelles sont les précautions pour utiliser les API côté serveur PHP Voici des cas pratiques, prenons un exemple ? regarder.
Je crois que tout le monde a déjà utilisé l'interface API de requête PHP pour obtenir des données, telles que l'API Taobao, la plateforme publique WeChat, la requête météo, la requête express, etc. Certains d'entre eux doivent se référer au document d'interface pour construire un signe selon l'algorithme de signature, ou définissez le jeton, puis envoyez-le via curl. La demande POST apporte des paramètres pour obtenir les données de retour, généralement au format json ou xml.
Mais maintenant, la situation est inversée. Nous devons développer une interface API côté serveur PHP, c'est-à-dire que lorsque d'autres nous le demandent, nous vérifions la légitimité de la demande et renvoyons les données de la requête.
Cette situation est en fait utilisée dans le développement d'applications mobiles. Les applications d'applications mobiles doivent souvent demander l'interface PHP pour obtenir des données. Cependant, cette demande n'a généralement pas besoin d'être vérifiée. Différentes URL sont demandées en fonction de différentes fonctions. dans la méthode get pour obtenir directement les données.
Cet article parle brièvement de la méthode côté serveur de vérification de la légitimité de la demande et de la méthode de réception des paramètres.
Demande d'obtention simplePar exemple : http://www.demo.com/api/get_cat?id=2, demander cette URL renverra certaines données, peu importe qui utilise quoiLangage de programmation Les requêtes peuvent obtenir des données.
Cela n’est donc évidemment pas possible lorsqu’il faut vérifier la légalité. Par conséquent, une clé secrète est nécessaire. À l’heure actuelle, POST est souvent utilisé pour demander l’URL.
Par exemple, il y a un signe de signature dans le paramètre passé et la valeur est 98888. Bien sûr, il existe de nombreuses façons de générer le signe et cela ne peut pas être aussi simple. Je l'écris simplement ici, puis le serveur reçoit le signe. comme 98888. Si nous convenons que 98888 est légal, vous pouvez à ce moment vérifier qu'il s'agit d'une demande légitime en jugeant si le signe est 98888.
Mais c'est trop simple, il sera fissuré d'un coup, et mettre ce signe n'aura aucun sens. Par conséquent, il doit y avoir une règle pour générer le signe. Lors de la demande, le paramètre sign est généré selon cette règle. Lorsque le serveur le reçoit, il génère également le signe selon cette règle. Si les signes générés sont cohérents, il l'indique. est une demande légale. Chaque demande sera accompagnée d'un signe de vérification.
Il existe un autre type de vérification appelé jeton. Le jeton est vérifié lors de la première demande. Il n'est pas nécessaire de le vérifier à nouveau dans un certain délai. Cela nécessite deux étapes. La première étape consiste à demander à l'interface d'obtenir le jeton pour obtenir le jeton. La deuxième étape consiste à demander la fonction de l'interface spécifique, et vous devez apporter le jeton pour transmettre les paramètres. Étant donné que le serveur stocke d'abord le jeton lors de sa première demande, puis le renvoie, les requêtes ultérieures peuvent vérifier si le jeton transmis existe.
De nombreux développeurs d'interfaces utilisent les deux méthodes pour garantir la confidentialité et la sécurité.
Un autre point est que le module CURL de PHP est souvent utilisé pour envoyer des requêtes POST. Par exemple, l'autre partie envoie une requête POST via curl, curl_setopt($ch,). CURLOPT_POSTFIELDS, $post_string), voici $post_string préférable à transmettre dans un tableau PHP, ou au format json ?
S'il s'agit d'un tableau PHP, j'obtiens les paramètres directement avec $_POST['xx']. S'il s'agit d'un format json, il me semble utiliser file_get_contents('php://input', 'r ') Obtenez les données json transmises, puis analysez le json pour obtenir les paramètres.
Quand faut-il utiliser la deuxième option ?
Cette question a déjà été posée en ligne, voyons comment tout le monde a répondu :
Pour PHP, la différence entre JSON et array est parfois juste une ligne de code. Si j'écris, je peux simplement utiliser la première.
Je pense que si vous voulez que votre code soit plus concis, vous pouvez utiliser le second. Je me souviens que le SDK php de Weixin semble être similaire au second (bien sûr, il est au format XML)
De plus, si l'autre partie utilise Orienté objet pour sérialiser directement json, l'utilisation de json rendra son code plus concis.
La première méthode, consiste à transmettre le protocole POST du formulaire. PHP convertira le tableau PHP au format de formulaire HTTP, qui est universel dans toutes les langues, mais ce n'est pas une API grand public. . protocole, mais plutôt comme une simulation de soumission de formulaire.
La plupart des protocoles API utilisent JSON POST La deuxième méthode consiste à mettre les données JSON dans le corps HTTP. Également multilingue, mais plus convivial en tant qu'API. La première méthode consiste à utiliser PHP curl directement. Si le contenu des données n'est pas bien traité et qu'un contenu tel que @/xxx/xxx est passé dans la valeur du tableau, curl transférera le fichier local sur le serveur, alors soyez prudent.
x-www-form-urlencoded est une norme RFC, il n'y a rien d'incompatible, ce n'est pas seulement multilingue, mais aussi à travers le temps et l'espace. JSON a été développé ces dernières années. Ce n’est pas un standard, c’est juste pour plus de commodité.
Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture recommandée :
Guide du débutant d'AnacondaAnalyse de la configuration de l'environnement PythonCe 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!