I'm giving promotions to users who sends us other visitors. This is done on the client side.
我正在向向我们发送其他访问者的用户进行促销活动。这是在客户端完成的。
I can do this using dynamic GET parameters, e.g. http://www.mysite.com?app_source=user_id or I can do this using the hash, e.g. http://www.mysite.com#app_source,user_id.
我可以使用动态GET参数来完成此操作,例如: http://www.mysite.com?app_source=user_id或我可以使用哈希,例如HTTP://www.mysite.com#app_source,user_id。
Are there any pros and cons for any of these methods?
这些方法有任何优缺点吗?
9 个解决方案
#1
5
Query String
- Google Analytics, server logs, et al will have a record of the URL, which may be beneficial for later analysis.
- Multiple URLs make caching harder and have a slight chance of confusing the Google
Google Analytics,服务器日志等都会记录网址,这可能有助于以后的分析。
多个网址会使缓存更加困难,并且很可能会让Google感到困惑
Hash
- Analytics and server logs will not see/pay attention to hash params
分析和服务器日志不会看到/关注哈希参数
The more semantic way of handling this is probably through a query string parameter, but it's not very strong. If none of the above-listed points is relevant, I would probably just stick with query strings because it is more common.
处理这种情况的更多语义方式可能是通过查询字符串参数,但它不是很强。如果上面列出的点都不相关,我可能会坚持使用查询字符串,因为它更常见。
If you mean that you are building a service that other people integrate, and you don't want them to have to pass information back to their application (via query string), then using hash params seems like a solid option.
如果您的意思是构建其他人集成的服务,并且您不希望他们必须将信息传递回他们的应用程序(通过查询字符串),那么使用哈希参数似乎是一个可靠的选项。
#2
8
The standard way to do this for a GET request would be to simply use a query string.
为GET请求执行此操作的标准方法是简单地使用查询字符串。
http://www.mysite.com?app_source=user_id
If you use a URL anchor such as
如果您使用URL锚点,例如
http://www.mysite.com#app_source,user_id
The anchor portion (#app_source,user_id) is not sent to the server
锚部分(#app_source,user_id)不会发送到服务器
For example, see this related question.
例如,请参阅此相关问题。
Here's another related question
这是另一个相关的问题
The anchor is merely a client-side flag to tell the browser where to navigate on the page.
锚点只是一个客户端标志,用于告诉浏览器在页面上导航的位置。
To address your redirect concerns, you can process the query string before redirecting, add/remove and key/value pairs you want, and then redirect.
要解决重定向问题,可以在重定向,添加/删除和所需的键/值对之前处理查询字符串,然后重定向。
PHP gives you direct access to the query string with $_SERVER['QUERY_STRING']
PHP允许您使用$ _SERVER ['QUERY_STRING']直接访问查询字符串
Rails uses request.uri which you can parse
Rails使用您可以解析的request.uri
Also, when you see fanciful things like facebook.com/#stuff, the anchor portion is handled with client-side javascript. So you can do this, but you'll be writing ajax code that is sending normal GET requests like the one recommended at the top of this answer.
此外,当你看到像facebook.com/#stuff这样的奇怪的东西时,锚点部分是用客户端javascript处理的。所以你可以这样做,但是你将编写一个正在发送普通GET请求的Ajax代码,就像在这个答案的顶部推荐的那样。
Why add complexity? Do you just like the look of the # better than the ? ?
为何增加复杂性?你喜欢#比#更好的外观吗? ?
#3
7
Use the ? approach. Why? Because that's how you should pass arbitrary data across pages.
使用 ?做法。为什么?因为这就是你应该如何在页面之间传递任意数据。
# is specifically used for page anchors.
#专门用于页面锚点。
Semantics and best practices aside, there is also a practical reason for this. Think about what happens when a user sends a visitor to an anchor on a page. You would not be able to use the hash approach (at least not in a simple way).
除了语义和最佳实践之外,还有一个实际的原因。想想当用户将访问者发送到页面上的锚点时会发生什么。您将无法使用哈希方法(至少不是以简单的方式)。
So I would follow the approach outlined here:
所以我会按照这里概述的方法:
function $_GET(q,s) {
s = s ? s : window.location.search;
var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}
var app_source = $_GET('app_source');
Then you can have URLs like this: http://www.mysite.com?app_source=user_id#anchor
然后你可以拥有这样的网址:http://www.mysite.com?app_source = user_id #anchor
#4
3
W3C says here:
W3C在这里说:
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
当然,不可能确保服务器不会因执行GET请求而产生副作用;实际上,一些动态资源会考虑一个功能。这里的重要区别是用户没有请求副作用,因此不能对他们负责。
#5
3
Use HASH.
Why?
Because you develop 3rd party plugin, and don't know if any of the arguments are NOT user by site developers. When you override one of used get parameters, you can destroy some important information passed to the server by native app devs. Also you don't want to make app holder having duplicated pages like: http://somepage.com/ and http://somepage.com/?app_source=user_id will be duplicates and as many users will refer that page, you will create many of them.
因为您开发了第三方插件,并且不知道网站开发人员是否有任何参数不是用户。当您覆盖其中一个使用过的get参数时,您可以销毁本机应用程序开发人员传递给服务器的一些重要信息。此外,您不希望让应用持有者拥有重复的页面,如:http://somepage.com/和http://somepage.com/?app_source=user_id将是重复的,并且很多用户将引用该页面,您将创造了许多。
Hash is the most safe option and can be used on every page.
哈希是最安全的选项,可以在每个页面上使用。
#6
2
Hash is the way to go.
哈希是要走的路。
There are only 2 choices, one is GET Parameter and 2nd is #.
只有2个选项,一个是GET参数,第二个是#。
? GET PARAMETER
?得到参数
The get parameter can be indexed by search engine and two URLs http://www.yoursite.com/ and http://www.yoursite.com/?app_id=123 can be 2 seperate pages
get参数可以由搜索引擎索引,两个URL http://www.yoursite.com/和http://www.yoursite.com/?app_id=123可以是2个单独的页面
On one of my sites I have used this and I get emails from google stating While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:
在我的一个网站上,我使用了这个,我收到来自谷歌的电子邮件说明在抓取您的网站时,我们注意到2012-06-30 22:00 UTC(伦敦,都柏林,爱丁堡)的瞬态软404错误数量增加)。您的网站可能遇到过停机。这些问题可能已得到解决。以下是一些导致软404错误的示例页面:
The links they mentioned are working properly without any issue, but still I am started to get these errors.
他们提到的链接正常工作没有任何问题,但我仍然开始得到这些错误。
# HASH
Hashes are better as they dont change the behavior of any SEO thing (many ppl will say that it does have impact but i dont think so)
哈希是更好的,因为他们不改变任何SEO的行为(很多人会说它确实有影响,但我不这么认为)
At the end you just need to get the app_source and to pass it to your server using Javascript. So you can as what you like. If I were you, i would surly use HASH
最后,您只需要获取app_source并使用Javascript将其传递给您的服务器。所以你可以随心所欲。如果我是你,我会狡猾地使用HASH
#7
1
Neither of your methods are good. The ultimate way to do this is to use URL Segments:
你的方法都不好。最好的方法是使用URL Segments:
If you want to differentiate by App and UserId:
如果您想通过App和UserId进行区分:
http://www.mysite.com/appName/UserID/
Or only by UserId:
或者仅由UserId:
http://www.mysite.com/UserID/
But I personally would go by both AppName and UserName:
但我个人会同时使用AppName和UserName:
http://www.mysite.com/appName/UserName/
#8
0
Based on some modern web applications today that have promoted the "#" sign is very useful to support SPA (Single Page Application) like Twitter. Please just use the "?" sign.
基于今天推出“#”符号的一些现代Web应用程序对于支持像Twitter这样的SPA(单页应用程序)非常有用。请使用“?”标志。
#9
0
The simple way is to use a GET parameter with a userID to verify if it's been referred by someone.
简单的方法是使用带有userID的GET参数来验证它是否被某人引用。
http://www.mysite.com/?ref=1128721
Then if you want to know more about the referral, you can also check from which url the user actually clicked your link by using $_SERVER['HTTP_REFERER'] (if you use php). This way, you can ensure that your link wasn't in a junk place or "auto-visited".
然后,如果您想了解有关推荐的更多信息,您还可以使用$ _SERVER ['HTTP_REFERER'](如果您使用php)检查用户实际点击您的链接的网址。这样,您可以确保您的链接不在垃圾场或“自动访问”。
#1
5
Query String
- Google Analytics, server logs, et al will have a record of the URL, which may be beneficial for later analysis.
- Multiple URLs make caching harder and have a slight chance of confusing the Google
Google Analytics,服务器日志等都会记录网址,这可能有助于以后的分析。
多个网址会使缓存更加困难,并且很可能会让Google感到困惑
Hash
- Analytics and server logs will not see/pay attention to hash params
分析和服务器日志不会看到/关注哈希参数
The more semantic way of handling this is probably through a query string parameter, but it's not very strong. If none of the above-listed points is relevant, I would probably just stick with query strings because it is more common.
处理这种情况的更多语义方式可能是通过查询字符串参数,但它不是很强。如果上面列出的点都不相关,我可能会坚持使用查询字符串,因为它更常见。
If you mean that you are building a service that other people integrate, and you don't want them to have to pass information back to their application (via query string), then using hash params seems like a solid option.
如果您的意思是构建其他人集成的服务,并且您不希望他们必须将信息传递回他们的应用程序(通过查询字符串),那么使用哈希参数似乎是一个可靠的选项。
#2
8
The standard way to do this for a GET request would be to simply use a query string.
为GET请求执行此操作的标准方法是简单地使用查询字符串。
http://www.mysite.com?app_source=user_id
If you use a URL anchor such as
如果您使用URL锚点,例如
http://www.mysite.com#app_source,user_id
The anchor portion (#app_source,user_id) is not sent to the server
锚部分(#app_source,user_id)不会发送到服务器
For example, see this related question.
例如,请参阅此相关问题。
Here's another related question
这是另一个相关的问题
The anchor is merely a client-side flag to tell the browser where to navigate on the page.
锚点只是一个客户端标志,用于告诉浏览器在页面上导航的位置。
To address your redirect concerns, you can process the query string before redirecting, add/remove and key/value pairs you want, and then redirect.
要解决重定向问题,可以在重定向,添加/删除和所需的键/值对之前处理查询字符串,然后重定向。
PHP gives you direct access to the query string with $_SERVER['QUERY_STRING']
PHP允许您使用$ _SERVER ['QUERY_STRING']直接访问查询字符串
Rails uses request.uri which you can parse
Rails使用您可以解析的request.uri
Also, when you see fanciful things like facebook.com/#stuff, the anchor portion is handled with client-side javascript. So you can do this, but you'll be writing ajax code that is sending normal GET requests like the one recommended at the top of this answer.
此外,当你看到像facebook.com/#stuff这样的奇怪的东西时,锚点部分是用客户端javascript处理的。所以你可以这样做,但是你将编写一个正在发送普通GET请求的Ajax代码,就像在这个答案的顶部推荐的那样。
Why add complexity? Do you just like the look of the # better than the ? ?
为何增加复杂性?你喜欢#比#更好的外观吗? ?
#3
7
Use the ? approach. Why? Because that's how you should pass arbitrary data across pages.
使用 ?做法。为什么?因为这就是你应该如何在页面之间传递任意数据。
# is specifically used for page anchors.
#专门用于页面锚点。
Semantics and best practices aside, there is also a practical reason for this. Think about what happens when a user sends a visitor to an anchor on a page. You would not be able to use the hash approach (at least not in a simple way).
除了语义和最佳实践之外,还有一个实际的原因。想想当用户将访问者发送到页面上的锚点时会发生什么。您将无法使用哈希方法(至少不是以简单的方式)。
So I would follow the approach outlined here:
所以我会按照这里概述的方法:
function $_GET(q,s) {
s = s ? s : window.location.search;
var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}
var app_source = $_GET('app_source');
Then you can have URLs like this: http://www.mysite.com?app_source=user_id#anchor
然后你可以拥有这样的网址:http://www.mysite.com?app_source = user_id #anchor
#4
3
W3C says here:
W3C在这里说:
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
当然,不可能确保服务器不会因执行GET请求而产生副作用;实际上,一些动态资源会考虑一个功能。这里的重要区别是用户没有请求副作用,因此不能对他们负责。
#5
3
Use HASH.
Why?
Because you develop 3rd party plugin, and don't know if any of the arguments are NOT user by site developers. When you override one of used get parameters, you can destroy some important information passed to the server by native app devs. Also you don't want to make app holder having duplicated pages like: http://somepage.com/ and http://somepage.com/?app_source=user_id will be duplicates and as many users will refer that page, you will create many of them.
因为您开发了第三方插件,并且不知道网站开发人员是否有任何参数不是用户。当您覆盖其中一个使用过的get参数时,您可以销毁本机应用程序开发人员传递给服务器的一些重要信息。此外,您不希望让应用持有者拥有重复的页面,如:http://somepage.com/和http://somepage.com/?app_source=user_id将是重复的,并且很多用户将引用该页面,您将创造了许多。
Hash is the most safe option and can be used on every page.
哈希是最安全的选项,可以在每个页面上使用。
#6
2
Hash is the way to go.
哈希是要走的路。
There are only 2 choices, one is GET Parameter and 2nd is #.
只有2个选项,一个是GET参数,第二个是#。
? GET PARAMETER
?得到参数
The get parameter can be indexed by search engine and two URLs http://www.yoursite.com/ and http://www.yoursite.com/?app_id=123 can be 2 seperate pages
get参数可以由搜索引擎索引,两个URL http://www.yoursite.com/和http://www.yoursite.com/?app_id=123可以是2个单独的页面
On one of my sites I have used this and I get emails from google stating While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:
在我的一个网站上,我使用了这个,我收到来自谷歌的电子邮件说明在抓取您的网站时,我们注意到2012-06-30 22:00 UTC(伦敦,都柏林,爱丁堡)的瞬态软404错误数量增加)。您的网站可能遇到过停机。这些问题可能已得到解决。以下是一些导致软404错误的示例页面:
The links they mentioned are working properly without any issue, but still I am started to get these errors.
他们提到的链接正常工作没有任何问题,但我仍然开始得到这些错误。
# HASH
Hashes are better as they dont change the behavior of any SEO thing (many ppl will say that it does have impact but i dont think so)
哈希是更好的,因为他们不改变任何SEO的行为(很多人会说它确实有影响,但我不这么认为)
At the end you just need to get the app_source and to pass it to your server using Javascript. So you can as what you like. If I were you, i would surly use HASH
最后,您只需要获取app_source并使用Javascript将其传递给您的服务器。所以你可以随心所欲。如果我是你,我会狡猾地使用HASH
#7
1
Neither of your methods are good. The ultimate way to do this is to use URL Segments:
你的方法都不好。最好的方法是使用URL Segments:
If you want to differentiate by App and UserId:
如果您想通过App和UserId进行区分:
http://www.mysite.com/appName/UserID/
Or only by UserId:
或者仅由UserId:
http://www.mysite.com/UserID/
But I personally would go by both AppName and UserName:
但我个人会同时使用AppName和UserName:
http://www.mysite.com/appName/UserName/
#8
0
Based on some modern web applications today that have promoted the "#" sign is very useful to support SPA (Single Page Application) like Twitter. Please just use the "?" sign.
基于今天推出“#”符号的一些现代Web应用程序对于支持像Twitter这样的SPA(单页应用程序)非常有用。请使用“?”标志。
#9
0
The simple way is to use a GET parameter with a userID to verify if it's been referred by someone.
简单的方法是使用带有userID的GET参数来验证它是否被某人引用。
http://www.mysite.com/?ref=1128721
Then if you want to know more about the referral, you can also check from which url the user actually clicked your link by using $_SERVER['HTTP_REFERER'] (if you use php). This way, you can ensure that your link wasn't in a junk place or "auto-visited".
然后,如果您想了解有关推荐的更多信息,您还可以使用$ _SERVER ['HTTP_REFERER'](如果您使用php)检查用户实际点击您的链接的网址。这样,您可以确保您的链接不在垃圾场或“自动访问”。