0

我正在构建一个 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 编码之外的其他编码方案，但这会增加客户端的复杂性，这是我试图避免的。

我有两个具体问题：

  1. 我的 URI 设计是我应该继续使用的东西，还是有更好的（最好的？）实践来做我想做的事情？

  2. 我正在通过使用 Martini“微框架”实现的 Go 进程来提供 API 请求。我应该做些什么 Go 或 Martini 来使 URI 编码的资源名称保持编码状态？也许是一种向路由子系统提示资源名称不仅仅是一个字符串而是一个 URL 编码的字符串的方法？

4

1 回答 1

0

我不知道您的应用程序的 url 方案，但是单个 % 编码值在 url 中有效，而不是它们所代表的字符，并且应该由服务器解码，您所看到的是我所期望的。如果您需要将 url 保留字符作为值传递并且不将它们作为 url 的一部分进行解码，则需要将它们加倍 % 编码。这是一种相当普遍的做法，添加到客户端和服务器的复杂性不会那么多，简短的评论就可以了。

简而言之，如果您需要传递 url 字符，请对它们进行双倍 % 编码，这很好。

于 2014-04-20T15:56:15.463 回答