There may be some rationale behind this, but I find the fact that the url block chokes when the scheme (e.g., http://) is included in the URL to be a small irritant. I have my students interact with an API through their browser and then copy the URL over to Snap!, and inevitably they copy the whole URL and the block doesn't work.
So, it would be nice if the scheme could be included (perhaps with http:// being the default if left off).
Not 100% sure If I'm understanding your problem but secure https websites (which Snap! is) aren't allowed to fetch/open non-secure i.e. http websites.
All (AFAIK) browsers do this nowadays - its not a Snap! restriction
Light dawns. I formed an incorrect mental model (when the scheme wasn't included, the data was fetched, when the scheme was left on, it wasn't). It didn't occur to me to try other schemes, or to think about the fact that Snap! was https. Further experimenting demonstrating that if the scheme is https:// it can indeed be included.
So, the irritant still remains (copying the API calls fails if the scheme is removed (or changed)), but the solution seems less clear cut. Quietly trying to switch to https could be an option. Perhaps a superior option would be to either report an error message, or actually throw an error so the script wouldn't continue if data couldn't be fetched.
We think the people who make browsers are all trying to drive us crazy by introducing restrictions and downright bugs once in a while. But yes, we could program a workaround for this. We'll consider it for When Things Slow Down™.
If it's about making requests to http sites from https Snap! then the recommendation is to use http://extenstions.snap.berkeley.edu OR to use a CORS proxy website. There is no other getting around the http vs https restriction, and frankly you wouldn't want browsers to do it in the "normal" case. We cannot "upgrade" http requests to https wholesale because many of the sites that use http don't fully support https.
(When the forum reopens): If you can share specific examples, that'd be helpful, but I don't think there's much we can do.