Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Businesses IT

Developers' New Opportunity — Retailers' Open APIs 45

Posted by timothy 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.'"
This discussion has been archived. No new comments can be posted.

Developers' New Opportunity — Retailers' Open APIs More

Developers' New Opportunity — Retailers' Open APIs

Comments Filter:
  • 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.

    • Re: (Score:3, Insightful)

      by grcumb ( 781340 )

      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.

      Indeed.

      McAllister writes:

      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.

      His conclusion is that low uptake makes opening APIs a high risk activity. That's as may be, but isn't it equally possible that these organisations aren't successful because they're doing it wrong?

      Unless I have some kind of moral ownership stake in the project (such as I might have if I maintained a GPLed Linux

  • Is it just me? (Score:3, Insightful)

    by Hognoxious ( 631665 ) on Thursday June 17, 2010 @02:08PM (#32605492) Homepage Journal

    I'm not sure what kind of applications they expect outside developers to create using these APIs. Is it just me?

    • Re: (Score:3, Informative)

      by yincrash ( 854885 )
      I assume they would embed them into existing applications.

      Let's say I have an app to look up movie times. I could check to see if the movie soundtrack is for sale on amazon.

      Or maybe one of those barcode scanner apps. You could then immediately purchase from the app itself.

      • Re: (Score:3, Interesting)

        by WeatherServo9 ( 1393327 )
        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.

      • Marvellous idea! That could be useful to as many as three people over a quarterly period. It might even pay for itself before the Sun blows up!

    • Re: (Score:2, Insightful)

      by Michael Kristopeit ( 1751814 )
      if they sell stuff, they expect you to sell their stuff to your audience.... presumably for a cut of the profit.

    • 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

  • http://camelcamelcamel.com/ [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.

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

    • Re: (Score:2)

      by eihab ( 823648 )

      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.

    And, of course, there's always the issue that the actual API as imp

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

  • Why a separate API for each store? (Score:3, Insightful)

    by NevarMore ( 248971 ) on Thursday June 17, 2010 @02:18PM (#32605612) Homepage Journal

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

    Hm...

  • Please think of the Grocers. Stop stealing all their apostrophes.

    • Re: (Score:2)

      by megrims ( 839585 )

      Please elaborate. I can't spot anything wrong with the punctuation in TFS.

      • Retailers' Open APIs

        Open APIs in the possession of a group of Retailers. There is no verb in that statement.

        Retailers Open APIs

        This one actually has a verb.

        An "s" at the end of a word does not necessitate an apostrophe in most cases.

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

  • 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 !!

  • Bring products to the desktop! (Score:3, Interesting)

    by improfane ( 855034 ) on Thursday June 17, 2010 @05:40PM (#32607768) Journal

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

    Hope I've made sense and please contribute.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close