Slashdot Mirror
Developers' New Opportunity — Retailers' Open APIs
snydeq writes "Fatal Exception's Neil McAllister examines the recent trend among retailers to provide outside developers access to open APIs — one that promises opportunity for developers to transform retailer data transparency into lucrative business models. But whether the trend lives up to its potential remains to be seen, especially given the hurdles small and midsize businesses face launching programs similar to those in place at Amazon, Zappos, and Sears. McAllister writes, 'There's a definite "Field of Dreams" quality to any such undertaking. Ask any company that hosts an open source software project how many outsiders actually commit code changes on a regular basis and you're likely to hear a discouraging figure. Similarly, just because a retailer builds an API doesn't mean anyone will actually use it. Given the uncertain prospects of return, it can be difficult to justify such an investment.'"
There's always the question, how long the APIs will remain open. They can disappear any time at the retailers wish and you're stuck with your development effort. I'd be wary.
I'm not sure what kind of applications they expect outside developers to create using these APIs. Is it just me?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
http://camelcamelcamel.com/ Great example. They also have one for newegg, bestbuy, backcountry and zzounds.
in theory, if the code was perfect, no new commits are required... open source is more about seeing first hand that backdoors don't exist, logic pathways are valid, and the realization that a finished solution requires no further work, and thus demands no continued pricing.
I seem to remember this whole idea from a while back, It comes to mind that microsoft was trying to market a product for use between [manufacturers distributors retailers] that allowed everybody access to information of what was going on with the whole chain.
seeing as I can't even think of the name of the solution, I expect it did so well that it got replaced with some upgrade, or tanked.
"Twenty years ago, brick-and-mortar retailers were only just discovering the Web as a vehicle to reach customers."
The web did not exist to be discovered by retailers 20 years ago.
What I find discouraging with these smaller outfits (maybe I've been unlucky in my choice of companies whose APIs I've used) is the attitude that once the API is announced, there is a disconcerting tendency not to bother to communicate changes to developers who've made use of the API. I generally discover that some change has been made purely by accident a week or more after the event, when I discover that something no longer works properly.
And, of course, there's always the issue that the actual API as implemented often is just-different-enough from the published description to cause one to experience an annoying period of trial-and-error as one figures out what actually works.
Isn't ecommerce pretty well standardized these days?
You search for an item, you have categories and subcategories, tags, a price listing, related items, and shipping info. Why isn't there a standard RetailML API for this?
Ask any company that hosts an open source software project how many outsiders actually commit code
http://www.fedoraproject.org/
Hm...
Palm trees and 8
Please think of the Grocers. Stop stealing all their apostrophes.
This isn't as bad an idea as it sounds. A good designer can make this happen with very little additional effort beyond the company's own uses. Basically, the thought is "If my applications work with the framework I've designed, then so should somebody else's". True, a designer doesn't think of every possible use, but that's what the design process is about - a feasible object model that supports all of the use cases you can think of, and even some you didn't think about. To me, this is the true power of OO design, that each class of objects is considered in isolation, and methods and behaviours thought of that aren't necessarily required at present.
The flipside, of course, is that your API will be prescriptive. To keep the cost of development similar to only developing internal uses, it wouldn't be feasible to really consider uses brought forward by the public. Basically, you get the "if I didn't think of it, then you can't do it" trap. To me, though, that's the challenge from the design perspective: to provide mechanisms to do things I didn't think of. When someone tells me they've used my code to do something I never dreamed of, I know I've done a great job.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
I'm guessing these retailers aren't giving back to anyone like RedHat does.
Blar.
You tried to write:
"I'm not sure what kind of applications they expect outside developers to create using these APIs. Is it just ME?"
For the sake of the English speaking world
please learn to write
"is it just I?".
I hope this helps you graduate from elementary school.
Yours In Krasnoyarsk,
Kilgore Trout
you insensitive cod .. er clod
Here's the way this plays out. I find out what you're into by the Facebook/Myspace APIs, then match tha up with what you might want to buy with the store's API... and suddenly every ad on my website is targeted to specific items at the store. Profit!
If companies actually used proper coding techniques, they'd be using their own API, and therefore wouldn't have to "justify such an investment" in creating one. All they would have to do is decide what properties and methods to make publicly visible and generate a wrapper API (which since the internal API is already created should be relatively easy).
Popisms.com - Connecting pop culture
The company I work for developed an API the minute we saw the first bot scraping our prices straight off the website. It's crazy not to. The bots are nearly always managed by someone who runs a price comparison website that drives traffic straight to us. The easier we make it for them, the more sales we get.
The hard-working 3rd party developers are going to get the info anyway by scraping the HTML designed for browsers but it will be hard work for them and it will break every time we re-jig the site. The API uses much less bandwidth and much fewer resources for both them and us and has the benefit for them of always being in a defined format.
Frankly, I'm surprised developing an API isn't the first thing every retailer does after finishing version 1.0 of their site.
Warning: The following paragraph may contain traces of a shameless plug.
A more recent API we have developed ties our products to semantically tagged data about the products. We aren't really sure what people are going to do with this data yet but the possibilities seem broad. If you feel like having a play with semantically tagged book data, the new API is at BibDib. (Yes, we have an affiliate program.)
Sig matters not. Judge me by my sig, do you?
Just open up the same API you are using internally and that should reduce the overhead of the API dramatically. I think much of the time the primary problem is that the developers don't have a proper API themselves so they have to build one from scratch.
A good pattern to adopt is: build an API and become your first client, to ensure the API is feature-rich. Twitter did this really well and it's helped to propel their business.
They just want you to list their crap on your dime.
As a web developer, it's amazing how little I want to do with "the web".
Is there such thing as a "closed" API? I mean... talking about redundancy.
hub and spoke design much better.
If google, yahoo, etc can simply work out a common API, then all these retailers can simply implement to that API and then job is done.
How hard can a shopping API be in complexity really !!
Digital Retail should NOT be web based
I imagine a decentralized social product network. It would be implemented with open standards and by a desktop client. Each manufacturer and retailer produce a catalogue of offered products, downloadable from their root domain ( http://manufactuer.tld/catalogue.xml )
Your client would aggregate data from a number of manufacturers (product specifications) and retailers (sellers).
It would let you compare products across any axes and produce many different fact indicators. It should be possible to compare products based on multiple indicators at the same time. This way you can do some constraint searching, such as I want a processor that offers a high performance per watt but has the lowest idle wattage, a hard drive that spins slow but offers the best data transfer rate and capacity.
There should be a public issue tracker per product so that users can determine what issues are with thay specific product. In a a category of product such as a car, there would be an issue called 'difficult to find parts'. This may be cross linked with multiple cars. The community can identify a severity of an each with each issue so they too can be searched as another axes. (Find me cars that do not have 'acceleration problems')
The reverse is also possible. There could be a positive attribute tracker, such as safety awards, standards (80% PSU Efficiency) and user created ones such as 'no known dangerous flaws 2010'. Of course the last one would be temporal. A product can change over time or the merit of the award becomes less relevant. When the Prius was released it could have no known dangerous flaws when it was released but then the positive attribute could be reversed when the acceleration problem was discovered. This way one could still search what was possible in the past. And what was available.
This is not a review system, it is more objective as it describes clear attributes for a category of products. Laptops would have 'overheating problems', 'exploding battery', 'battery degradation'. These are common to all laptops, with different severities.
The constraints would be very difficult to identify yourself unless you know what you are looking for. Users would contribute a 'saved search' for subjective product categories. Manufacturers should not have the control over this. for example, there is a difference between a DSLR and a point and shoot camera, a consumer router and a enterprise router. Laptops are a prime example: netbooks, ultra portable notebooks, desktop replacement laptops. All these definitions are up to (the knowledgeable) user who shares his searches.
Take a look at Forum Matrix for a good example but imagine more interactivity with the data. The interface should borrow from Drill down dashboards used by execs.
Hope I've made sense and please contribute.
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
Opposite water, Mrs Slocombe. The subject of the sentence isn't the speaker; it's the impersonal "it" - the same one that rains and snows. The word "me" is perfectly valid in a predicate.
Also: http://www.googlefight.com/index.php?lang=en_GB&word1=%22is+it+just+me%3F%22&word2=%22is+it+just+I%3F%22
I'll put a good word in for you. Maybe they'll let you in.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."