How to use URI as a REST resource?

huangapple go评论77阅读模式
英文:

How to use URI as a REST resource?

问题

我正在为检索和存储线程中的评论构建一个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编码的字符串?

英文:

I am building a RESTful API for retrieving and storing comments in threads.

A comment thread is identified by an arbitrary URI -- usually this is the URL of the web page where the comment thread is related to. This design is very similar to what Disqus uses with their system.

This way, on every web page, querying the related comment thread doesn't require storing any additional data at the client -- all that is needed is the canonical URL to the page in question.

My current implementation attempts to make an URI work as a resource by encoding the URI as a string as follows:

/comments/https%3A%2F%2Fexample.org%2Ffoo%2F2345%3Ffoo%3Dbar%26baz%3Dxyz

However, before dispatching it to my application, the request URI always gets decoded by my server to

/comments/https://example.org/foo/2345?foo=bar&baz=xyz

This isn't working because the decoded resource name now has path delimiters and a query string in it causing routing in my API to get confused (my routing configuration assumes the request path contains /comments/ followed by a string).

I could double-encode them or using some other encoding scheme than URI encode, but then that would add complexity to the clients, which I'm trying to avoid.

I have two specific questions:

  1. Is my URI design something I should continue working with or is there a better (best?) practice for doing what I'm trying to do?

  2. I'm serving API requests with a Go process implemented using Martini 'microframework'. Is there something Go or Martini specific that I should do to make the URI-encoded resource names to stay encoded?
    Perhaps a way to hint to the routing subsystem that the resource name is not just a string but a URL-encoded string?

答案1

得分: 0

我不了解你的应用程序的URL方案,但是在URL中,单个%编码的值是有效的,可以代替它们所表示的字符,并且服务器应该对其进行解码。你所看到的是我所期望的结果。如果你需要将URL保留字符作为值传递,并且不希望它们作为URL的一部分进行解码,你需要对它们进行双重%编码。这是一个相当常见的做法,对客户端和服务器增加的复杂性并不大,只需要添加一个简短的注释即可。

简而言之,如果你需要传递URL字符,请对它们进行双重%编码,这是可以的。

英文:

I don't know about your url scheme for your application, but single % encoded values are valid in a url in place of the chars they represent, and should be decoded by the server, what you are seeing is what I would expect. If you need to pass url reserved characters as a value and not have them decoded as part of the url, you will need to double % encode them. It's a fairly common practice, the complexity added to the client & server will not be that much, and a short comment will do rightly.

In short, If you need to pass url chars, double % encode them, it's fine.

huangapple
  • 本文由 发表于 2014年4月20日 15:20:38
  • 转载请务必保留本文链接:https://go.coder-hub.com/23179552.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定