我正在构建一个RESTful API，用于在线程中检索和存储注释。
评论线程由任意URI标识 - 通常这是与评论线程相关的网页的URL。这种设计与Disqus与他们的系统非常相似。
这样，在每个网页上，查询相关的评论帖子都不需要在客户端存储任何其他数据 - 所需要的只是相关页面的规范URL。
我当前的实现尝试通过将URI编码为字符串来使URI作为资源工作，如下所示：
/comments/https%3A%2F%2Fexample.org%2Ffoo%2F2345%3Ffoo%3Dbar%26baz%3Dxyz
但是，在将其分发给我的应用程序之前，请求URI总是被我的服务器解码为
/comments/https://example.org/foo/2345?foo=bar&baz=xyz
这不起作用，因为解码后的资源名称现在有路径分隔符和查询字符串，导致我的API中的路由混淆（我的路由配置假定请求路径包含/comments/后跟一个字符串）
我可以对它们进行双重编码或使用除URI编码之外的其他编码方案，但这会增加客户端的复杂性，我试图避免这种情况。
我有两个具体问题：
我的URI设计是我应该继续使用的，还是有更好的（最好的？）练习来做我想做的事情？
我正在使用Martini'microframework'实现的Go流程提供API请求。是否有一些Go或Martini特定的东西，我应该做的是使URI编码的资源名称保持编码？ 也许是一种提示路由子系统的方法，资源名称不仅仅是一个字符串而是一个URL编码的字符串？
答案 0 :(得分：0)
我不知道你的应用程序的url方案，但单个％编码的值在url中有效代替它们代表的字符，应由服务器解码，什么你看到的就是我所期待的。如果您需要将url保留字符作为值传递，而不是将它们解码为url的一部分，则需要对它们进行双重编码。这是一种相当普遍的做法，增加了客户端的复杂性。服务器不会那么多，简短的评论也会正确。
简而言之，如果您需要传递url字符，请对它们进行双重编码，这很好。