IP-API problem for Weather Project?

IP-API problem for Weather Project?
0.0 0

#1

Why is the Ip-Api not working for me? I am trying to execute this example code from a video to get basic info but it doesn’t seem to be returning anything.


I just get blank calls as shown:

I searched for other projects which use this api on codepen and they all seem to not work for me either. I have tried different browsers and different devices but nothing seems to work. What are the possible reasons for why this is happening? Thanks! Im pretty new to this.


#2

Check the browser console and report back.


#3

If I’m not mistaken that’s because CodePen migrated everything to be served using the HTTPS protocol at the end of March, and there isn’t a HTTPS version of http://ip-api.com (more information here).

I have seen a few threads about this and only realised just now that I need to update my app, too, and found this:

I hope that helps. :slight_smile:


#4

Yes, you need an API that can be accessed through https.
https://ipinfo.io works for me.


#5

Hi,
I checked your JS file the getJSON call is not ended with ;
at the end $.getJSON(url, function(){
});
its the syntax we follow. and also need to change to https.

hope it helps you.


#6

You’re gonna end up in trouble with openweathermap because they currently don’t have a version of their api that works with HTTPS but that is what is suggested in the question. I suggest you find a weather API that does work with HTTPS. DarkSky was suggested for this purpose in the help chat room.


#7

That’s a very good point. I literally just finished fixing my weather app and ended up using Dark Sky’s API because I came across it on a SO thread. :slight_smile:

I can confirm that it works and it works very beautifully if you are using Dark Sky’s Skycons. Do note that attribution is required to use Dark Sky weather API.


#8

What’s wrong with the browser’s native geolocation API?


#9

Nothing now but there used to be a problem with it so some of the older apps are written with an outside API.


#10

People were convinced that there was a problem, but there wasn’t. I’m still not sure what the source of that confusion is, but outside location services have never been needed.


#11

If you say so but where there is smoke there is usually at least a small fire! It wasn’t working for me personally a while back but I checked today and it does work. The code was exactly the same in both cases so who knows.


#12

Amazing, sorry for the late reply, you just saved me big time. the ipapi works 100%, i was losing a lot of motivation trying to get the other one to work. Also thanks to everyone else for helping me learn about how api/jsons work, really helped me a lot.


#13

No need to be sorry, it’s the weekend and we all have things to do. I’m glad that it worked out well. :slight_smile:

On a somewhat related note, I personally think that there is absolutely nothing wrong with the native geolocation API that @PortableStick pointed out—if anything I think it’s better in the sense that it appears to have a little bit more respect for the privacy of the end user, and probably faster and more reliable.

The only issue is probably when someone has location services unknowingly turned off and that an error callback is not implemented. The fail-safe solution in terms of user experience is probably implementing the location API call inside the error callback of the native geolocation API.

Good luck with the rest of your project. :slight_smile: