How can I get the same results in the API as in the web interface?

Sorry for this long post.

Let’s take two examples: “miles davis” and “kenny garrett”.

This returns the “real” Miles Davis (score 100), then a relatively unknown bassist also called “Miles Davis” (score 96), and then all the groups including Miles Davis, with scores <90. This is good.

If I call the API:

The order is about the same, but the score of the second result is 93 (not 96). This is not a problem.

Now let’s try with “kenny garrett”:

The “real” Kenny Garrett is first (score 100) and all the other results have a score <50. This is good.

Same result in the API:


Now, let’s suppose I made a typo (“kenny garret”):

I still get the good Kenny Garrett first (score 100) and the rest with scores <=52. Good.

But in the API:

I get Kay Garret first (score 100) and Kenny Garrett comes way down with a score of 52.

Let’s try with a fuzzy search:

Kenny Garrett comes first (score 100). Good! But the second result is an artist called GARREN with a high score of 73. Weird. Let’s remove the typo and search for “Kenny Garrett” again:

Kenny Garrett is first (score 100) and the second result is an artist called JGarrett with a high score of 78.

Now back to Miles Davis:

The “real” Miles Davis still comes first (score 100) but the bassist also called “Miles Davis” comes third with a “low” score of 62, which is very different than the score of 96 in the web interface.

And if I prefix the search query with “artist:” or “name:” I get completely weird results:

JGarrett comes first (score 100).

For me, the most intuitive (“correct”) results are the ones I see on the web interface. How can I call the API to get the exact same results?

Yeah, if you don’t enable advanced query syntax in the web interface (which allows you to specify fields), it informs the search server to perform a “dismax” query, which is a fancy internal method that searches across multiple fields using different weightings.

There’s an undocumented way to enable this through the web service, but the usual caveats apply to using undocumented features:

I’m not sure why it was decided to not enable dismax by default in the WS if no fields are specified (that was before my time), but I guess at this point it would contradict our API docs: search for “Query terms without a field specifier” on to see the promises we make there (as much as I doubt many people rely on those behaviors).


Thanks for your answer. This helps a lot!

Is there a reason why this is undocumented/unofficial?

Dismax search didn’t originally exist, it was added later to provide better results for the website search. It wasn’t really considered it would be used via the api since it doesnt allow any choice over what fields can be searched