Comment envoyer des “commandes” à un serveur RESTful?
Cas d’utilisation: Mon serveur met en cache certaines informations afin de ne pas avoir à lire la firebase database chaque fois que ces informations sont demandées. J’ai besoin d’un moyen d’envoyer une commande à partir de mon application cliente pour demander au serveur de vider le cache. Utiliseriez-vous POST ou PUT sur une URL comme “… / flush_cache”?
La “commande” n’est pas vraiment une donnée nécessitant un “transfert d’état de représentation”, à moins que l’état transféré ne soit le résultat de la commande – “le commutateur est désactivé”, “le cache est vidé”, etc. REST envoie des commandes au serveur?
J’ai déjà rencontré une telle situation dans un projet antérieur. Puisque REST est bien … à propos des ressources, on ne sait pas toujours comment traiter les choses qui sont vraiment de nature RPC.
Un moyen facile de contourner ce problème est de le considérer comme la partie bureaucratique du repos , la demande pouvant être une ressource elle-même:
1 . “Vous voulez déclencher une commande sur mon serveur? Remplissez d’abord ce formulaire I90292 et envoyez-le nous”:
POST /bureaucracy/command-request Content-Type: application/x-www-form-urlencoded Content-Length: ... “Ok, nous verrons ce que nous pouvons faire. Votre numéro de dossier est 999”
201 Créé (ou 202 Accepté selon le commentaire de Kugel) Lieu / bureaucratie / demande de commande / 999
Et puis le client vérifie régulièrement
GET / bureaucratie / demande de commande / 999
Espérons qu’il obtienne une réponse comme celle-ci
200 OK 999 ... Success
Bien sûr, si le service bureaucratique a un excellent service à la clientèle, il offrirait au client de l’appeler quand il le souhaite s’il le souhaite:
“Vous voulez déclencher une commande sur notre serveur? Veuillez remplir ce formulaire et nous l’envoyer. Notez que vous pouvez joindre vos informations de contact pour que nous puissions vous appeler quand c’est fait”
POST /bureaucracy/command-request?callback=client.com/bureaucracy/inbox
Ou comme un en-tête http personnalisé X-Callback: http://client.com/bureaucracy/inbox
Je suggère ceci:
http://server.example/results/00001 ), peut-être avec un statut 204 (No Content) et En-tête de lieu ou une redirection (selon le client peut comprendre). C’est à vous de décider du cycle de vie de la ressource de résultat. Cela pourrait être de courte durée si vous n’avez pas besoin de stocker les résultats longtemps. L’URI pourrait être construit à partir d’un UUID par exemple.
Dans votre cas, pourquoi ne pas faire du cache la ressource?
DELETE /cache
Quand vous voulez le vider.
POST /cache
quand vous voulez en créer un nouveau.
Ou combinez les deux précédentes dans les suivantes:
DELETE /cache?autorecreate=true