Restful : C’est quoi une méthode safe ou idempotent ?

Safe

Les méthodes safe, sécurisées en français, sont toutes les méthodes HTTP qui ne modifient aucune ressource.

Par exemple, une requête GET sur une ressource ne devrait jamais modifier de données.

Ainsi, la requête suivant n’est pas correcte si son but est réellement de supprimer un utilisateur :

GET /user/delete/1234

L’avantage des méthodes safe c’est qu’elles peuvent être mise en cache ou en prefetch sans crainte, a condition de respecter cette règle.

Idempotent

Une méthode idempotente est une méthode qui peut être appelée autant de fois que l’on souhaite et qui retournera toujours le même résultat.

Par exemple, une méthode qui affecte une valeur à une ressource est idempotente :

username = mike

Peut être appelée un million de fois, le résultat sera toujours le même. Par conttre, la méthode qui ferait l’action suivante n’est pas idempotente :

user_age = user_age +1

On remarquera aussi que ces deux méthodes ne sont pas safe, elles modifient toutes les deux des données.

L’idempotence est importante quand on veut réaliser une API robuste. Par exemple si on permet d’effectuer une mise a jour via un POST ça peut poser un problème, imaginons que la requête de ce POST n’aboutisse pas (timeout par exemple) on peut alors se retrouver avec des données corrompues : faut-il recommencer ? La données a-elle été mise à jour ?

Si on utilise les méthodes idempotents à bons escient on n’a pas besoin de se poser ces questions et on peut renvoyer ces requêtes tant qu’elles ne passent pas correctement.

Un petit récapitulatif

METHODE HTTP Idempotent Safe
OPTIONS Oui Oui
GET Oui Oui
HEAD Oui Oui
PUT Oui Non
POST Non Non
DELETE Oui Non
PATCH Non Non

Pour avoir plus d’informations vous pouvez aller voir ce site référence: restcookbook.com

 

Une courte introduction aux Promises

La programmation synchrone comme en PHP ou en Python est simple à appréhender, une étape à la fois, chaque instruction est exécutée l’une après l’autre. Mais lorsque vous regardez un peu ce qu’il se passe du coté de nodejs et du javascript, vous vous rendez vite compte que la programmation asynchrone omniprésente. C’est un gain de performances, pouvoir lancer plusieurs requêtes en même temps et recevoir (et traiter) les réponses à mesure qu’elle arrivent, c’est plutôt efficace.

Par contre ça peut vite devenir très difficile à gérer lorsque l’application grandit, c’est là que les objets Promise entrent en jeu

Utiliser les objets Promises

Un petit exemple


function parse(json) {
  return new Promise( (resolve, reject) => {
    try {
      resolve(JSON.parse(json));
    } catch (e) {
      reject(e);
    }
  });
}

parse(process.argv[2]).then( result => {
    // On traite le résultat
}).catch( reject => {
    // On traite l'erreur
    console.log(reject);
});

Un objet Promise ne devrait être utilisé qu’avec des fonction asynchrones, setTimeOut par exemple.

Lorsqu’on crée une Promise il peut y avoir deux retours soit tout c’est bien passé et on retourne le résultat avec resolve() ou alors il y a eu une erreur et alors on utilise reject()

On voit bien l’intérêt d’utiliser les objets Promise dans un environnement asynchrone le fait de pouvoir chaîner les then() entre-eux allège énormément le code.

Par exemple, lancer plusieurs fonctions les unes à la suite des autres devient alors bien plus simple , plus la peine de les imbriquer entre elles à l’intérieur des callbacks


promise()
    .then(...)
    .then(...)
    .then(...)
    .then(...)
    .catch(...)

Pour aller plus loin : Les promises sur MDN

Utiliser Iptables pour bloquer les accès par pays

Voici la traduction d’un article de   qui est disponible ici : Linux Iptables Just Block By Country – Merci à l’auteur de m’avoir donné l’autorisation de traduire son article.

Je gère un site de commerce électronique et un grand nombre de traffic indésirable (spam, tentative de hack, …) provient de certains pays dont l’intention d’achat est clairement inexistante. Je me posais alors la question de pouvoir mettre ne place un système basé sur Apache ou iptables pour bloquer les connections provenant de ces pays. Lire la suite

Utiliser l’API météo de Google

IMPORTANT : Depuis la publication de cet article, l’API météo fournir par google à été supprimée, elle ne fonctionne plus. J’ai créé un bundle symfony qui utilise l’API de OpenWeatherMap, ce bundle est libre et son code source est disponible sur son dépot github

Pour un de mes sites perso sur les villes de France, j’utilisais le webservice météo fourni par The Weather Channel mais quelques temps celui-ci est devenu payant j’ai donc dû trouver une solution alternative. Apres un peu de recherche à droite et à gauche j’ai trouvé un webservice peu connu et peu documenté fourni par Google correspondant bien à mes besoins.
Lire la suite

Traitements parallèles grâce a Gearman

Je me suis déjà frotté au multitâche avec PHP, et il faut dire, avec un certain recul et pas mal de temps de tests, que je suis plutot déçu par la stabilité du système mis en place. J’avais développé ça sur une base de forks de process. Ça marchait bien jusqu’à un certain point, lorsque le serveur était un peu chargé (à peine plus que d’habitude) certain de mes process plantaient aléatoirement, jamais le même process. Peut-être que j’abusais un peu, mais bon j’en ai besoin de mes 200 process moi.

Dans ma quête de stabilité, je me suis dit qu’utiliser Gearman serait une bonne idée, il est censé être simple, scalable, stable, et tout et tout.

Lire la suite

Associer un sous-domaine à une application symfony

Coté serveur web

Il faut soit  créer des virtual host pour tous vos sous-domaine.

Soit créer un seul virtual host en utilisant des wildcards dans le ServerAlias, du coup tous les sous-domaines pourraient correspondre à une application, plus besoin de créer autant de virtual hosts que de sous-domaine. Il doit même être possible d’utiliser les wildcards dans la déclaration du domaine dans le gestionnaire de dns.

Lire la suite

PHP fait du multitâche

Pour les besoins d’un projet effectuant un grand nombre de tâches répétitives, j’ai dû mettre en place un système basé sur un script PHP lancé par cron à intervalles réguliers. Il n’y a aucune difficulté particulière à réaliser ceci, là où ça commence à être intéressant c’est à partir du moment où il a fallu que ce script puisse lancer plusieurs tâches en même temps.

On a donc un script lancé à intervalles réguliers qui lui même va lancer et gérer un certain nombre, configurable, de tâches concurrente. Voici comment j’ai procédé.

Lire la suite