PHP, vos astuces pour palier à ses défauts ?

[Sephi-Chan]

Une remarque par rapport à ce que dit Sephi : les URL REST c'est bien, mais dans une appli Rails, les termes de la recherche sont donc envoyés en GET systématiquement afin de pouvoir bookmark la parge de résultats ?
Dans quel cas préconise-t'on l'envoi via POST ? Uniquement pour les interfaces auxquelles il faut être loggés (espace privé) ?

Dans REST, on utilise POST pour effectuer une opération qui va altérer une ressource. Ça peut être la création et/ou la modifier, selon les choix de ceux qui implémentent l'API RESTful. L'authentification n'est pas une condition sine qua non.

Dans Rails, on utilise généralement POST pour créer une ressource et PUT pour la modifier.

Un exemple appliqué à un Webgame (ça change des CRUD à la con) : je souhaite déployer 2 unités sur un territoire qui m'appartient. Je vais envoyer une requête PUT à ma ressource Ownership (qui modélise l'appartenance d'un territoire à un joueur). Je créerais alors une route telle que :

put "/games/:game_id/ownerships/:id/deploy", to: "ownerships#deploy"

Et le corps de la requête devra contenir un paramètre, disons count. Bien sûr, ce paramètre pourrait être donné en GET, mais l'intérêt serait moindre. Ainsi dans le code de mon contrôleur, j'ai un code très simple du type (ensuite, j'ai des vues pour répondre au formats souhaités : HTML, JSON ou autre) :

def deploy

  game      = Game.find(params[:game_id])

  ownership = game.ownerships.find(params[:id])

  

  ownerships.deploy_units!(params[:count])

end

Dans le cas d'un moteur de recherche, les paramètres utiles pourraient en effet être transmis inscrits dans l'URL mais ça ne serait pas REST puisqu'on conserve la composante temps : les résultats d'une même recherche peuvent varier au cours du temps.

Une autre possibilité pourrait être de traiter une recherche comme une ressource identifiée : avec ses propres résultats gravés dans le marbre (qui ne varieraient pas au cours du temps). Ainsi, la recherche est bien stateless. Après, la question à se poser : est-ce que ce besoin est pertinent ?

Ce n'est pas parce que REST présente certains avantages que c'est toujours la meilleure solution. Dans certaines de mes applications, j'ai une route /dashboard : ça n'a pas de sens d'un point de vue REST mais c'est fort utile. J'essaye d'utiliser les outils à ma disposition avec pragmatisme pour faire ce que je veux sans m'enfermer dans un carcan pénible.