url pour la gestion du CRUD

Par Vallyan, il y a 10 ans

PHP

Question un peu philosophique, un peu pragmatique aussi:

Je développe avec symfony (encore que ce ne soit pas une excuse valable), et j'ai l'habitude de faire des url du genre:

en admetant que 34 soit l'id d'un truc a voir, supprimer ou modifier, respectivement (on pourait aussi imaginer un slug a la place de l'id).
C'est comme cela que symfony génère les CRUD et les url associés automatiquement lorsque l'on passe par la console, et c'est plus ou moins comme ca que j'ai toujours vu les choses.

On m'a fait remarquer récemment qu'il serait peut-etre plus judicieux de réserver l'url pour identifier une ressource, et de faire passer l'action a réaliser en argument. par exemple:

monsite.com/thing/34?action=delete

J'ai tendance a ne pas aimer les parametres passés en get, mais d'un autre coté si ca aide au réferencement ...

5 réponses

kal-el, il y a 10 ans

Il y a selon moi une meilleur alternative à ton problème : REST. Je ne vais pas faire un cours la dessus ici mais en bref, afin de déterminer l'action à réaliser, tu ne te base uniquement sur les verbes HTTP (GET, POST, PUT/PATCH, DELETE) que tu passe dans les headers de la requête.

De cette manière, l'accès à tes différentes resource se fera de manière homogène :

GET /things ==> ThingsController#index GET /things/:id ==> ThingsController#show POST /things ==> ThingsController#create PUT/PATCH /things/:id ==> ThingsController#update DELETE /things/:id ==> ThingsController#destroy

Pour ma part, j'aime aussi mettre le nom des resources au pluriel (pour la consistence) mais après c'est un choix qui ne reviens qu'a toi. Au niveau de Symfony je n'ai malheureusement pas énormement d'expérience mais tout les frameworks moderne te permettrons d'arriver à cela, en envoyant généralement une clé de type _method contenant le verbe HTTP associé à la requête.

Vallyan, il y a 10 ans

Merci de ta réponse Kal-el.
Effectivement j'y ai pensé mais j'avais en tete que les navigateurs ne sont pas les meilleurs clients REST, et qu'ils ne connaissent pas toutes les méthodes HTTP. Il existe des "hack" pour faire passer la méthode PUT ou DELETE en parametre POST depuis un champ caché du formulaire (et tu as raison sf2 le propose nativement si besoin), mais je trouvais que ca ressemble plus a du bidouillage qu'autre chose.
Cela dit si tout le monde fait comme ca ...

Lartak, il y a 10 ans

Effectivement j'y ai pensé mais j'avais en tete que les navigateurs ne sont pas les meilleurs clients REST, et qu'ils ne connaissent pas toutes les méthodes HTTP

Si les principaux Framework utilisent le système REST, c'est que les navigateurs comprennent très bien les entêtes HTTP qu'ils utilisent, je ne vois donc pas où est le problème.

Vallyan, il y a 10 ans

Il n'y a pas que les navigateurs qui communiquent avec des serveurs. Il peut donc y avoir un intéret pour des frameworks a supporter certaines méthodes HTTP qui ne sont pourtant plus supportée par l'HTML (applications mobiles par exemple).

As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts.

http://programmers.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms

mxmaxime, il y a 10 ans

J'utilise la même méthode que toi, et je n'ai jamais eu de problème.
Après, c'est vrai que la "grande mode" est pour REST, qui pour moi ne sert à rien dans certains cas ^^
Perso je préfère ta méthode à REST, mais c'est une préférence perso :-)
Même si tu utilises Symfony, pour éviter des failles de sécu, tu peux simplement créer une route spécifique pour les actions administrateur.
Exemple, j'avais des url /business/manage/add /business/manage/edit/.... et toutes les url manage tu les sécurise dans security.yml, après chacun sa façon de faire ^^