Schéma d'URL convivial?

Question

L'une des nombreuses choses qui manquait à mon scraper service que j'ai mis en place la semaine dernière sont 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, il existe deux pages, mise à jour et graphique, qui fournissent des informations à l'utilisateur. Voici les deux possibilités que j'ai trouvé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>/mise à jour/1234
• http: // < tld>/carte/1234

ou

• http: // < tld>/1234/mise à jour
• http: // < tld>/1234/Tableau

L'option 1, conceptuellement, appelle la mise à jour avec l'ID utilisateur. L'option # 2 fournit un verbe pour opérer sur un identifiant d'utilisateur.

Du point de vue de la cohérence, quel est le plus logique?

---

Une autre option est mentionné

• http: // < tld>/user/1234/mise à jour
• http: // < tld>/user/1234/Tableau

Cela permet d'avoir de la place pour les pages ne concernant pas un utilisateur spécifique. à savoir

• http: // <> tld/Statistiques

Answer 1

Je serais légèrement enclin à diriger avec l'ID utilisateur - option # 2 - puisque (ce qui existe de) la structure de répertoire est deux fonctions différentes sur les données d'un utilisateur. C'est le graphique de l'utilisateur et la mise à jour de l'utilisateur.

C'est un point mineur, cependant, sans savoir s'il y a des plans pour une expansion significative de la fonctionnalité de cette chose.

• Est-ce que tout va aller de l'avant avec des fonctions supplémentaires foo et bar et baz pour les utilisateurs individuels? Si c'est le cas, l'option n ° 2 devient plus attrayante pour la raison ci-dessus - l'ID utilisateur est les données de base, il est logique de commencer sémantiquement.
• Allez-vous ajouter une fonctionnalité non-pilotée par l'utilisateur? L'interlocuteur avec un répertoire d'en-tête peut avoir du sens, puis -/user/1234/update,/user/1234/chart,/question/45678/activity,/question/45678/stats, etc

Answer 2

Personnellement, je aime ce style, car il garde l'utilisateur même, mais vous donne un aperçu spécifique pour eux.

• http: // < tld>/1234/mise à jour
• http: // < tld>/1234/Tableau

Si vous êtes allé dans l'autre sens, je pense pouvoir voir tout sous/update ou/chart et ensuite resserrer par utilisateur.

Answer 3

L'option 1 correspond aux exemples communs ASP.NET MVC. Certains exemples du modèle Model View Controller ont la forme {controller}/{action}/{id}.Le .NET 3.5 quickstart on routing a un tableau des modèles d'itinéraire valides:

Route définition - Exemple d'URL correspondant à

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

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

blog/{action}/{entrée} -/blog/show/123

{ReportType}/{année}/{mois}/{jour} -/ventes/2008/1/5

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

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

Answer 4

Je suis d'accord sur le plan de contexte, l'application suivie par les paramètres de sens beaucoup plus pour moi que la clé de substitution pour un article suivi du contexte de l'objet. En fin de compte, je suggérerais ce qui est le plus naturel pour vous de programmer.

Answer 5

dernier; Les URL sont censées être hiérarchiques (ou, du moins, les utilisateurs les lisent par analogie avec les chemins de répertoire locaux). L'accent est mis ici sur différentes vues d'un utilisateur spécifique, de sorte que "user" est le concept le plus général et devrait apparaître en premier.

Answer 6

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

http: // < tld>/user/mise à jour/1234

(je viens de remarquer qui correspond à votre question :) mise à jour

Alors oui, # 3 est le meilleur choix.

Cela soutient les opérations non-utilisateur que vous mentionnez (stats /), ainsi que les opérations multi-utilisateurs:

http: // < tld>/user/liste/

Answer 7

Je viens répondu à la question "How do you structure your URL routes?" avec mes opinions sur la façon de rendre les URLs RESTful, Hackable et conviviale. Je pense qu'il serait préférable de lier que d'écrire quelque chose de similaire dans cette question, d'où le lien.

Answer 8

Si vous allez avec ce schéma, il devient simple d'arrêter (sage) des robots de spidering votre site:

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

En effet, vous pourriez installer un fichier robots.txt pour contenir:

Disallow /update/ 
Disallow /chart/ 

Pour moi c'est un bon bonus qui est souvent négligé.

Answer 9

S'il y a un moyen d'utilisateurs liste Je vous présente 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 vos propres détails, à savoir les utilisateurs sont invisibles à l'autre, vous n'avez pas besoin de l'utilisateur id puisque vous pouvez déduire de la session, dans quel cas:

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