J'imagine que c'est un acronyme, vu que tu me poses la question.Effectivement, c'est pour HyperText Transfer Protocol.
HyperText
Tu m'as déjà parlé d'HyperText ! Ce ne sont pas des documents reliés entre eux?Effectivement, le concept d'HyperText est d'avoir des pages qui ont des références vers d'autres pages.
HTTP
Et HTTP, comme son nom l'indique, c'est un protocole de transfert - ou communication - de document HyperText.
Tu entend quoi par protocole?C'est une façon de communiquer. Chaque ordinateur a son propre système d'exploitation et des logiciels installés qui lui sont spécifiques. Pour pouvoir communiquer avec un autre ordinateur, potentiellement avec un autre système d'exploitation et d'autres logiciels, il faut trouver un langage sur lequel se mettre d'accord. C'est l'objectif d'un protocole de de communication, il définit une norme dans laquelle la façon d'envoyer une demande et une réponse sont très précise. Ainsi peut importe comment l'ordinateur fonctionne, il est capable de comprendre ce qu'on lui demande.
Il existe de très nombreux protocole de communications différents, et HTTP est donc un protocole pour échanger des document HyperText, comme par exemple des pages HTML avec des liens.
Ah, je sens qu'on arrive dans le vif du sujet.En effet, d'ailleurs pour rappel, HTML signifie HyperText Markup Language, c'est un langage de programmation pour créer des pages HyperText avec des balises.
Ah mais oui maintenant que tu me le dit ! Je n'avais jamais fait le lien entre http et html.Message HTTP
Et attention, maintenant on parle de protocole, et donc de norme, on va employer apprendre à employer les bons termes !
Ok je t'écoutePour commencer, quand on veut envoyer une "demande" via le protocole HTTP, on parle d'envoyer une requête. Et cette requête se passe en deux partie, d'abord le client envoie un message HTTP, et le destinataire va traiter ce message pour envoyer une réponse HTTP.
Ok donc requête HTTP = message + reponseC'est ça. Ce message est au format texte, mais il y a une syntaxe très précise à respecter pour qu'il soit compris par tous :
{"language":"shell","content":"<Method> <Path> <Protocole>\n<Host>\n[<Headers>]\n\n[<Body>]","filename":""}
- Method : c'est le type de demande envoyée par le client. Par exemple une méthode GET signifie qu'on demande à récupérer des données, alors qu'une méthode POST sert à envoyer des données à enregistrer.
- Path : c'est le chemin pour accéder à la ressource en particulier, un serveur peut proposer de nombreuses ressources différentes, il faut donc bien lui préciser laquelle
- Protocole : ça permet de préciser le protocole utilisé, car comme je te l'ai dit il en existe de nombreux, et même pour HTTP, il y a plusieurs version différentes. Généralement ce sera "HTTP/1.1"
- Host : c'est le destinataire de la demande, donc son nom de domaine ou adresse IP
- Headers : c'est un paramètre facultatif pour préciser des informations complémentaires dans le message. Ce sont ici surtout des méta données, pour définir comment traiter spécifiquement la requête.
- Body : un autre paramètre facultatif, il ne va être utilisé que s'il y a des données à envoyer au serveur, comme par exemple quand on utilise la méthode POST, pour lui fournir les données à enregistrer.
Je comprend la logique, mais de là à faire une requête moi même...Exemple GET
Par exemple si on veux afficher la page de recherche de google on peut envoyer une requête GET au serveur google.fr
{"language":"shell","content":"GET / HTTP/1.1\nHost: google.fr\nContent-Type: application/x-www-form-urlencoded","filename":""}
Ok je comprend à peu près, mais pourquoi tu as précisé un Content-Type? Tu ne m'en a pas parlé de ça !Et si je t'en ai parlé, c'est un header de requête, il en existe de très nombreux différents, mais le Content-Type permet de préciser au serveur que les données de la requête sont au format url.
Hum ok, et pourquoi un / après GET?Car on veux juste contacter l'url de base de google c'est à dire http://google.fr, par contre si on voulait préciser une recherche sur le mot "HTTP", il faudrait plutôt contacter l'url http://www.google.fr/search?q=http ce qui donnerait :
{"language":"shell","content":"GET /search?q=http HTTP/1.1\nHost: google.fr\nContent-Type: application/x-www-form-urlencoded","filename":""}
D'accord je comprend mieux.Exemple POST
Pour une requête POST ce serait un peu différent, car il faut passer un body en plus, et il faut aussi préciser le type de données du body, par exemple, pour une requête de login sur un site :
{"language":"shell","content":"POST /login HTTP/1.1\nHost: monsite.fr\nContent-Type: application/x-www-form-urlencoded\n\nemail=contact@training-dev.fr&password=123456","filename":""}
Ok, mais tu es toujours en content-type url là?En effet, car j'ai préciser des données au format url, mais je pourrais envoyer exactement la même chose dans un autre format :
{"language":"shell","content":"POST /login HTTP/1.1\nHost: monsite.fr\nContent-Type: application/json\n\n{“email”: “contact@training-dev.fr”,”password”:”123456”}","filename":""}
Si j'ai bien compris, là c'est au format JSON.C'est bien ça, et dans les deux cas, le serveur va être capable de comprendre et traiter les données que je lui ai envoyé, car je lui ai précisé le format.
Réponse HTTP
Il pourra donc répondre à ma requête et respectant lui aussi un format très précis de réponse :
{"language":"shell","content":"<Protocole> <Status Code> <Status Message>\n<Headers>\n\n<Body>","filename":""}
On retrouve à peut prêt les même données, mais pas dans le même ordre, et on a en plus un Status Code et Status message. Ils permettent de préciser comment la requête s'est passée sur le serveur. Tu as déjà entendu parler de code HTTP?
Hum, ça ne me dit rien.Si je te dit 404?
Page introuvable !Et bien 404 est un code HTTP qui peut être envoyé dans le Status Code, et page introuvable, ou plutôt Not Found en anglais sera envoyé dans ce cas dans le Status Message.
Ah ok !Et il existe de nombreux code et messages associés, le plus important étant le code 200 pour "OK". Il signifie que la requête s'est bien passée et qu'il répond normalement, comme la plupart des codes 2xx. Par contre tous les codes en 4xx ou 5xx comme 404 ou 500 sont des codes d'erreur précisant que le serveur n'as pas pu traiter la demande correctement.
Voici donc une réponse que pourrait envoyer le serveur :
{"language":"shell","content":"HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 123456\nDate: Mon, 14 Jun 2021 17:09:55 GMT\n\n<!Doctype html>\n<html>\n\t<head>\n\t...\n","filename":""}
Pourquoi il y a plus d'en-tête ici?Il n'y a pas de limite au nombre d'en-tête aussi bien dans un message que dans une réponse.
Et pourquoi un content type ici aussi? Je pensais que ça servait à préciser le format des données dans le message...C'est bien ça, mais ça permet aussi de préciser le format des données dans la réponse, qui dans le cas présent est du HTML. Mais ça pourrait être bien d'autres choses !
Je pense que j'ai tout compris. Peut être une dernière question, tu m'as parlé de http, mais https c'est quoi alors? J'ai terminé cette partie