服务器应该接受＆amp; 而不是在URL获取请求？

Question

INTRO
I will give you an example so my question may be better understandable. I don't need "help" in programming matters, just information about this topic!

EXAMPLE
I tried out an API for getting weather information for a specific position and stumbled upon a problem. I built my url to request data like this:

$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);

The final URL looked like this

http://api.worldweatheronline.com/free/v1/weather.ashx?q=48.13743%2C11.57549&format=json&num_of_days=1&key=APIKEY

However, when requesting the data for this URL with cURL I received the error that no api-key was provied. As I found out, the problem were use of & symbols in the URL. When I used the http_build_query method like this:

$url .= '?'. http_build_query($params, null, '&');

The URL looked like this: http://api.worldweatheronline.com/free/v1/weather.ashx?q=48.13743%2C11.57549&format=json&num_of_days=1&key=APIKEY

QUESTION
Now what I want to ask, if this is an expected behavior from a server. I know from several other APIs (Facebook, Foursquare, etc.) that they accept & instead of & in the URL and work like expected.

Is there a standard? Should a server be able to accept & or is it "wrong" to accept it and should only & be accepted? Thanks!

Answer 1

HTML entities like & are not a part of URI specification. As far as RFC 3986 is concerned, & is a sub-delimiting character, therefore if a server receives a query string like this:

foo=1&bar=2

and parses it to the following key-value pairs:

'foo' => '1',
'amp;bar' => '2'

it is behaving correctly.

To make things even more interesting, ; is a reserved sub-delimiter, too, but:

if a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.