Share
Le protocole HTTP (Hypertext Transfer Protocol) est la vie du Web. Il est utilisé chaque fois que vous transférez un document ou effectuez une AJAX demande. Mais étonnamment, HTTP est relativement inconnu chez certains développeurs web..
Cette introduction expliquera comment l'ensemble de principes de conception, appelé REST, sous-tend HTTP et vous permet d'exploiter toute sa puissance en construisant des interfaces pouvant être utilisées à partir de presque tous les périphériques et systèmes d'exploitation..
Envato Market propose également des milliers de scripts de code, de plug-ins et d'applications utiles pour le développement Web, tels que HTTP Assistant, une application qui vous permet de tester les services Web en ligne..
L'application Assistant HTTP sur le marché Envato Tutoriel republié Toutes les quelques semaines, nous revoyons certaines des publications favorites de nos lecteurs au cours de l'histoire du site. Ce tutoriel a été publié pour la première fois en novembre 2010.
REST est un moyen simple d'organiser les interactions entre systèmes indépendants.
REST est un moyen simple d'organiser les interactions entre des systèmes indépendants. Sa popularité augmente depuis 2005 et inspire la conception de services tels que l'API Twitter. Cela est dû au fait que REST vous permet d’interagir avec un minimum de temps système avec des clients aussi divers que les téléphones mobiles et d’autres sites Web. En théorie, REST n'est pas lié au Web, mais il est presque toujours implémenté en tant que tel et s'inspire de HTTP. REST peut donc être utilisé partout où HTTP peut être utilisé..
L’alternative est de construire des conventions relativement complexes au-dessus de HTTP. Cela prend souvent la forme de nouveaux langages basés sur XML. L’exemple le plus illustre est SOAP. Vous devez apprendre un ensemble de conventions complètement nouveau, mais vous ne devez jamais utiliser HTTP à fond. Parce que REST a été inspiré par HTTP et exploite pleinement ses atouts, c’est le meilleur moyen d’apprendre le fonctionnement de HTTP..
Après un premier aperçu, nous examinerons chacun des blocs de construction HTTP: URL, verbes HTTP et codes de réponse. Nous verrons également comment les utiliser de manière RESTful. En cours de route, nous illustrerons la théorie à l'aide d'un exemple d'application simulant le processus de suivi des données relatives aux clients d'une entreprise via une interface Web..
HTTP est le protocole qui permet l'envoi de documents sur le Web..
HTTP est le protocole qui permet d’envoyer des documents sur le Web. Un protocole est un ensemble de règles qui détermine quels messages peuvent être échangés et quels messages sont des réponses appropriées aux autres. POP3 est un autre protocole courant, que vous pouvez utiliser pour récupérer des emails sur votre disque dur..
Dans HTTP, il existe deux rôles différents: serveur et client. En général, le client initie toujours la conversation. le serveur répond. HTTP est basé sur le texte; c'est-à-dire que les messages sont essentiellement des bits de texte, bien que le corps du message puisse également contenir d'autres médias. L'utilisation de texte facilite la surveillance d'un échange HTTP.
Les messages HTTP sont constitués d'un en-tête et d'un corps. Le corps peut souvent rester vide; il contient des données que vous souhaitez transmettre sur le réseau, afin de les utiliser conformément aux instructions de l'en-tête. L'en-tête contient des métadonnées, telles que des informations de codage; mais, dans le cas d'une requête, il contient également les méthodes HTTP importantes. Dans le style REST, vous constaterez que les données d’en-tête sont souvent plus importantes que le corps..
Si vous utilisez les outils de développement Chrome ou Firefox avec l’extension Firebug installée, cliquez sur le bouton Net panneau, et réglez-le sur activée. Vous aurez alors la possibilité d'afficher les détails des demandes HTTP pendant que vous surfez. Par exemple:
Un autre moyen utile de vous familiariser avec HTTP consiste à utiliser un client dédié, tel que cURL..
cURL est un outil de ligne de commande disponible sur tous les principaux systèmes d'exploitation..
Une fois que vous avez installé cURL, tapez:
curl -v google.com
Ceci affichera la conversation HTTP complète. Les demandes sont précédées de >, tandis que les réponses sont précédées de <.
Les URL sont la façon dont vous identifiez les choses que vous souhaitez utiliser. Nous disons que chaque URL identifie une ressource. Ce sont exactement les mêmes URL que celles affectées aux pages Web. En fait, une page Web est un type de ressource. Prenons un exemple plus exotique et considérons notre exemple d'application, qui gère la liste des clients d'une entreprise:
/ clients
identifiera tous les clients, tout en
/ clients / jim
identifiera le client, nommé 'Jim', en supposant qu'il est le seul à porter ce nom.
Dans ces exemples, nous n'incluons généralement pas le nom d'hôte dans l'URL, car il n'est pas pertinent du point de vue de la manière dont l'interface est organisée. Néanmoins, le nom d'hôte est important pour garantir que l'identificateur de ressource est unique sur le Web. Nous disons souvent que vous envoyez la demande pour une ressource à un hôte. L'hôte est inclus dans l'en-tête séparément du chemin de la ressource, qui se trouve juste au-dessus de l'en-tête de la requête:
GET / clients / jim HTTP / 1.1 Hôte: exemple.com
Les ressources sont mieux considérées comme des noms. Par exemple, ce qui suit n'est pas RESTful:
/ clients / ajouter
En effet, il utilise une URL pour décrire une action. C’est un point assez fondamental pour distinguer les systèmes RESTful des systèmes non RESTful.
Enfin, les URL doivent être aussi précises que nécessaire. tout ce qui est nécessaire pour identifier de manière unique une ressource doit se trouver dans l'URL. Vous ne devriez pas avoir besoin d'inclure les données identifiant la ressource dans la demande. De cette façon, les URL agissent comme une carte complète de toutes les données traitées par votre application..
Mais comment spécifiez-vous une action? Par exemple, comment dites-vous que vous souhaitez créer un nouvel enregistrement client au lieu de le récupérer? C’est là que les verbes HTTP entrent en jeu.
Chaque demande spécifie un verbe ou une méthode HTTP spécifique dans l'en-tête de la demande. C'est le premier mot tout en majuscule dans l'en-tête de la demande. Par exemple,
GET / HTTP / 1.1
signifie que la méthode GET est utilisée, alors que
DELETE / clients / anne HTTP / 1.1
signifie le EFFACER la méthode est utilisée.
Les verbes HTTP indiquent au serveur quoi faire avec les données identifiées par l'URL.
Les verbes HTTP indiquent au serveur quoi faire avec les données identifiées par l'URL. La demande peut éventuellement contenir des informations supplémentaires dans son corps, qui peuvent être nécessaires pour effectuer l'opération, par exemple les données que vous souhaitez stocker avec la ressource. Vous pouvez fournir ces données en cURL avec le -ré option.
Si vous avez déjà créé des formulaires HTML, vous serez familiarisé avec deux des principaux verbes HTTP: OBTENIR et POSTER. Mais il y a beaucoup plus de verbes HTTP disponibles. Les plus importants pour la construction d’une API RESTful sont OBTENIR, POSTER, METTRE et EFFACER. D'autres méthodes sont disponibles, telles que TÊTE et OPTIONS, mais elles sont plus rares (si vous voulez en savoir plus sur toutes les autres méthodes HTTP, la source officielle est IETF).
OBTENIR est le type le plus simple de la méthode de requête HTTP; celui que les navigateurs utilisent chaque fois que vous cliquez sur un lien ou tapez une URL dans la barre d'adresse. Il indique au serveur de transmettre les données identifiées par l'URL au client. Les données ne doivent jamais être modifiées côté serveur à la suite d'une OBTENIR demande. En ce sens, un OBTENIR la requête est en lecture seule, mais bien sûr, une fois que le client reçoit les données, il est libre de faire toute opération avec elle de son propre côté - par exemple, formatez-le pour affichage..
UNE METTRE La requête est utilisée lorsque vous souhaitez créer ou mettre à jour la ressource identifiée par l'URL. Par exemple,
PUT / clients / robin
pourrait créer un client, appelé Robin sur le serveur. Vous remarquerez que DU REPOS est complètement agnostique en arrière-plan; rien dans la requête n'informe le serveur de la manière dont les données doivent être créées, mais seulement de la manière dont elles le devraient. Cela vous permet d’échanger facilement la technologie d’arrière-plan si le besoin s’en faisait sentir.. METTRE les demandes contiennent les données à utiliser pour mettre à jour ou créer la ressource dans le corps. Dans cURL, vous pouvez ajouter des données à la demande avec le -ré commutateur.
curl -v -X PUT -d "du texte"
EFFACER devrait effectuer le contraire de METTRE; il doit être utilisé lorsque vous souhaitez supprimer la ressource identifiée par l'URL de la demande..
curl -v -X DELETE / clients / anne
Ceci supprimera toutes les données associées à la ressource, identifiées par / clients / anne.
POSTER est utilisé lorsque le traitement que vous souhaitez effectuer sur le serveur doit être répété, si le POSTER demande est répétée (c’est-à-dire qu’ils ne sont pas idempotent; plus à ce sujet ci-dessous). en outre, POSTER les requêtes doivent entraîner le traitement du corps de la requête en tant que subordonné de l'URL à laquelle vous publiez.
En termes simples:
POSTE / clients /
ne devrait pas causer la ressource à / clients /, lui-même, à modifier, mais une ressource dont l'URL commence avec /clients /. Par exemple, il pourrait ajouter un nouveau client à la liste, avec un identifiant généré par le serveur.
/ clients / some-unique-id
METTRE les demandes sont utilisées facilement au lieu de POSTER demandes, et vice versa. Certains systèmes utilisent un seul, certains utilisent POSTER pour créer des opérations, et METTRE pour les opérations de mise à jour (depuis avec un METTRE demandez toujours l’URL complète), certains utilisent même POSTER pour les mises à jour et METTRE pour crée.
Souvent, POSTER Les requêtes sont utilisées pour déclencher des opérations sur le serveur, qui ne rentrent pas dans la Créer / Mettre à jour / Supprimer paradigme; mais cela dépasse toutefois le cadre de DU REPOS. Dans notre exemple, nous allons rester avec METTRE tout le.
Accentsconagua
OBTENIR. Les autres sont dangereux, car ils peuvent entraîner une modification des ressources. Méthodes idempotentes: Ces méthodes donnent le même résultat, peu importe le nombre de fois où la demande est répétée: elles sont OBTENIR, METTRE, et EFFACER. La seule méthode non idempotente est POSTER. METTRE et EFFACER être considéré comme idempotent pourrait être surprenant, cependant, il est en fait assez facile à expliquer: répéter une METTRE Une méthode avec exactement le même corps doit modifier une ressource de manière à ce qu'elle reste identique à celle décrite dans la section précédente. METTRE demande: rien ne changera! De même, il est inutile de supprimer une ressource deux fois. Il en résulte que peu importe combien de fois un METTRE ou EFFACER demande est répétée, le résultat devrait être le même que si cela n'avait été fait qu'une fois. Rappelles toi: c'est vous, le programmeur, qui décide finalement de ce qui se passe lorsqu'une certaine méthode HTTP est utilisée. Rien dans les implémentations HTTP n’entraîne automatiquement la création, la liste, la suppression ou la mise à jour de ressources. Vous devez faire attention à appliquer correctement le protocole HTTP et à appliquer vous-même ces sémantiques..
Le client HTTP et le serveur HTTP échangent des informations sur les ressources identifiées par des URL.
Nous pouvons résumer ce que nous avons appris jusqu’à présent de la manière suivante: le client HTTP et le serveur HTTP échangent des informations sur les ressources identifiées par des URL..
Nous disons que la demande et la réponse contiennent une représentation de la ressource. Par représentation, nous entendons des informations, dans un certain format, sur l'état de la ressource ou sur la manière dont cet état devrait être dans le futur. L'en-tête et le corps sont des morceaux de la représentation.
Les en-têtes HTTP, qui contiennent des métadonnées, sont étroitement définis par la spécification HTTP. ils ne peuvent contenir que du texte brut et doivent être formatés d'une certaine manière.
Le corps peut contenir des données dans n'importe quel format, et c'est là que la puissance de HTTP brille vraiment. Vous savez que vous pouvez envoyer du texte brut, des images, du HTML et du XML dans n’importe quel langage humain. À l'aide de métadonnées de demande ou d'URL différentes, vous pouvez choisir entre différentes représentations pour la même ressource. Par exemple, vous pouvez envoyer une page Web aux navigateurs et JSON aux applications.
La réponse HTTP doit spécifier le type de contenu du corps. Ceci est fait dans l'en-tête, dans le Type de contenu champ; par exemple:
Contenu / Type: application / json
Pour des raisons de simplicité, notre exemple d’application n’envoie que du JSON, mais l’application doit être conçue de manière à ce que vous puissiez facilement modifier le format des données, en fonction du client ou des préférences de l’utilisateur..
cURL est le plus souvent la solution client HTTP de choix pour les développeurs PHP.
Pour expérimenter les différentes méthodes de requête, vous avez besoin d'un client, qui vous permet de spécifier quelle méthode utiliser. Malheureusement, les formulaires HTML ne conviennent pas, car ils vous permettent uniquement de faire des requêtes GET et POST. Dans la vie réelle, les API sont accessibles par programme via une application client distincte ou via JavaScript dans le navigateur..
C'est la raison pour laquelle, en plus du serveur, il est essentiel de disposer de bonnes capacités de client HTTP disponibles dans le langage de programmation de votre choix..
Une bibliothèque client HTTP très populaire est, encore une fois, cURL. Vous avez déjà été familiarisé avec la commande cURL décrite précédemment dans ce didacticiel. cURL comprend à la fois un programme en ligne de commande autonome et une bibliothèque pouvant être utilisée par divers langages de programmation. En particulier, cURL est le plus souvent la solution client HTTP de choix pour les développeurs PHP. D'autres langues, telles que Python, offrent davantage de bibliothèques clientes HTTP natives.
Je souhaite exposer autant que possible les fonctionnalités de bas niveau.
Notre exemple d'application PHP est extrêmement barebone. Je souhaite exposer autant que possible les fonctionnalités de bas niveau, sans aucun cadre magique. Je ne voulais pas non plus utiliser une véritable API, telle que Twitter, car elles sont sujettes à des modifications inattendues. Vous devez donc configurer l'authentification, ce qui peut être fastidieux et vous ne pouvez évidemment pas étudier la mise en œuvre..
Pour exécuter l'exemple d'application, vous devez installer PHP5 et un serveur Web, avec un mécanisme permettant d'exécuter PHP. La version actuelle doit être au moins la version 5.2 pour avoir accès au json_encode () et json_decode () les fonctions.
En ce qui concerne les serveurs, le choix le plus courant reste Apache avec mod_php, mais vous êtes libre d'utiliser toutes les alternatives avec lesquelles vous êtes à l'aise. Un exemple de configuration Apache contient des règles de réécriture pour vous aider à configurer rapidement l'application. Toutes les demandes vers n’importe quelle URL, commençant par / clients /, doivent être acheminées vers notre server.php fichier.
Dans Apache, vous devez activer mod_rewrite et mettre le fourni mod_rewrite configuration quelque part dans votre configuration Apache, ou votre .htacess fichier. Par ici, server.php répondra à toutes les demandes provenant du serveur. La même chose doit être obtenue avec Nginx, ou le serveur alternatif que vous décidez d'utiliser..
Il existe deux clés pour traiter les demandes de la manière REST. La première clé consiste à lancer un traitement différent, en fonction de la méthode HTTP, même lorsque les URL sont identiques. En PHP, il y a une variable dans le $ _SERVER tableau global, qui détermine quelle méthode a été utilisée pour effectuer la requête:
$ _SERVER ['REQUEST_METHOD']
Cette variable contient le nom de la méthode sous forme de chaîne, par exemple 'OBTENIR','METTRE', etc.
L'autre clé est de savoir quelle URL a été demandée. Pour ce faire, nous utilisons une autre variable PHP standard:
$ _SERVER ['REQUEST_URI']
Cette variable contient l'URL à partir de la première barre oblique. Par exemple, si le nom d'hôte est 'exemple.com','http://example.com/' retournerais '/', tandis que 'http://example.com/test/' retournerais '/tester/'.
Essayons d'abord de déterminer quelle URL a été appelée. Nous ne considérons que les URL commençant par 'les clients'. Tous les autres sont invalides.
$ resource = array_shift ($ chemins); if ($ resource == 'clients') $ name = array_shift ($ path); if (empty ($ name)) $ this-> handle_base ($ method); else $ this-> handle_name ($ method, $ name); else // Nous ne gérons les ressources que sous l'en-tête 'clients' ('HTTP / 1.1 404 Introuvable'); Nous avons deux résultats possibles:
S'il existe un autre identifiant, nous supposons qu'il s'agit du nom du client et le transmettons à une autre fonction, en fonction du méthode. Nous utilisons un commutateur déclaration, ce qui devrait être évité dans une application réelle:
switch ($ method) case 'PUT': $ this-> create_contact ($ name); Pause; cas 'DELETE': $ this-> delete_contact ($ name); Pause; case 'GET': $ this-> display_contact ($ name); Pause; default: header ('HTTP / 1.1 405 Méthode non autorisée'); en-tête ('Allow: GET, PUT, DELETE'); Pause; Les codes de réponse HTTP standardisent un moyen d'informer le client du résultat de sa demande..
Vous avez peut-être remarqué que l'exemple d'application utilise PHP entête(), passer des chaînes étranges à la recherche comme arguments. le entête() la fonction imprime le HTTP en-têtes et veille à ce qu'ils soient correctement formatés. Les en-têtes doivent figurer en premier dans la réponse. Par conséquent, vous ne devez rien extraire avant d'en avoir terminé avec les en-têtes. Parfois, votre serveur HTTP peut être configuré pour ajouter d'autres en-têtes, en plus de ceux que vous spécifiez dans votre code..
Les en-têtes contiennent toutes sortes de méta-informations. Par exemple, le codage de texte utilisé dans le corps du message ou le type MIME du contenu du corps. Dans ce cas, nous spécifions explicitement les codes de réponse HTTP. Les codes de réponse HTTP standardisent un moyen d'informer le client du résultat de sa requête. Par défaut, PHP renvoie un 200 code de réponse, ce qui signifie que la réponse est réussie.
Le serveur doit renvoyer le code de réponse HTTP le plus approprié. De cette façon, le client peut tenter de réparer ses erreurs, en supposant qu’il en existe. La plupart des gens connaissent le commun 404 introuvable code de réponse, cependant, il y en a beaucoup plus disponible pour s'adapter à une grande variété de situations.
N'oubliez pas que la signification d'un code de réponse HTTP n'est pas extrêmement précise. Ceci est une conséquence de HTTP étant lui-même plutôt générique. Vous devriez essayer d'utiliser le code de réponse qui correspond le mieux à la situation. Cela étant dit, ne vous inquiétez pas trop si vous ne pouvez pas trouver un ajustement exact.
Voici quelques codes de réponse HTTP, souvent utilisés avec REST:
Ce code de réponse indique que la demande a abouti.
Cela indique que la demande a abouti et qu'une ressource a été créée. Il est utilisé pour confirmer le succès d’une METTRE ou POSTER demande.
La demande était mal formée. Cela arrive surtout avec POSTER et METTRE demandes, lorsque les données ne passent pas la validation ou sont dans un format incorrect.
Cette réponse indique que la ressource requise est introuvable. Ceci est généralement renvoyé à toutes les demandes qui pointent vers une URL sans aucune ressource correspondante..
Cette erreur indique que vous devez effectuer une authentification avant d'accéder à la ressource..
La méthode HTTP utilisée n'est pas prise en charge pour cette ressource..
Cela indique un conflit. Par exemple, vous utilisez un METTRE demande de créer deux fois la même ressource.
Quand tout le reste échoue; généralement, une réponse 500 est utilisée lorsque le traitement échoue en raison de circonstances imprévues côté serveur, ce qui entraîne la sortie d'erreur du serveur.
Commençons par extraire simplement les informations de l'application. Nous voulons les détails du client, 'Jim', alors envoyons un simple OBTENIR demande à l'URL de cette ressource:
curl -v http: // localhost: 80 / clients / jim
Cela affichera les en-têtes de message complets. La dernière ligne de la réponse sera le corps du message; dans ce cas, ce sera JSON contenant l’adresse de Jim (rappelez-vous que l’omission d’un nom de méthode entraînera un OBTENIR demande; remplacer également localhost: 80 avec le nom du serveur et le port que vous utilisez).
Ensuite, nous pouvons obtenir les informations pour tous les clients à la fois:
curl -v http: // localhost: 80 / clients /
Pour créer un nouveau client, nommé Paul…
curl -v -X PUT http: // localhost: 80 / clients / paul -d '"address": "Sunset Boulevard"
et vous recevrez la liste de tous les clients contenant maintenant Paul comme confirmation.
Enfin, pour supprimer un client:
curl -v -X DELETE http: // localhost: 80 / clients / anne
Vous constaterez que le JSON renvoyé ne contient plus aucune donnée sur Anne..
Si vous essayez de récupérer un client non existant, par exemple:
curl -v http: // localhost: 80 / clients / jerry
Vous obtiendrez une erreur 404 tandis que, si vous essayez de créer un client qui existe déjà:
curl -v -X PUT http: // localhost: 80 / clients / anne
Vous recevrez plutôt une erreur 409.
En général, moins vous formulez d’hypothèses au-delà de HTTP, mieux vous.
Il est important de se rappeler que HTTP a été conçu pour communiquer entre des systèmes partageant une compréhension du protocole. En général, moins il y a d'hypothèses au-delà de HTTP, mieux c'est: ceci permet à la plus large gamme de programmes et de périphériques d'accéder à votre API..
J'ai utilisé PHP dans ce tutoriel, car il s'agit probablement du langage le plus familier des lecteurs de Nettuts +. Cela dit, PHP, bien que conçu pour le Web, n’est probablement pas le meilleur langage à utiliser lorsque vous travaillez de manière REST, car il gère METTRE demandes d'une manière complètement différente de celle OBTENIR et POSTER.
Au-delà de PHP, vous pourriez envisager les éléments suivants:
Parmi les applications qui tentent de respecter les principes REST, l'exemple classique est le protocole de publication Atom, bien qu'il ne soit vraiment pas utilisé trop souvent dans la pratique. Pour une application moderne, qui repose sur la philosophie d’utiliser HTTP au maximum, reportez-vous à Apache CouchDB..
Et n'oubliez pas de consulter la sélection de scripts de code, de plug-ins et d'applications sur Envato Market.
S'amuser!
Nous avons créé un guide complet pour vous aider à apprendre le JavaScript, que vous soyez débutant en tant que développeur Web ou que vous souhaitiez explorer des sujets plus avancés..
