in Uncategorized

Yahoo Web Service APIs

Well Yahoo has released their search engine web service APIs. The fact that they chose to ignore industry standard communication protocols (SOAP + WS-*) was just a bad decision IMHO. Now all the toolkits that exist for various languages/frameworks are useless in helping the programmer develop against these APIs and everyone must roll their own XML parsing.

Something that could have taken ten seconds of running your favorite language wrapper generator now boils down to you having to write extensive amounts of XML generation/parsing logic. I see they released some sample client implementations for ECMAScript and Java, but noticeably absent is an sample implementation for .NET. Hmmm…

Leave a comment


  1. Interesting. I think their decisions made total sense. In fact I think they should have gone one better and did what the MSN Search team did by just using RSS search results. Why do you think developers need to mess around with SOAP and WSDL for something as straightforward as fetching search results?

  2. Yes, it’s simple, but there’s no tools support. The developers have to do all the REST+HTTP work themselves here. Yes there are REST toolkits, but AFAIK there are none as rich as the SOAP/WSDL toolkits out there (which even themselves suck at this point). As for MSN’s RSS feeds, again it’s simple and I think it’s really smart to have this version, but once again you have to do all the query string building and HTTP request generation yourself which can lead to errors. The whole idea of having a standard is that you can build tools around it to take the time out of development.

    Case in point, both build on HTTP and URL specificiations. Why use HTTP? We don’t need all those stupid headers and what not, just open up a TCP connection to port 80 and fire some bytes through there. Why use URLs with query strings? We could just spec out a proprietary struct to pass. So why is it those two standards were used, but the SOAP standard was not? SOAP/WSDL by itself really isn’t that hard, I think it catches a bad rap. The only point where things get complex is when the WS-* specs get involved and I agree whole-heartedly that none of those are necessary here.

    Thankfully they used REST and instead of going entirely proprietary, so I gotta give them some props for that.

  3. When a service chooses SOAP and WSDL they are intentionally limiting their audience to developers who use platforms with fancy toolkits. It would be short sighted of Yahoo! or MSN to think like this. There are times when the cost of SOAP + WSDL buy you a better development experience and times when the benefit is marginal at best.

    Fetching search results over HTTP is one of those times where I think using SOAP + WSDL is overkill. I’ve told the MSN Search folks pretty much the same thing and I’m sure the fact Yahoo! is bought into the idea is also telling to them.

  4. I think the statement that they’re “limiting their audience” is a bit strong. Someone who doesn’t want to use a toolkit really doesn’t have to do any more than they were doing already. I mean it’s not much harder to build a string of XML as it is to build a query string, ya know? The formatting rules are just different. Plus people who don’t use fancy toolkits are usually the ones who are used to writing all sorts of custom code. I happen to be one of those people, btw… the toolkits for .NET just aren’t there yet in terms of translating from .NET -> WSDL or vice versa

    I guess I just don’t see SOAP/WSDL as being *that* much more difficult, especially when the idea is that it’s supposed to make it easier for all of your consumers to leverage your service (since it’s a well document standard, toolkits, etc.), but I guess that’s where we disagree. 🙂

  5. I’ll use the Amazon and Google Web Services APIs for application development until Yahoo! publishes WSDL. I’ll do this because of the fantastic tools support offered by Microsoft, IBM and others for Web Services-based programming.