Friday, March 02, 2007

Blog movage

The techno blog has officially moved to the new general-purpose kayak blog. Please redirect your feed readers there for all future technical posts.


Friday, September 29, 2006

Perl and Java examples of Kayak search API

These samples are a bit old, but are a good starting point if you want to try implementing the Kayak API in Perl or Java. If you have a better/cleaner example you would like to share, let us know. If it's better than our hacked-together examples, I'll send you a Kayak t-shirt. Yeah, we spare no expense, baby!

Perl example.

Java example.

Friday, September 22, 2006

Search API problems

Just a quick note to let you know that we know that the search API is having some problems. We're working on tracking them down. So now we know that you know that we know. We'll let you know when it's fixed.

Update: we've found and fixed the problem; it will be patched first thing tomorrow, along with some other updates.

Thursday, August 03, 2006

KayakMobile ... Search API app

KayakMobile made its debut today. It is a Java servlet implementation using velocity to render pages.

It was a fun development effort. The Air and Hotel functionality is built using only the public Search API .. it might have been slightly easier to use internal APIs, but doing it this way forced us to push along development of the API as well.

The initial target is people in immediate need of travel arrangements ... stuck somewhere and need a flight or hotel now. With this in mind, we tried to keep the UI uncluttered and made assupmtions such as one-way flights, and single-night hotel requests.

With KayakMobile we introduce a rudimentary Restaurant search that's not in the core service.

Take it for a spin and let us know your thoughts.

Wednesday, June 21, 2006

Where is the Kayak WSDL?

Sometimes people ask why the kayak search API is not a true Web Services implementation.

Bruce Eckel just posted an interesting article that pretty much covers it for me.

Friday, June 02, 2006

Search API changes coming next week!

We've made a pretty major change to the search API this week, slated for release next Thursday. Actually, it's not so much a change to the API as it is a change to itself, and the API is just a victim of this.

The short story is that in order to expand our scale by 50-100% on our front-end processors, we now "lock" interim search results to a single front-end processors. These units are called "sparkles," for reasons that are too silly to explain. This is bad news for you, the developer, in the short term because you will have to change your code; but in the long run it's good, because we'll be able to handle much bigger volume than the 300,000 searches/day we handle right now. (Without buying zillions more servers.)

So, before you would make http calls like this:


But after thursday, it will be:

(this returns "-sparkle27" in the "searchinstance" xml tag)

Clear as mud? Good.

If you have any questions, drop me an email. billo at kayak daught com

Friday, May 12, 2006

Search API common problems

We're suddenly picking up a lot more people using the search API. There are a few problems that people run into, and they are our fault. Sorry.

The first problem is that there is a parameter missing from the doc: on the search results calls, the "apimode=1" parameter is required. If you don't pass it, you will get HTML and not XML! This will be fixed on the next site update we do. Just send apimode=1 on everything, it can't hurt :-)

The next problem is that sometimes the quota allocation breaks, and your quota is set to zero. If you are only able to do 1 or 2 searches and then you get "over quota" errors, please use the feedback link on to say this:

"my quota is broken on the search API. my email address for the developer is *insert email here*. Tell billo to get off his fat ass and fix my quota!"

(you may substitute "chiseled, Brad Pitt-like" for "fat" if you want to score points)

Finally there is some confusion over the 1000/day default quota. It's really 1000 searches/day, distributed over 24 hours, bucketed by whole hour. So you have 41 searches per hour when the quota is 1000/day.