当需要一些复杂的参数时，设计 HTTP 请求的最佳方法是什么? [英] What is the best way to design a HTTP request when somewhat complex parameters are needed?
问题描述
我正在编写一些 Web 服务，并且我正在尝试尽可能地使用 RESTful.我使用在 IIS/ASP.NET/SharePoint 内部运行的 HTTPHandler 托管这些 Web 服务.
I have some web services that I am writing and I am trying to be as RESTful as possible. I am hosting these web services using a HTTPHandler running inside of IIS/ASP.NET/SharePoint.
我的大部分服务都需要 HTTP GET.我有两个只是返回一些数据(即查询)并且将是 Idempotent，但参数可能有些复杂.它们都可以在服务的参数中包含至少在 URL 的 PATH 部分不允许的字符.
Most of my services expect a HTTP GET. I have two of these that are simply returning some data (i.e., a query) and will be Idempotent, but the parameters may be somewhat complex. Both of them could include characters in the parameters of the service that are not allowed for at least the PATH portion of the URL.
使用 IIS、ASP.NET 和 SharePoint 我发现 URL 路径中的以下字符甚至没有进入我的 HttpHandler 即使 URL 编码(请求爆炸，我没有任何简单的控制在这个):
Using IIS, ASP.NET, and SharePoint I have found that the following characters in the URL path don't even make it to my HttpHandler even if Url encoded (the request blows up and I don't have any easy control over this):
- % (%25)
- &(%26)
- *(%2a，但未进行 Url 编码)
- + (%2b)
- :(%3a)
- <(%3c)
(%3e)
以下字符进入了我的 HttpHandler，但即使 Url 编码，UriTemplate 也无法正确处理它们:
The following characters made it to my HttpHandler, but the UriTemplate could not handle them properly even if Url encoded:
(%23)
- .(%2e，但没有进行 Url 编码；UriTemplate 删除了."，如果是/之前的最后一个字符)
- ?(%3f)
- /(%2f - 即使 UrlEncoded，UriTemplate 由于明显原因失败)
- (%5c)
所以，我已经有点彻底了，但是我需要在查询字符串中测试这些 url 编码的字符.看来这在大多数情况下都会起作用.
So, I've been somewhat thorough, but I need to test these url encoded characters in the query string. It appears that this will work for the most part there.
在我的一项服务中，作为参数的特殊字符在语义上是查询/过滤器的一部分(实际上是搜索服务的搜索词)，但在另一个服务中，它们实际上并不是查询/过滤器的一部分，因此理想情况下它们是路径的一部分，而不是查询字符串.
In one of my services, the special characters that are a parameter are semantically part of a query/filter (actually search terms for a search service), but in another they are not really part of a query/filter so ideally they are part of the path and not the query string.
我的问题是，什么选择最好?以下是我所知道的:
My question is, what option is best? Here are some I know of:
使用 HTTP GET 和查询字符串.任何可能使用特殊字符的内容都应该在查询字符串和 URL 编码中.这是我倾向于的地方，但我担心超长的查询字符串(IE 有 2083 个限制)
Use HTTP GET and query string. Anything that may use special characters should be on the query string and Url Encoded. This is where I am leaning, but I am concerned about extremely long query strings (IE has a 2083 limit)
在路径中使用 HTTP GET 和 base64 编码. 使用 修改了 URL 的 Base64 用于可能使用特殊字符的任何参数，如果愿意，将它们保留为路径的一部分.我已经尝试过这个并且它有效，但它有点难看.仍然担心超长的查询字符串.
Use HTTP GET and base64 encoding within path. Use a Modified Base64 for URL for any parameters that might use special characters and keep them as part of the path if preferred. I have tried this and it works, but it is kind of ugly. Still a concern about extremely long query strings.
使用 HTTP POST 和消息正文.任何可能使用特殊字符的内容都应包含在请求正文中.似乎是一个不错的解决方案，但帖子被理解为不是Idempotent 和(我认为)通常用于更改(而此处没有发生更改).
Use HTTP POST and message body. Anything that may use special characters should be in the body of the request. Seems like a decent solution, but posts are understood to not be Idempotent and (I thought) are generally meant for changes (whereas no change is occurring here).
使用 HTTP GET 和消息正文.任何可能使用特殊字符的内容都应该在请求正文中.根据 SO: HTTP GET with request body 和
Use HTTP GET and message body. Anything that may use special characters should be in the body of the request. This seems like a bad idea according to SO: HTTP GET with request body and Roy Fielding.
根据请求的大小，使用 #3 和 #1 或 #2 的组合.
Use a combination of #3 and either #1 or #2 above depending on how large the request can be.
其他???
请注意，在某些情况下，我可以更改一些内容以防止出现特殊字符(我可能会这样做)，但我无法在所有情况下都这样做.
Note that in some cases I may be able to change things around to prevent special characters (and I may do that), but I won't be able to do this in all cases.
关于 URI 长度，RFC2616 Sec3.2.1说如下:
Regarding URI length, RFC2616 Sec3.2.1 says the following:
HTTP 协议没有对 URI 的长度设置任何先验限制.服务器必须能够处理它们所服务的任何资源的 URI，并且如果它们提供可以生成此类 URI 的基于 GET 的形式，则它们应该能够处理无限制长度的 URI.如果 URI 的长度超出了服务器的处理能力，服务器应该返回 414(Request-URI Too Long)状态(参见 10.4.15 节).
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
此外，Internet Explorer 中的最大 URL 长度为 2,083 个字符.
推荐答案
我建议您阅读 HTTP 1.1 规范，尤其是部分3.2 统一资源标识符和9.1.1 安全方法.这些内容有望回答您的问题.
I recommend you to read the HTTP 1.1 specification, especially the sections 3.2 Uniform Resource Identifiers and 9.1.1 Safe Methods. Those will hopefully answer your question.
以下是一些附加信息:
这篇关于当需要一些复杂的参数时，设计 HTTP 请求的最佳方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
