在为网站构建 URL 时，有哪些资源可以帮助您了解最佳实践？
这是 的后续问题为什么很多网站（MySQL）的查询参数都是非常神秘的长整数？。在安全性和可扩展性方面。请引用任何资源（在线/离线）。
This is a follow-up question to Why are the query parameters for many websites(MySQL) very cryptic long integers?. In terms of security and scalability. Please cite any resources(online/offline).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在安全性和可扩展性方面，您可以使用您想象的任何网址。
通常是人类可读性和可用性或（更常见的是）搜索引擎友好性影响 URL 构建规则。
比如说，PHP.NET 著名的 php.net/echo 功能可以快速轻松地访问功能描述。这就是创建此类网址的原因，而不是安全性。
In terms of security and scalability you can use whatever urls you imagine.
It's usually human readability and and usability or (more often) search engine friendship that affects URL building rules.
Say, PHP.NET famous php.net/echo feature giving fast and easy access to function description. That's the reason to make such urls, not security.
安全性和可扩展性与 URL 的形成方式关系不大。有些网站确实使用神秘的 URL 作为保护图片的措施（例如 Facebook），这种类型的安全性通常不受欢迎，因为每个人通过各种方式（浏览器缓存、代理缓存等）知道 URL 都可以访问所谓的受保护的内容资源。
虽然干净的 URL 有助于搜索引擎优化，但它通常意味着响应速度较慢，从而降低可扩展性。考虑一个 URL http://example.com/user/Lars，向您显示我的个人资料的个人资料页面。如果我的帐户在数据库中不是通过我的帐户名链接，而是通过代理密钥（某个任意数字） ），系统首先必须在用户表中查询我的代理键才能获取其余信息。这会降低性能，因为必须查询另一个表。
Security and scalability have little to do with the way an URL is formed. Some sites do use cryptic URLs as a measure for securing pictures (e.g. Facebook), this type of security is generally frowned upon, as everyone knowing the URL through various ways (browser cache, proxy cache, ...) can access the supposedly protected resource.
While a clean URL helps the search-engine-optimization, it usually means slower response and thus a degraded scalability. Consider an URL http://example.com/user/Lars, showing you the profile page of my profile. If my account is linked in the database not by my accountname but by a surrogate key (some arbitrary number), the system first has to query the user table for my surrogate key in order to get the rest of the information. This degrades performance, as one more table has to be queried.
虽然我完全同意 Shrapnel 上校的回答，但在某些情况下，长“神秘”ID 有助于安全性，有时甚至有助于可扩展性。 Sharelockers（RapidShare 和朋友）通常在其 URL 中使用
/ID/Filename结构来通过模糊性来增加安全性，对于某人来说，测试所有整数或常见文件名并获取敏感信息是非常容易的信息。有些人还会对他们的数据库 ID 应用某种校验和算法，这使得某人更难弄清楚底层结构并“隐藏”某些类型的信息：我敢打赌，如果 URL例如，订单是
/order/2/。使用校验和还有助于提高性能，因为您可以忽略无效 ID，甚至无需查询数据库（当有人暴力破解您的 URL 时很有用）。长 ID 有助于可扩展性，因为它们提供了更广泛的可能数字（Slashdot 曾两次成为“int(11) 对每个人来说都足够了”假设的受害者 - 抱歉找不到旧的故事），这就是为什么你现在看到 Twitter 和朋友们使用不同的方法。
当您使用更宽的 ID 时，您还可以存储更多信息，例如时间戳、创建数据库记录的 IP/主机名等，这在您运行分布式数据库设置时至关重要。查看 MongoID 类 文档以更好地了解它是如何实现的作品。
While I agree completely with Col. Shrapnel answer there are a few cases where long "cryptic" IDs contribute to security and sometimes even scalability. Sharelockers (RapidShare and friends) usually employ the
/ID/Filenamestructure in their URLs to add security through obscurity, it would be far too easy for someone to test all integers or common filenames and get access to sensitive information.Some people also apply some kind of checksum algorithm to their database IDs, this makes it harder for someone to figure out the underlying structure and "hide" certain kinds of information: I bet many people would be reluctant to pay for something online if the URL for the order was
/order/2/for instance. Using checksums can also contribute for improved performance, since you can disregard invalid IDs without even having to query the database (useful when someone is brute-forcing your URLs).Long IDs contribute to scalability, in the sense that they provide a wider range of possible numbers (Slashdot had been a victim of the "int(11) is more than enough for everyone" assumption twice - sorry can't find old story), and that's why you see Twitter and friends using different approaches nowadays.
When you use a wider ID you can also store more information, such as timestamps, IP / hostname that created the database record and so on, which can be crucial when you're running a distributed database setup. Take a look at the MongoID class documentation to get a better idea how it works.