ВСТУПЛЕНИЕ
Я приведу вам пример, чтобы мой вопрос был лучше понятен. Мне не нужна «помощь» в вопросах программирования, просто информация по этой теме!
ПРИМЕР
Я опробовал API для получения информации о погоде для конкретной позиции и наткнулся на проблему. Я построил свой URL для запроса данных следующим образом:
$params['q'] = $latitude .','. $longitude; // 48.14,11.58
$params['format'] = $format; //json
$params['num_of_days'] = $numOfDays; //1
$params['key'] = self::APIKEY;
$url = 'http://api.worldweatheronline.com/free/v1/weather.ashx'
$url .= '?'. http_build_query($params);
Конечный URL выглядел так
Однако при запросе данных для этого URL с помощью cURL я получил сообщение об ошибке, что API-ключ не был предоставлен. Как я выяснил, проблема заключалась в использовании &
символы в URL. Когда я использовал http_build_query
метод как это:
$url .= '?'. http_build_query($params, null, '&');
URL выглядел так: http://api.worldweatheronline.com/free/v1/weather.ashx?q=48.13743%2C11.57549&Формат = JSON&NUM_OF_DAYS = 1&ключ = APIKEY
ВОПРОС
Теперь то, что я хочу спросить, если это ожидаемое поведение от сервера. Я знаю из нескольких других API (Facebook, Foursquare и т. Д.), Что они принимают &
вместо &
в URL и работать, как ожидалось.
Есть ли стандарт? Если сервер сможет принять &
или это «неправильно» принимать это и должно только &
быть принятым? Спасибо!
HTML-сущности, такие как &
не являются частью спецификации URI. Так далеко как RFC 3986 обеспокоен, &
является символом под разделителя, поэтому, если сервер получает строку запроса, подобную этой:
foo=1&bar=2
и анализирует его для следующих пар ключ-значение:
'foo' => '1',
'amp;bar' => '2'
это ведет себя правильно.
Чтобы сделать вещи еще интереснее, ;
также является зарезервированным вложенным разделителем, но:
если зарезервированный символ найден в компоненте URI и без разделителя
Роль известна для этого персонажа, то она должна интерпретироваться как
представляющий октет данных, соответствующий кодировке этого символа
в США-ASCII.
Других решений пока нет …