分层 URL 与扁平 URL

发布于 2024-12-24 21:48:09 字数 474 浏览 1 评论 0原文

我有一个资源结构,例如 Flight >座位>预订,因此预订属于某个航班的某个座位:

http://example.com/jdf_3prGPS4/1/jMBDy46PbNc
                   ----------- - -----------
                        |      |       |
                        |      |       |
                     flight  seat  reservation

由于客户获取此(有点难看)URL以便稍后取消,我考虑省略资源结构并缩短预订的链接:

http://example.com/reservation/jMBDy46PbNc                     

您看到任何不缩短此 URL 的原因(与用户相关)?

I have a resource structure like flight > seat > reservation, so a reservation belongs to a certain seat which belongs to a certain flight:

http://example.com/jdf_3prGPS4/1/jMBDy46PbNc
                   ----------- - -----------
                        |      |       |
                        |      |       |
                     flight  seat  reservation

Since the customer gets this (somewhat ugly) URL for later cancellation I consider to leave out the resource structure and shorten the link to the reservation:

http://example.com/reservation/jMBDy46PbNc                     

Do you see any reasons (relevant to the user) not to shorten this URL?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

A君 2024-12-31 21:48:09

最终用户不太关心 url 结构是什么。事实上,考虑到它们在那里的样子,他们几乎肯定甚至不想看它们,而只是点击一下。这实际上只留下了功能上的考虑。

如果 URL 指向完全相同的资源,并且该资源在不同的 URL 下表现完全相同,那么几乎根据定义,您使用哪一个都无关紧要。

我想唯一真正的因素可能是是否存在任何安全隐患。我能猜出预订 ID 吗?这可以让我到达任何地方吗(即我是否仍然需要登录或其他什么)?如果还有座位和航班,他们就必须能够猜测这三者的有效组合,这显然比暴力破解预订 ID 困难得多。

如果最后一个不是问题,那么我看不出有任何理由使用更长的网址......

The end user doesn't much care what the urls structure is. In fact given what they look like there they almost certainly don't even want to look at them and instead just clicky-click. This only really leaves functional considerations.

If the URLs lead to exactly the same resource and that resource behaves exactly the same with the different urls then almost by definition it doesn't matter which one you use.

I guess the only real factor might be whether there are any security implications. Would I be able to guess reservation IDs? Does that get me anywhere (ie would I still need to log in or something)? If there is a seat and flight as well they would have to be able to guess a valid combination of all three which is obviously a lot harder than just brute forcing the reservation ID.

If this last is not a concern then I don't see any reason to ever use the longer url...

半﹌身腐败 2024-12-31 21:48:09

提供较长或较短的 URL 都不是大问题,但仅提供其中一个或两者都是大问题。如果两个 URL 返回相同的内容,那么您的缓存中将会有重复的信息(无论是服务器端、中间层还是客户端),并且这些信息可能会在两个资源之间不同步,尤其是当它们缓存在不同的位置时。一生。理想情况下,您应该提供其中之一。如果您确实想同时提供两者,则应该将一个重定向到另一个,而不是重复它。

Whether you offer the longer or shorter URL is not a big issue, but whether you offer only one of them or both of them is. If both URL's return the same content, then you will have duplicate information in your caches (whether server-side, intermediary, or client-side), and these can get out of sync between the two resources, especially if they are cached at different lifetimes. Ideally, you should offer one or the other. If you really want to offer both, you should have one redirect to the other instead of duplicating it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文