Posted
by
timothy
on Thursday June 17, 2010 @03:00PM
from the mashing-together-shoes-and-bags dept.

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.'"

It's also useful for cataloging software; I own an insane amount of dvds and blu-rays and keep a list on my computer. When I get a new disc, I enter the upc code (it's also compatible with barcode scanners though I don't own one) and it automatically checks numerous sites including Amazon to grab things like the title, msrp, director, actors, publisher, number of discs, cover art, and other stuff.

English is far from a dead language. it's constantly evolving and changing to meet the standards of communication.

and in this day and age, THERE'S NOTHING WRONG WITH SAYING ME IN THE CORRECT TENSE. as a perfect example: "Last night: [persona], [personb], [personc], and me went for pints at [location]." is just as usable in today's speech as I was.

the reason "I" was grammatical preferred over "me" was due to the difficulty in saying "me" in proper english. "I" is a sharp high inflection, whi

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 [wikipedia.org].

The company I work for sells books. One of our developers created a Chrome addon in his own time that looks for ISBNs in every page you view and displays the price for the same book on our website.

No one knew that was going to happen when the API was developed. In fact, Chrome didn't even exist back then. (Although one of the other developers has made a Firefox addon and Firefox certainly did exist.) Companies just provide the API and let the developers come up with the good ideas. They don't expect an

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.

and besides, how many developers does it take to improve an open source codebase?I think the answer is smaller than you think.

I know the urge to follow an oss codebase that has a lot of commits, forums and feedback is strong - that shows the code is still being maintained and improved even if that is just bugfixes. A codebase that is stagnant, even if it is perfectly workable, is something that doesn't inspire confidence in it. That's just the way things are.

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.

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.

Were you referring to BizTalk? [microsoft.com] It seems to be alive still (2010 beta).

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.

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.

I get this exact same problem within IT at a Fortune 200, so cry more.

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

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).

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. Th

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.

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 [manufactuer.tld] )

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 [forummatrix.org] for a good example but imagine more interactivity with the data. The interface should borrow from Drill down dashboards used by execs.