У меня есть несколько веб-сервисов, которые я пишу, и я стараюсь быть как можно более RESTful. Я размещаю эти веб-службы, используя HTTPHandler, работающий внутри IIS / ASP.NET / SharePoint.

Большинство моих сервисов ожидают HTTP GET. У меня есть два из них, которые просто возвращают некоторые данные (то есть запрос) и будутидемпотент, но параметры могут быть несколько сложными. Оба они могут включать символы в параметры службы, которые не разрешены, по крайней мере, для части пути в URL-адресе.

Используя IIS, ASP.NET и SharePoint, я обнаружил, что следующие символы в пути URL даже не попадают в мой HttpHandler, даже если закодирован Url (запрос разрывается, и я не могу легко это контролировать) :

% (%25) & (%26) * (%2a, but didn't Url encode) + (%2b) : (%3a) < (%3c)

(%3e)

Следующие символы попали в мой HttpHandler, но UriTemplate не смог обработать их должным образом, даже если закодирован Url:

(%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)

Итак, я был достаточно тщателен, но мне нужно проверить эти символы, закодированные в URL, в строке запроса. Похоже, что это будет работать по большей части там.

В одном из моих сервисов специальные символы, которые являются параметром, являются семантически частью запроса / фильтра (фактически, терминами поиска для поискового сервиса), но в другом они на самом деле не являются частью запроса / фильтра, поэтому в идеале они являются частью путь, а не строка запроса.

У меня вопрос, какой вариант лучше? Вот некоторые из них, которые я знаю:

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)

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.

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

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.

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

Other???

Обратите внимание, что в некоторых случаях я могу изменить ситуацию, чтобы предотвратить использование специальных символов (и я могу это сделать), но я не смогу сделать это во всех случаях.

Что касается длины URI,RFC2616 Sec3.2.1 говорит следующее:

Протокол HTTP не устанавливает каких-либо априорных ограничений на длину URI. Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они обслуживают, и ДОЛЖНЫ иметь возможность обрабатывать URI неограниченной длины, если они предоставляют формы на основе GET, которые могут генерировать такие URI. Сервер ДОЛЖЕН вернуть статус 414 (Request-URI Too Long), если URI длиннее, чем может обработать сервер (см. Раздел 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.

В дополнениеМаксимальная длина URL-адреса составляет 2083 символа в Internet Explorer.

Related: How to pass complex queries in REST?