TheFaxman

It seems like there's some bad data in the database somewhere - I noticed that the URLs returned by the API for all the Best of Giant Bomb videos all look valid but return 404 when you try to retrieve them. For example:

http://v.giantbomb.com/2016/04/01/vf_giantbomb_bestof_95_4000.mp4

It only seems to affect videos in this category - can someone help me figure out why these are busted for my app users?

I posted this to the API forum as well but since it appears to be a bug I'm cross posting here to make sure it gets noticed.

I'm getting a lot of reports of my app hitting failures today and I've tracked it down to a change where requests without a User-Agent header are getting rejected with a 403 error. Once I add a User-Agent header (even a fake one) the request succeeds. The same requests worked as recently as yesterday (2/15).

Is this an intentional change? Since it's blocking my app I need to figure out how to resolve it but I don't want to push an update until I fully understand what you want to see in the User-Agent header for apps.

I'm getting a lot of reports of my app hitting failures today and I've tracked it down to a change where requests without a User-Agent header are getting rejected with a 403 error. Once I add a User-Agent header (even a fake one) the request succeeds.

Is this an intentional change? Since it's blocking my app I need to figure out how to resolve it but I don't want to push an update until I fully understand what you want to see in the User-Agent header for apps.

@silver-streak: The update that resolves the video playback issues is published (along with a pile of fixes and new features)

@silver-streak: I just noticed this and am working on fixes for the Windows apps (along with some long overdue updates)

This is impacting my GB app for Windows & Windows Phone - it appears that all requests to the /reviews endpoint are returning no data and a null count of rows returned. For example:

http://www.giantbomb.com/api/reviews/?api_key=<key>&format=json

Returns:

{"error":"OK","limit":100,"offset":0,"number_of_page_results":0,"number_of_total_results":null,"status_code":1,"results":[],"version":"1.0"}

This was also reported in the API forum but I'm putting it here to hopefully help get it in front of the right people. Original thread was here:

http://www.giantbomb.com/forums/api-developers-3017/problem-with-api-reviews-1498287/#1

Not sure when this started but I first had a report last night.

@edgework: It's mostly about minimizing end user impact when API changes occur. There's two real categories here:

1.) A bug in the app itself often due to assumptions. In this case by testing against a beta endpoint the app author can fix the bug before their users are impacted by it. This is more impactful when the upcoming changes are fairly big.

2.) A regression in the API. In this case it gives the opportunity to provide feedback to you guys earlier and reduce impact.

During the seaserpent beta I found a bunch of bugs in my app that fell into #1 and quite a few that fell into #2. Both ended up getting fixed before the rollout because of the beta endpoint and my end users saw no real impact. If the changes had just been deployed I probably would have had at least a week's worth of disruptions while I worked through issues. Like I said before I don't suspect what you asked about is really impactful this is more of a general suggestion. I know that having a beta endpoint to test against is more work for the engineering teams so I can appreciate that it may or may not be the right thing here.

@edgework: One thing that I think really helped when the site & API redesign hit was the beta endpoint we could test our apps against (I found a number of bugs and regressions this way). While I don't suspect adding fields is a big deal for most apps it would be great if you could stand up a beta endpoint so people can test and give you feedback before launch.

@gamingmichael: I have a "2.0" update that I've been working on - but it's mostly updates to switch to the Windows 8.1 / Universal SDK so that when the Xbox SDK drops I'll be ready to get things working.

If you have a specific feature request let me know - I'm not 100% sure what you mean by bookmarking and since I'm actively working on things it's a good time to get feature requests in.

@jslack: The hard coded API key usage was the only guidance I've seen for client apps. I have no problems switching off of this but I'd like some guidance as to what I should be moving to? Should I ask for API keys from users directly? Use the /boxee/ code method? Something else?

I need to try to get a fix out as soon as possible since my users are blocked so I need to figure out a method fairly quickly.