Fix REST search response for requests without snippets

[guilload]

Nesting each hit in a document object is not required for requests without snippets.

[evanxg852000]

@guilload, Please It's not very clear to me what you mean, document as?

• in quickwit https://github.com/quickwit-oss/quickwit/blob/main/quickwit/quickwit-search/src/fetch_docs.rs#L155
• or the rest service response https://github.com/quickwit-oss/quickwit/blob/main/quickwit/quickwit-search/src/search_response_rest.rs#L31

[fmassot]

So here is an example of a hit:

{
  "document": {
    "created_at": "2022-09-28T14:20:49Z",
    "id": 24276723600
  }
}

I see one problem coming: the json structure depending on snippet or not. From a user perspective, it's nice to have a stable search results whether there is a snippet or not.

[evanxg852000]

Ok I think i now understand @guilload 's concern and it's for stable representation of the response I changed the shape, this way decorative info specific to "document" like score can always come next to it. we could get rid of document and have snippet but a document field can be named snippet. Elsewhere, what we have here as "document" ElasticSearch call it "_source"

[guilload]

As discussed with Evance, let's go with:

• removing the document field
• populating snippets in a top-level field called snippets the same way we do for aggregations

#[serde(skip_serializing_if = "Option::is_none")]
pub snippets: Option<Vec<serde_json::Value>>,

[evanxg852000]

My guess is that the snippet array and the hits array should match in terms of indices. That is hit[0] -> snippets[0]
@guilload IMHO this is not API consumer friendly thought.