REST : la conséquence des entêtes HTTP personnalisées

Il y’a eu plusieurs essais pour étendre HTTP avec de nouvelles méthodes. Par exemple, WebDAV ajoute les méthodes LOCK, UNLOCK, PROPPATCH, MOVE etc. pour la création et le versionning des documents. La méthode PATCH est aussi une extension qui permet de gérer les mises a jour partiels de documents. Tandis que MERGE gère le merge des ressources.

Par ailleurs, Ajouter des méthodes personnalisées (custom methods)  n’est pas sans conséquences. Essentiellement, il y’a un bris de la contrainte d’interface uniforme, notion essentielle en REST. Quand vous introduisez de nouvelles méthodes, vous ne pouvez plus vous fier aux logiciels qui ne sont conscients que des entêtes HTTP standard (Serveurs proxy, Serveurs de Cache etc.). A moins que votre extension soit largement connue et adoptée, les extensions de méthodes réduisent l’interopérabilité.

La solution dans ce cas est de concevoir une ressource  qui abstrait ces opérations spécifiques, et utiliser la méthode POST.

Prenons par exemple le cas de la méthode MOVE de WebDAV. Cette dernière est définie comme suit : “Equivalent logique a une copie, suivie d’un traitement de maintenance pour assurer la consistance, suivi d’une suppression de la source, Où toutes ces opérations sont atomiques”. N’importe quel client peut exécuter une requete OPTIONS pour déterminer si un serveur WebDAV supporte MOVE ou non.

# Réponse
HTTP/1.1. 204 No Content
Allow: GET, PUT, DELETE, MOVE
Si c’est le cas, le client peut alors effectuer la requête MOVE sur cette ressource, comme suit :

Cool! Nous pouvons alors imaginer que nous pouvons faire la même chose si nous voulons “cloner” une ressource. Nous pouvons concevoir une nouvelle méthode CLONE qui permet de copier une ressource sans supprimer la source. Par ailleurs, les composants et logiciels standards, comme les serveurs de cache et les serveurs proxy vont considérer ces méthodes comme des méthodes dangereuses, “non idempotents“, et “non cacheables”. En d’autres termes, ils vont considérer toute méthode non standard comme POST, qui est considérée “non idempotente” et “non cacheable”.

La raison derrière ceci est que l’idempotence et la sureté sont des garanties que le serveur doit explicitement donner; Pour les méthodes non standard, les serveurs de cache, serveurs proxy et librairies HTTP ne peuvent pas assumer ces garanties. Du coup, pour la majorité des méthodes qui ne sont pas standard, les entêtes HTTP en général sont considérées les mêmes que ceux pour POST.
De plus, il n’y a pas de garanties que tous les logiciels HTTP (incluent les firewalls) supportent des extensions arbitraires. Utilisez donc ces méthodes personnalisées uniquement si vous n’avez pas besoin de supporter une large interopérabilité.
Morale de l’histoire : Utilisez POST au lieu de concevoir des méthodes personnalisées, afin d’assurer le plus d’interopérabilité.