分层URL与平面URL

我有一个类似航班>座位>预订的资源结构，因此预订属于属于某个航班的某个座位：

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

http://example.com/reservation/jMBDy46PbNc                     

因为客户得到这个（有点丑陋）URL以供稍后取消，我考虑省略资源结构并缩短到预订的链接：

http://example.com/reservation/jMBDy46PbNc                     

---

您是否认为有任何原因（与用户相关）不缩短此URL

最终用户不太关心URL结构是什么。事实上，考虑到它们在那里的样子，它们几乎肯定不想看它们，而只是点击。这只剩下功能方面的考虑

http://example.com/reservation/jMBDy46PbNc                     

如果URL指向完全相同的资源，并且该资源在不同URL中的行为完全相同，那么根据定义，使用哪一个资源几乎无关紧要

http://example.com/reservation/jMBDy46PbNc                     

我想唯一真正的因素可能是是否有任何安全隐患。我能猜到预订ID吗？这能帮我找到什么地方吗（我还需要登录什么的）？如果还有座位和航班，他们就必须能够猜出这三者的有效组合，这显然比强行输入预订ID要困难得多

http://example.com/reservation/jMBDy46PbNc                     

---

如果最后一个不是问题，那么我看不出有任何理由使用更长的url…

无论您提供更长或更短的url都不是大问题，但您是否只提供其中一个或两个都是大问题。如果两个URL都返回相同的内容，则缓存中会有重复的信息（无论是服务器端、中间层还是客户端），并且这两个资源之间可能会不同步，特别是在缓存时间不同的情况下。理想情况下，你应该提供一个或另一个。如果您真的想同时提供这两种服务，您应该将其中一个重定向到另一个，而不是复制它。

假设URL将执行完全相同的操作，那么它们肯定可以互换吗？只有你能告诉我们他们是否真的做了同样的事情是的，URL是可互换的，并且会产生完全相同的资源。因此，我认为没有理由不缩短URL。：）我现在正在使用短变体。

http://example.com/reservation/jMBDy46PbNc