Microsoft（Bing）によるtotalEstimatedMatchesの動作認知検索API（v5）

Question

最近、Bing Search API v2コードをv5に変換して動作しますが、「totalEstimatedMatches」の動作が不思議です。私の質問を説明する例を次に示します。

私たちのサイトのユーザーは、特定の単語を検索します。 APIクエリは10個の結果（ページサイズ設定）とtotalEstimatedMatchesを21に設定します。したがって、3ページの結果が表示され、ユーザーがページを通過させます。

ページ3に到達したとき、totalEstimatedMatchesは21ではなく22を返します。このような小さな結果セットでは、それが22であることはわかっていないはずですが、それでも問題はありません。すべての結果が正しく表示されます。

ユーザーがページ3からページ2に再び戻ると、totalEstimatedMatchesの値は再び21になります。結果セットがページングされると、APIは22の結果ではなく21の結果であることを知っているはずなので、これはちょっと驚くべきことです。

私は80年代以来、プロのソフトウェア開発者でした。そのため、これはAPI設計に関連する厄介な問題の1つです。明らかに、結果の正確な数をキャッシュしていないか、それとも何でも。私は、V2検索API（これは第三者のコードであることを認識している）でその種の動作を覚えていない。結果はかなり信頼できました。

これは私の外に誰かが予期しないほどの衝撃を与えますか？

Answer 1

これはレスポンスJSONフィールドtotalEstimatedMatchesは言葉...Estimated...を含み、ちょうどtotalMatchesと呼ばれていない理由ですが判明：検索エンジンのインデックスは、全試合の正確な推定をサポートしていません...

」 "撮影

：1が予想されるようNews Search API V5 paging results with offset and count

、あなたが戻って取得少数の結果、あなたはtotalEstimatedMatches値で見ることが可能性が高いです大きな％の誤差。同様に、より複雑なクエリ（たとえば、../search?q=(foo OR bar OR foobar)&...などの複合クエリを実行すると、実際には3つの検索が1にパックされます）、この値がより多く表示されるように見えます。

つまり、私はoffset == totalEstimatedMatchesを設定し、単純な等価性チェック機能を作成することで（少なくとも予備的に）これを補うことができました。

はここで、Pythonで簡単な例です：

while True: 
    if original_totalEstimatedMatches < new_totalEstimatedMatches: 
     original_totalEstimatedMatches = new_totalEstimatedMatches.copy() 

     #set_new_offset_and_call_api() is a func that does what it says. 
     new_totalEstimatedMatches = set_new_offset_and_call_api() 
    else: 
     break