I work as a developer on the API team at Best Buy, and we're trying to open up our data in ways that will (hopefully) be useful to folks outside of Best Buy. Please feel free to comment on anything you especially like or dislike.
What's the formula for choosing Top Trending? Is it absolute or relative lift over the previous three hours? Can you disclose any details on the algorithms or the features used in the Similar Products API?
I'd love to talk to you offline. Could you shoot me an email? Details in profile.
On the API team, we're simply packaging data that is cooked up internally by teams who are also providing data for the dot com site, as well as other stuff. Consequently, I can't give you good information (and in any case, I maybe couldn't even if I knew - some of these types of things (like trending, similar products, etc.) are carefully tweaked by business folks, same as at any other retailer. Nothing crazy; but I think the details are proprietary.).
Where did the idea for the API come from? At large companies that like I imagine upper-management sees things like this as a cost center, which can make it difficult to try and innovate.
I believe the original set of APIs (called "Remix") were cooked up by some of the bestbuy.com architecture crew, and lately there's been increased interest and support from the management. The executives here are actually pretty forward-thinking about this kind of stuff.
Super stoked to see a public api from your company. First thing I did, though, was try to hit http://api.remix.bestbuy.com/v1/products/1162032.json. Despite being a json file, it returns html. Admittedly, a consumer should be looking at the err code first, but a json formatted error would be preffered :]
I'm really sorry about that - there are a few types of errors that come from Mashery for which we haven't yet customized the responses to properly return JSON. Essentially what you're seeing is that you aren't specifying an API key. To use the Best Buy APIs, you just need to register for a key at https://remix.mashery.com/member/register. And there's more info on getting started at https://developer.bestbuy.com/get-started. If you decide to try it out, please let me know if you run into any problems.
Why did you guys decide to have the API endpoints a) use plain HTTP and b) include the API key as a query parameter? While it doesn't look like the API lets you access anything particularly sensitive, you're just asking for API keys to be sniffed out and used/abused by folks other than those you issued the key for.
It's a fair complaint. I'm not sure when we're getting everything to HTTPS, but I know it's on the roadmap. Including the API key as a parameter goes back to the early days of our API - quite a few years ago. The problem now is that we have enough apps with enough traffic that we can't just move it to the header without causing a bit of disruption. But that too is on our roadmap. Both issues are important.
It should still be fairly easy to check for an API Key in the header if not found in the request parameters. This way there would be no disruption for old apps, and it would benefit new apps.
I also think that both this and HTTPS are mandatory, but since it's on your roadmap that's good enough.
Having worked as a developer for several large retailers I have inevitably pondered whether a public API would be of any value to either the developer community or the business itself. The Gallery[1] offers a small number of use cases but I still have trouble grasping how upper management, as forward thinking as they may be, would see any ROI for the time and effort required to establish and maintain such a large, brittle piece of software. Not to mention the risks of potentially providing tools for competitive advantage to others in the electronics space (however few there may be nowadays) or a security slip of some kind.
At any rate, kudos to the team for trying to move the industry forward.
Thanks for the kudos! I'm a relative newcomer to the group; we have some great programmers and product folks who have been growing this for years now.
You raise a number of interesting points. Our view is that by sharing our data, we can create an ecosystem in which third parties can make apps and services that make a better overall experience for the customers, and of course we hope that we'll benefit from that, however indirectly. The risks are relatively minor: our code is small and our team is small, so we don't cost much. And at least for now, we're not really serving up any data that you can't see on bestbuy.com, so we're not (yet) facing any large security issues.
As for the use cases, I really think people are just starting to scratch the surface of what you might do with data from a very large retailer.
I've been using Best Buy's API for 4 years now. My first API key was registered on 1/31/11 at 2:24 pm. It is crazy it has been this long. This is the site I built using the API: http://boominaudio.com
The BBY API is awesome. I've especially liked the stores API. I've grabbed the location of the user, and then mapped out products that are in stock near them and use the Google Maps API to show people products on a map relative to their location. The data that is pulled from the API, is then stored in Memcached for like 6 hours. I actually store the product data in MySQL, but certain things are pulled dynamically on the fly, like the product reviews data.
Are there any plans to deploy the same API to FutureShop.ca?
My understanding is that they are one and the same company under different roofs. I worked in the Canadian west-coast Bestbuy warehouse and we shipped product to both BestBuy and FutureShop stores, sometimes with stickers from the other store still on it.
Bestbuy.ca and Futureshop.ca even share a remarkably similar design, though BestBuy.com does look dissimilar to both bb.ca and fs.ca.
It's true that Best Buy owns Future Shop, but I don't believe we're pulling their data as part of what we show. I'm not sure if we have immediate plans to offer similar APIs for Future Shop, but I can find out.
