当需要复杂的参数时，设计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服务。

我的大多数服务都期望使用HTTP GET。我有两个只是返回一些数据（即查询），并将幂等，但参数可能有点复杂。它们都可以在服务的参数中包含字符，这些字符至少不能用于URL的PATH部分。

使用IIS，ASP.NET和SharePoint我发现URL路径中的以下字符甚至不会将它传递给我的HttpHandler，即使Url编码（请求爆炸，我也没有任何简单的控制权）：

• ％（％25）


• & （％26）


• *（％2a，但没有Url编码）
  
• +（％2b）
  
• ：（％3a）
  
• < （％3c）
  

  
  

  （％3e）
  

以下字符将其添加到我的HttpHandler中，但即使Url编码，UriTemplate也无法正确处理它们：

• （％23）



• 。 （％2e，但没有Url编码; UriTemplate移除了。，如果is是/ /
  
• 之前的最后一个字符）？ （％3f）


• /（％2f - 即使UrlEncoded，UriTemplate也会因为明显的原因而失败）


• \（％5c）

所以，我已经有点彻底了，但我需要在查询字符串中测试这些URL编码字符。看来，这将在大多数情况下工作。

在我的一个服务中，作为参数的特殊字符在语义上是查询/过滤器的一部分（实际上搜索条件搜索服务），但在另一个他们并不真正的查询/过滤器的一部分，所以理想情况下，他们是路径的一部分，而不是查询字符串。

我的问题是，什么选择是最好的？以下是我所知道的一些信息：

1. 使用HTTP GET和查询字符串。特殊字符应该在查询字符串和URL编码。这是我倾向的地方，但我担心查询字符串过长（IE有2083个限制）




2. 在路径中使用HTTP GET和base64编码。使用修改后的Base64作为URL a>表示可能使用特殊字符的任何参数，并将其保留为路径的一部分（如果首选）。 我已经试过这个，它可以工作，但它有点难看。仍然担心查询字符串过长。 使用HTTP POST和邮件正文字符应该在请求的正文中。看起来像一个体面的解决方案，但职位被理解为而不是是 Idempotent 和（我认为）通常用于更改（而这里没有变化）。

使用HTTP GET和消息正文。任何可能使用特殊字符的内容都应该位于请求的正文中。根据 SO：HTTP GET with request body 和 Roy Fielding 。



3. 根据请求的大小，使用＃3和＃1或＃2的组合。

其他？请注意，在某些情况下，我可能会改变事物以防止出现特殊字符（我可能会做到这一点），但我无法在所有情况下都这样做。




---





关于URI长度， RFC2616 Sec3.2.1 说明如下：





HTTP协议不会对URI的长度进行任何先验限制。服务器必须能够处理它们所服务的任何资源的URI，并且如果它们提供可以生成这种URI的基于GET的表单，则应该能够处理无限长的URI。如果一个URI的长度超过服务器可以处理的时间，服务器应该返回414（Request-URI Too Long）状态（见10.4.15节）。



 注意：服务器应该谨慎处理高于255字节的URI长度
，因为一些较旧的客户端或代理
实现可能不能正确支持这些长度。 
  

另外 Internet Explorer中的最大URL长度为2,083个字符。




相关：< a href =https://stackoverflow.com/questions/872984/how-to-pass-complex-queries-in-rest>如何在REST中传递复杂的查询？







解决方案

我建议您阅读 HTTP 1.1规范，尤其是 3.2统一资源标识符和 9.1.1安全方法。这些将有希望回答你的问题。





---





以下是一些额外的信息：





• 权威指南GET vs POST


• URIs，可寻址性以及HTTP GET和POST的使用





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.

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.

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, but didn't Url encode)
• + (%2b)
• : (%3a)
• < (%3c)

• (%3e)

The following characters made it to my HttpHandler, but the UriTemplate could not handle them properly even if Url encoded:

• (%23)

• . (%2e, but didn't Url encode; UriTemplate removed the "." if is is the last character before a /)
• ? (%3f)
• / (%2f - UriTemplate fails for obvious reasons even if UrlEncoded)
• \ (%5c)

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:

1. 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)

2. 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.

3. 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).

4. 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.

5. Use a combination of #3 and either #1 or #2 above depending on how large the request can be.

6. Other???

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.

---

Regarding URI length, RFC2616 Sec3.2.1 says the following:

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.

In addition the Maximum URL length is 2,083 characters in Internet Explorer.

Related: How to pass complex queries in REST?

解决方案

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.

---

Here’s some additional information:

• The Definitive Guide to GET vs POST
• URIs, Addressability, and the use of HTTP GET and POST

这篇关于当需要复杂的参数时，设计HTTP请求的最佳方式是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！