•  02-07-2019
  •  | 
  •  

Question

L'une des nombreuses choses qui manque à mon service de ramassage que j'ai mis en place la semaine dernière sont les suivantes: jolies URL. À l'heure actuelle, le paramètre utilisateur est passé dans le script avec ? U = = , ce qui est un symptôme d'un piratage paresseux (que le script est certes). Cependant, j'ai pensé à le refaire et j'aimerais avoir un retour sur les options disponibles. À l'heure actuelle, deux pages, update et chart, fournissent des informations à l'utilisateur. Voici les deux possibilités que j'ai proposées. " 1234 " est le numéro d'identification de l'utilisateur. Pour des raisons techniques, le nom d'utilisateur ne peut malheureusement pas être utilisé:

  • http: // < tld > / update / 1234
  • http: // < tld > / chart / 1234

ou

  • http: // < tld > / 1234 / update
  • http: // < tld > / 1234 / chart

L'option n ° 1, conceptuellement, appelle la mise à jour avec l'ID utilisateur. L’option n ° 2 fournit un verbe pour agir sur un identifiant d’utilisateur.

Du point de vue de la cohérence, ce qui a plus de sens?

Une autre option mentionnée est

  • http: // < tld > / user / 1234 / update
  • http: // < tld > / user / 1234 / chart

Ceci laisse de la place pour les pages ne concernant pas un utilisateur spécifique. c'est-à-dire

  • http: // < tld > / stats
Était-ce utile?

La solution

Je serais légèrement enclin à diriger avec l'ID utilisateur - option n ° 2 - car (ce qui existe), la structure de répertoires est constituée de deux fonctions différentes par rapport aux données d'un utilisateur. C'est le graphique de l'utilisateur et sa mise à jour.

Cependant, c’est un point mineur, sans que nous sachions s’il est prévu d’élargir considérablement les fonctionnalités de cette solution.

  • Est-ce que tout va continuer à être des fonctions supplémentaires foo and bar and baz pour les utilisateurs individuels? Si tel est le cas, l'option n ° 2 devient plus attrayante pour la raison ci-dessus: l'ID utilisateur est la base de données, il est donc logique de commencer sémantiquement.
  • Allez-vous ajouter des fonctionnalités non pilotées par l'utilisateur? Il peut alors être utile de commencer par un répertoire d’en-tête - / user / 1234 / update, / user / 1234 / chart, / question / 45678 / activity, / question / 45678 / stats, etc.

Autres conseils

Si vous optez pour ce schéma, il devient simple d'empêcher les robots (bien comportés) d'araigner votre site: 

 http://< tld >/update/1234
 http://< tld >/chart/1234

Cela est dû au fait que vous pouvez configurer un fichier /robots.txt pour qu'il contienne: 

 Disallow /update/
 Disallow /chart/

Pour moi, c’est un bonus intéressant qui est souvent négligé.

L'option n ° 1 correspond aux exemples courants ASP.NET MVC. Certains exemples sur Contrôleur de vue de modèle modèle a la forme {contrôleur} / {action} / {id}. Démarrage rapide .NET 3.5 pour le routage contient un tableau indiquant certains modèles d'itinéraire valides:

Définition de la route - Exemple d'URL correspondante

{contrôleur} / {action} / {id} - / Produits / spectacle / boissons

{table} /Details.aspx - /Products/Details.aspx

blog / {action} / {entry} - / blog / show / 123

{reporttype} / {year} / {month} / {day} - / sales / 2008/1/5

{locale} / {action}
- / en-US / show

{langue} - {pays} / {action}
- / en-US / show

Personnellement, j'aime ce style, car il garde l'utilisateur identique, mais vous donne un aperçu spécifique de ces derniers.

  • http: // < tld > / 1234 / update
  • http: // < tld > / 1234 / chart

Si vous procédiez dans le sens opposé, je m'attendrais à pouvoir tout voir sous / update ou / chart puis à préciser par utilisateur.

Allez avec ce dernier; Les URL sont censées être hiérarchiques (ou, au moins, les utilisateurs les lisent de cette façon par analogie aux chemins de répertoire locaux). L'accent est mis ici sur différentes vues d'un utilisateur spécifique, donc & Quot; utilisateur & Quot; est le concept plus général et devrait apparaître en premier.

Je viens de répondre à la question ". vous structurez vos itinéraires d'URL? & "; ; mon opinion est de rendre les URLs RESTful, piratables et conviviales. Je pense qu'il serait préférable de créer un lien plutôt que d'écrire quelque chose de similaire dans cette question, d'où le lien.

Je suis d’accord du point de vue du contexte, l’application suivie par les paramètres me semble beaucoup plus logique que la clé de substitution d’un élément, suivie du contexte de son contenu. En fin de compte, je vous conseillerais de choisir le programme le plus naturel.

La convention dit objet / verbe / ID, il devrait donc être:

http: // < tld > / user / update / 1234

(Je viens de remarquer que cela correspond à votre question mise à jour:)

Alors oui, le n ° 3 est le meilleur choix.

Ceci prend en charge les opérations non-utilisateur lorsque vous mentionnez (stats /), ainsi que les opérations multi-utilisateur:

http: // < tld > / user / list /

S'il existe un moyen de répertorier les utilisateurs, j'aimerais introduire un segment d'utilisateurs: 

http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart

Si vous ne pouvez voir que vos propres détails, c'est-à-dire que les utilisateurs sont invisibles l'un pour l'autre, vous n'avez pas besoin de l'ID utilisateur car vous pouvez l'inférer à partir de la session. Dans ce cas: 

http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top