#1 Posted by TheBeast (1931 posts) -

I've just had a quick play with the API (Great work - looking forward to making some stuff with it!) but have hit a snag when trying to build a client-side application in JavaScript (making requests to the API).

Would it be possible to implement JSONP/callback support to get around the usual limitations of making cross-domain requests? I'd rather not have to mirror the results locally using some server-side solution if I can avoid it (for now, at least).

On another note, the documentation doesn't mention how to change the delivery format (For anyone looking; use the 'format' paramter with either 'JSON' or 'XML' - anything else causes a server error).
#2 Posted by andy (427 posts) -

We might be able to do this.  It would be trivial to implement on our end.  I'd like to think about potential security issues with this prior to saying yes or no.  One thing that comes to mind is that anyone who uses your app has access to your API key.  That's not a huge concern, just not something we really anticipated.

I'll respond again soon with a yes or no.

Staff
#3 Posted by TheBeast (1931 posts) -

That's understandable - I suppose there are security problems.

How do API's designed for use through JavaScript (like Google Maps) deal with it? Are their keys tied to a domain?

I'm getting around the problem by redirecting the request through a script on my server (hiding the API key) at the moment - it works OK but I'm not too keen on having to forward all possible variables - plus it's naturally slower.

Perhaps some sort of 'Allowed Domains' feature could be added, where each user has a set of domains they can tie to their API key which is checked against the referrer when a request is made? Not entirely foolproof - but good enough to stop anyone accidentally using other people's keys.
#4 Edited by doogiemac (22 posts) -

I'd like something like this, as well.  Could it just be recommended practice that app developers not distribute their API key with their app?  i.e. a step in the installation of your app would be to edit the API key.  My use-case is a little JS utility that can be loaded onto web pages and show tool-tips with game, franchise, character, etc. info - kind of like WoWHead's script: http://www.wowhead.com/?powered

#5 Posted by LordAndrew (14424 posts) -
doogiemac said:
"I'd like something like this, as well.  Could it just be recommended practice that app developers not distribute their API key with their app?  i.e. a step in the installation of your app would be to edit the API key.  My use-case is a little JS utility that can be loaded onto web pages and show tool-tips with game, franchise, character, etc. info - kind of like WoWHead's script: http://www.wowhead.com/?powered"
Basically, the user would have to provide their own API key? I was thinking that too, but you'd have to make sure your users know how to get one.
#6 Posted by doogiemac (22 posts) -
LordAndrew said:
Basically, the user would have to provide their own API key? I was thinking that too, but you'd have to make sure your users know how to get one."
Right.  They've made it really easy to get a key, so hopefully it wouldn't be too big of a deal.  I believe Flickr has handled this well (i.e. http://api.flickr.com/services/feeds/photos_public.gne?tags=cat&tagmode=any&format=json&jsoncallback=? ) but I believe they've also got a limited API if you're not using an API key - which may be more than Whiskey is looking to do at this time.
#7 Edited by TheBeast (1931 posts) -
doogiemac said:
"My use-case is a little JS utility that can be loaded onto web pages and show tool-tips with game, franchise, character, etc. info - kind of like WoWHead's script: http://www.wowhead.com/?powered"
Fantastic idea! 
With a plugin/script like that you definitely wouldn't distribute your API key with the app - you'd just have the user set a variable somewhere with their own API key or whatever.
A key should be used for only one implementation - this way, if it was required to limit the rate/frequency at which a single key can be used to query the database, it's not going to affect everyone who uses your script, or every application you're running with the key.

The problem Andy raised is that with a JS implementation (no matter whos API key it is...), it's still visible to the world.
#8 Posted by doogiemac (22 posts) -
TheBeast said:
The problem Andy raised is that with a JS implementation (no matter who's API key it is...), it's still visible to the world."
Yeah, that's a very good point. I think the allowed domains idea may be a good workaround, if that's something you guys are interested in doing.
#9 Edited by andy (427 posts) -

doogiemac:  Awesome idea.  I'm a huge fan of WOWhead.  Something similar for GB is a great use for the API.

As TheBeast said, my only real concern is that the API key can easily be seen by the world if it's in JS.  Maybe that's not a huge problem.  I'll come up with something today and reply back to this thread.

Staff
#10 Edited by TheBeast (1931 posts) -

There's an interesting article here about API authentication - although it's more to do with handling user data in an API, it might give you some ideas.


Personally I don't think that security is a big problem with an API that doesn't involve user information and is only used for fetching information - if someone was desperate enough to farm API keys, it would be easy enough to create a whole lot of accounts on the site (considering no e-mail authentication or anything is used) to get them!
#11 Posted by andy (427 posts) -

Agreed.  I've gone ahead and added jsonp support.  Updated the documentation to be a little more clear about responses, formats, etc.

For jsonp, just do:  http://api.giantbomb.com/game/1/?api_key=<your key>&format=jsonp&json_callback=<your callback name>

Let me know if there's any problems.

Staff
#12 Posted by TheBeast (1931 posts) -

Awesome! Thanks again Andy.

#13 Posted by doogiemac (22 posts) -

You guys rock.  Thanks, Andy.