Je donne des promotions aux utilisateurs qui nous envoient d'autres visiteurs. Ceci est fait sur le côté du client Je peux faire cela en utilisant des paramètres dynamiques d'obtenir, par exemple. Y a-t-il des avantages et des inconvénients pour l'une de ces méthodes? http://www.mysite.com?app_source=user_id ou je peux le faire à l'aide du hachage, par exemple http: //www.mysite.com#app_source ,user_id .
9 Réponses :
Le moyen standard de le faire pour une demande d'obtention serait de simplement utiliser une chaîne de requête.
http://www.mysite.com#app_source,user_id
Ceci est un script tiers. Redirections - et analyse des arguments dynamiques avant la redirection - ne sont pas possibles. D'autres scripts tiers, comme AddChis, utilisent les paramètres de hachage et non dynamiques.
Sur la base de certaines applications Web modernes qui ont promu le signe "#" est très utile pour prendre en charge le spa (application à une seule page) comme Twitter. S'il vous plaît utiliser simplement le "?" signe.
Si le site Web redirigea vers une autre page, je perdrez les paramètres dynamiques, mais je ne perdrai pas les informations de hachage. Voir FB.com/#sttuff à titre d'exemple
@Camelcamelcamel, j'ai abordé votre préoccupation de redirection dans ma réponse.
C'est pourquoi je vous ai suggéré d'utiliser le? Obtenir le signe des paramètres et non le # hachage. Bonne chance.
Eh bien, si vous y réfléchissez vraiment. Peu importe si vous allez utiliser le? Obtenez le paramètre ou le hachage #, quelque part, vous ferez une demande Ajax pour faire face à des sessions et mettre à jour votre base de données, mettez ainsi à jour votre état de l'application. Les ? Obtenir le paramètre est tout simplement plus naturel pour moi et peut-être pour la plupart des développeurs.
Plus Sémantican moyen de manipuler est probablement via un paramètre de chaîne de requête, mais ce n'est pas très fort. Si aucun des points énumérés ci-dessus n'est pertinent, je resterais probablement simplement avec des chaînes de requête, car il est plus courant.
Si vous voulez dire que vous construisez un service que d'autres personnes s'intègrent et que vous ne souhaitaez pas qu'ils devaient adopter des informations à leur application (via la chaîne de requête), utilisez les params de hachage semble être une option solide. < / p>
Utilisez l'approche Semantitique et les meilleures pratiques de côté, il y a aussi une raison pratique pour cela . Pensez à ce qui se passe lorsqu'un utilisateur envoie un visiteur à une ancre sur une page. Vous ne seriez pas en mesure d'utiliser l'approche de hachage (au moins pas de manière simple). Donc, je suivrais que l'approche décrite ici : alors vous pouvez avoir des URL comme ceci: ? . Pourquoi? Parce que c'est comme ça que vous devriez passer des données arbitraires à travers les pages. # est spécifiquement utilisé pour les ancres de la page. http : //www.mysite.com? App_source = user_id # anchor
w3c dit ici :
Naturellement, il n'est pas possible de s'assurer que le serveur ne fonctionne pas générer des effets secondaires à la suite de l'exécution d'une demande d'obtention; dans Fait, certaines ressources dynamiques considèrent qu'une fonctionnalité. L'important distinction ici est que l'utilisateur n'a pas demandé les effets secondaires, donc donc ne peut donc pas être tenu responsable pour eux.
Aucune de vos méthodes n'est bonne. Le moyen ultime de le faire est d'utiliser des segments d'URL:
Si vous souhaitez différencier par application et userid: p> ou uniquement par ID utilisateur: p> xxx pré> Mais je voudrais personnellement passer par AppName et Nom d'utilisateur: p> http://www.mysite.com/appName/UserName/
Totalement tort - il développe un plugin JavaScript 3ème partie et ne veut pas gâcher l'URL de l'application. Vous ne savez même pas si cette application ne lancera pas 404 Erreur lors de votre approche.
@ Maciejpyszyński Vous n'êtes pas sûr de ce que vous entendez par «gâchis», également 404 est lancé sur le serveur et n'a rien à voir avec JavaScript.
Oui. faire si la base URL est quelquepage.com/page-ulrname et seulement ce format URL est pris en charge par App et ce gars développe un plugin tiers de 3ème partie, il ne peut donc pas ajouter de paramètres à l'URL. Autre cas, c'est lorsque l'application utilise le paramètre Appname, il peut donc fournir une mauvaise entrée. Un autre est le hachage peut être utilisé sur chaque page, sans aucune défaute (si l'application n'utilise pas de hasch pour restaurer un état)
Eh bien, maintenant vous m'avez complètement perdu parce que je ne comprends pas votre anglais. Essayez de formuler vos phrases de manière plus claire.
Désolé était à la dépêche. Si URL de base est quelquepage.com/[Gage-ulRName] et ce format supporté uniquement. Vous obtiendrez 404 erreur. De plus, ce gars développe un plug-in 3ème partie, il ne peut donc pas ajouter de paramètres à l'URL ou à appliquer l'équipe de dev. Nous courons dans un autre problème lorsque l'application utilise le paramètre "AppName", il peut donc fournir une mauvaise entrée (par URL). Le hachage peut également être utilisé sur chaque page, sans aucun défaut (si l'application n'utilise pas de hachage pour restaurer un État)
Si OP n'a pas de contrôle sur l'URL, ma réponse n'est pas pertinente.
Le moyen simple consiste à utiliser un paramètre d'obtention avec un ID utilisateur pour vérifier s'il a été référé par une personne.
http://www.mysite.com/?ref=1128721
Utilisez hachage.
pourquoi?
Parce que vous développez un plug-in 3ème partie, et ne savez pas si l'un des arguments ne sont pas utilisateurs par les développeurs de sites. Lorsque vous remplacez l'un des paramètres d'utilisation utilisés, vous pouvez détruire des informations importantes transmises au serveur par APP Devs. De plus, vous ne voulez pas faire du titulaire de l'application ayant des pages dupliquées telles que: http://somepage.com/ et http://somepage.com/?app_source=user_id sera des duplicats et autant d'utilisateurs renvoient cette page, Vous en créerez beaucoup.
HASH est l'option la plus sûre et peut être utilisée sur chaque page.
hachage est la voie à suivre.
Il n'y a que 2 choix, on obtient le paramètre et 2ème est #.
Le paramètre GET peut être indexé par le moteur de recherche et deux URL sur l'un de mes sites que j'ai utilisé cela et je reçois des courriels de Google indiquant
Les liens qu'ils ont mentionnés fonctionnent correctement sans aucun problème, mais je suis toujours commencé à obtenir ces erreurs.
Les hachages sont meilleurs car ils ne changent pas le comportement d'une chose de référencement (beaucoup de PPL diront que cela a un impact mais je ne le pense pas)
à la fin, il vous suffit de recevoir le http://www.yoursite.com/ et http://www.yoursite.com/?app_id=123 peut être 2 pages séparées
Tout en rampant votre site, nous avons constaté une augmentation du nombre d'erreurs transitoires SOFT 404 autour de 2012-06-30 22:00 UTC (Londres, Dublin, Édimbourg). Votre site peut avoir des pannes expérimentées. Ces problèmes ont peut-être été résolus. Voici quelques exemples de pages qui ont abouti à des erreurs Soft 404:
app_source et pour le transmettre à votre serveur à l'aide de JavaScript. Donc, vous pouvez comme ce que vous aimez. Si j'étais toi, j'utiliserais superdément hachage
Comment le suivi est-il accompli s'il est fait du côté du client?
Ceci est une application tierce partie. Nous analysons l'objet
document.location et post sur nos serveurs, tout comme Google Analytics