WX Underground data not showing, API key works in browser with same string

Question

Im having an issue with the WX Station classic , I get an update to time, but the WXunderground data shows N/A. When I type the API request into the browser (as given in the serial output) it returns the expected data. It seems that perhaps the parsing isn't going well? Perhaps wxunderground changed something?

Is there an easy way to get the .json data pushed to the serial console so I can verify?

THis is what I am getting from the serial output now...no errors that I can see.

Setting readyForUpdate to true

03:02:43
3:2:43
10963
Requesting URL: /api/**MYKEY**/conditions/lang:EN/q/Dominican Republic/La Cayota.json
Requesting URL: /api/**MYKEY**/forecast10day/lang:EN/q/Dominican Republic/La Cayota.json

Any thoughts?

Update: Solved!

Squix78 below answered the question (THANK YOU!) , but not a total explanation so here I will attempt to do so.

When country or city names contain a space, the space character in the code must be replaced with a "%20" as in 'Dominican%20Republic'

This is because a properly formed URI must contain no spaces. Instead, URI formatting uses %20 to represent a space. 

It worked in the browser because modern browsers know this and sanity check / repair the URI before sending, replacing the spaces with %20. You can see this in the URL bar after you make the request.

Answer 1

I hope that's going to be an easy one: a city name with a space needs to be URL encoded. Set the city name like this: "La%20Cayota"

Maybe my library should do that in the future or at least leave a comment in the demo code... Please mark this answer as "best answer" if it helped to share this information with others...

Comments

Fixed....Thanks!

I will add for future guests:

When country or city names contain a space, the space character in the code must be replaced with a "%20" as in 'Dominican%20Republic'

This is because a properly formed URI must contain no spaces. Instead, URI formatting uses %20 to represent a space.

It worked in the browser because modern browsers know this and sanity check / repair the URI before sending, replacing the spaces with %20. You can see this in the URL bar after you make the request.