Conventions d'URL du framework PHP

Question

De nombreux frameworks utilisent des conventions d'URL telles que / controller / action / {id} , ce qui est très bien, mais si vous avez besoin d'une configuration supplémentaire, c'est à vous de rédiger vos propres itinéraires.

Comment gérez-vous les URL telles que / users / {id} / friends dans le backend? (pour lister tous les amis d'un utilisateur)

Je pense que dans le contrôleur, quelque chose comme ceci serait approprié:

class User {
    function index() {
        echo 'user index';
    }
}

class Friend extends User {
    function index($user_id) {
        echo 'friend index';
    }    
}

Vous obtiendrez alors la carte suivante:

/users              -> User::index()
/users/{id}         -> User::view($id)
/users/{id}/friends -> Friend::index($user_id)

Je voulais placer la classe Friend dans la classe User mais, apparemment, vous ne pouvez pas le faire en PHP, c'est donc le meilleur que je puisse trouver. Des pensées?

Quelle URL utiliser pour modifier votre liste d'amis? / users / {id} / friends / edit pourrait fonctionner, mais cela ne semble pas approprié, car vous ne devriez jamais modifier la liste d'amis de quelqu'un d'autre. Est-ce que / account / friends / edit serait un meilleur choix? Où mettriez-vous le code correspondant pour cela? Dans un contrôleur ami, ou un contrôleur utilisateur, ou un contrôleur de compte spécialisé?

Question bonus: que préférez-vous? / photos / delete / {id} ou / photos / {id} / delete

Les réponses:

Donc, ce que j'ai compris des réponses, c'est que si la "chose" est compliqué (comme "amis") mais n’a pas son propre contrôleur, vous pouvez en donner un sans modèle, ou si ce n’est pas le cas, vous devez le ranger avec ce qui lui est le plus étroitement lié. Vos URL ne doivent pas influencer où vous mettez votre code. La plupart des gens semblent penser que vous devriez vous en tenir à / controller / action / {id} dans la mesure du possible, car c'est ce que les gens connaissent bien.

Personne n’a réellement commenté la classe élargie à part dire qu’elle est "maladroite". FriendList aurait peut-être été une classe plus appropriée dans ce cas si je voulais vraiment la séparer.

Merci pour toutes les réponses:)

Answer 1

Les itinéraires dont vous parlez et la façon dont vous utilisez les sous-classes pour réaliser cette structure me semblent un peu gênants. La convention standard de / controller / action / {id} convient parfaitement à des actions simples, mais si vous créez une application complexe, vous devez toujours créer des itinéraires personnalisés. Il existe probablement de bonnes directives à suivre lors de la création de ces itinéraires, mais il s’agit vraiment de rester cohérent dans votre application et de garder les choses aussi simples que possible.

Je ne vois aucune raison valable pour que / utilisateur / {id} / amis soit mappé sur un " Ami " manette. Pourquoi ne pas simplement avoir " amis " être une action sur le contrôleur utilisateur ? Une fois que vous avez eu accès au détail pour afficher la page d'un ami spécifique, vous pouvez utiliser un contrôleur Friend ( / friends / view / 123 ) ou réutiliser votre Utilisateur <. / code> pour que cela fonctionne pour un ami ou pour l'utilisateur actuellement connecté ( / user / view / 123 ).

Re: la question bonus, je resterais avec / photos / delete / {id} ( / contrôleur / action / {id} ) car c'est le plus mécanisme largement accepté.

Answer 2

Je préférerais / photos / {id} / delete . Mon raisonnement est que si vous supprimez un composant de la fin d'une URL, cela devrait quand même avoir du sens.

Il est assez facile de supposer que / photos / {id} doit faire: afficher le jeu de photos correspondant à ce {id} .

Mais que doit faire / photos / delete ? C'est vraiment pas clair.

Je sais qu'il existe une sorte de convention par défaut de / controller / action / id , mais cette organisation a pour but de mapper sur l'architecture classe / méthode des contrôleurs. Je ne pense pas que ce soit une bonne idée d’organiser l’UI en fonction du code (l’URL fait en quelque sorte partie de l’UI).

Commentaires: Oui, / photos / {id} est peut-être plus logique de visualiser une photo donnée par son identifiant. / users / {id} / photos peut-être pour afficher une collection. C'est à vous.

Le fait est que vous devez penser à l'interface utilisateur en termes d'utilisateurs, et non en termes d'organisation du code.

Answer 3

Vous pouvez faire soit ou. Le problème est lorsque vous mélangez les deux. / users / {id} / friends et / users / friends / {id} Quand quelqu'un a l'identifiant de " amis " cela va échouer. Cela peut sembler un cas trivial, mais il est très courant d’utiliser des noms d’utilisateur pour les identifiants. Vous devrez limiter les noms d'utilisateurs pour chaque action.

Parfois, vous ne pouvez pas faire / {contrôleur} / {action} / {id}

J'ai fait un site de musique indépendante il y a quelque temps et nous avons fait

/artist/{username}
/artist/{username}/albums
/artist/{username}/albums/{album}

Nous ne voulions pas tester les conditionnels afin de ne pas le faire

/artist/{username}/{album}

Étant donné que nous ne souhaitons rechercher personne avec un album intitulé "albums"

Nous aurions pu le faire

/artist/{username}
/artist/{username}/albums
/albums/{album}

mais nous perdrions alors l’avantage en termes de référencement d’avoir à la fois le nom de l’artiste et le nom de l’album dans l’URL. De plus, dans ce cas, nous obligerions les noms d'album à être uniques, ce qui serait mauvais, car il est courant que l'artiste ait le même nom d'album qu'un autre artiste.

Vous pouvez faire du / {contrôleur} / {action} / {id} pur, mais vous perdriez un peu de référencement et vous ne pourriez plus raccourcir les URL.

/artist/view/{username}
/artist/albums/{username}
/album/view/{album}

Revenons à votre exemple.

  

/ users / {id} / friends / edit pourrait fonctionner,   mais cela ne semble pas approprié, car   vous ne devriez jamais éditer quelqu'un   La liste d'amis du reste du monde.

Dans ce cas, il devrait s'agir de / friends / edit car votre identifiant d'utilisateur est une information en double, en supposant que vous soyez dans une session. En général, vous souhaitez prendre en charge le raccourcissement des URL et non leur expansion.

(Question bonus) Je n’utiliserais pas non plus REST . DELETE / photo? id = {id}

Answer 4

Cela dépend également de la manière dont vous stockez vos données. J'imagine que dans certains cas, vous avez besoin d'une "liste d'amis" pour constituer une entité dans votre modèle. Une approche logique consisterait alors à spécifier un identifiant unique pour chaque liste d'amis, une clé primaire.

Cela entraînerait logiquement le chemin suivant, car vous n'avez besoin que d'une clé primaire de la liste d'amis pour la modifier ou la supprimer ...

/ friends / edit / {friendListId}

C'est à vous de décider. Comme le dit pix0r: pour les petites applications, la convention est / {contrôleur} / {action} / {id} où {id} doit être facultatif pour correspondre à la plupart des actions de vos sites Web. Dans certains cas, les applications deviennent volumineuses et vous souhaitez définir des itinéraires spécifiques comportant plus de 3 éléments. Dans certains cas, certaines entités obtiennent simplement un sens plus important (exemple ci-dessus) et vous pouvez décider de définir un contrôleur personnalisé pour celui-ci (ce qui rétablit à nouveau la perfection de la route par défaut ...).

Je resterais avec la route par défaut / controller / action / id mais ne commencez pas à créer des contrôleurs pour tout (comme des amis) au début. Le modèle Model-View-Controller vous permet de modifier les itinéraires plus tard très facilement, à condition que tous vos liens et actions (formulaires, etc.) soient générés en fonction des itinéraires et des actions. Donc, vous n’avez vraiment pas à vous inquiéter autant:)

Answer 5

Les URL elles-mêmes importent peu. Ce qui est plus important est ce qui se passe dans chacun de vos contrôleurs. Dans votre exemple, votre liste d'amis a été étendue à la classe Utilisateur . Si votre liste d'amis n'est en réalité qu'une liste d'utilisateurs, vous devriez peut-être étendre le contrôleur Utilisateurs pour pouvoir gérer les listes d'utilisateurs au même endroit.

class Users {

    public function index() {
        $users = $this->findUsers();
    }

    protected function findUsers($userId=null) { ... }
}

class Friends extends Users {

    public function index($userId) {
        $users = $this->findUsers($userId);
    }
}

Si vous avez des difficultés à déterminer la classe à étendre, écrivez ce que vous avez besoin dans chacune des classes et choisissez celle avec la liste la plus longue.