BING API met paginatie

[semyazaruax]

Mijn vraag
Ik ben momenteel bezig met de API van Bing, welke overigens perfect werkt. Het enigste wat ik niet werkend krijg is dat ik de zoekresultaten in een paginatie wil hebben. In de API geven ze aan dat je met een count (hoeveel resultaten) en een offset (hoeveel skippen) kunt werken.

Nu zoek ik op bijvoorbeeld "why do apes take over the planet" en krijg ik om maar wat te noemen 200 resultaten (geschat door de API). Ik zit dus al met een nummer dat niet helemaal klopt om te beginnen want het is een schatting.

Als ik nu 50 resultaten per pagina wil, houdt dat in dat ik 4 pagina's nodig heb (4*50=200). Echter, ga ik naar pagina 3 dan heb ik nog maar 12 resultaten en pagina 4 bestaat helemaal niet.

Heeft iemand een idee hoe ik toch een fatsoenlijke paginatie kan maken met Bing zodat het aantal pagina's toch wel klopt? heb nu alles perfect werkend alleen de paginatie lukt mij gewoonweg niet omdat het allemaal niet klopt qua nummers

Wat ik al gevonden of geprobeerd heb
MSDN: Paging Results

[Verwijderd]

Ten eerste geef je al aan dat het aantal een schatting is, dus het aantal kan minder zijn (212 bijvoorbeeld).

Gebruik je wel een zero-based 'count'? Dus voor pagina 3 de waarde 2 * 50 =100 in plaats van 3 * 50 = 150?

[semyazaruax]

Ja klopt, maar elders lees je weer dat het geen schatting is... tegenstrijdig dus maar goed. Ik gebruik inderdaad de zero base count

Een klein gedeelte van mijn code (de url):

code:

$url = 'https://api.cognitive.microsoft.com/bing/v5.0/search?q='.urlencode($_GET['searchString']).'&mkt=en-US&offset='.$offset.'&count='.$perpage.'&format=json&safeSearch=Off'.$search;

Uiterard staat "count" op 50 omdat ik 50 resultaten per pagina wil. Offset telt gewoon met +1 op voor elke pagina die je verder gaat dus pagina 1 = geen offset, pagina 2 is =1 offset, pagina 10 = 9 offset waarbij pagina 10 dan een offset van 9*50=450 heeft.

Volgens mijn zou dit gewoon moeten kloppen allemaal. Als ik vervolgens het volgende bereken:

resultaten / 50 = 200 (om maar een voorbeeld te geven) dan gaat het op pagina 1, 2 en 3 goed maar 4 bijvoorbeeld fout.

Ik denk dat het dan toch een hééééle ruwe schatting is helaas... maar kan ik hiervoor iets maken dat iemand weet of word dit een mission impossible zonder x-aantal requests weg te gooien? ik kan wel door de paginatie iteraten en voor elke keer een request sturen en kijken of het aantal terug gegeven resultaten kloppen maar dan schieten de requests de lucht uit

[ Voor 185% gewijzigd door semyazaruax op 18-06-2017 20:41 ]

[Verwijderd]

Het enige optie lijkt me inderdaad bij elke pagina (of vanaf 75% of zo) te kijken of de volgende offset-stap nog data oplevert, en zo nee die optie niet te tonen.

Offset moet je trouwens met $perpage verhogen, volgens de specs: "The offset parameter specifies the number of results to skip."

[semyazaruax]

ja dat heb ik inderdaad Zaph

Dus 50 per pagina zou dan zijn:

Pagina 1: 50 weergeven 0 skippen
Pagina 2: 50 weergeven 50 skippen
Pagina 3: 50 weergeven 100 skippen

Wel rot dan dat je requests moet gaan gebruiken om te kijken naar volgende pagina('s), dan tikt het wel aan kan je flink in de buidel tasten voor een API abonnementje haha.

Dankjewel voor je antwoord!

[Verwijderd]

Helaas, ja - ik heb het op Google ook regelmatig dat er in eerste instantie 7 pagina's of zo lijken te zijn, en dat het na wat doorklikken bij pagina 3 ophoudt. Waarschijnlijk is het een keuze tussen exacte aantallen enerzijds en snelle respons anderzijds.

[NickThissen]

Je kan toch gewoon bij opvragen van pagina X alvast de resultaten van pagine X + 1 ophalen (op de achtergrond eventueel), en als die er niet zijn kun je dat pagina nummer weg halen. Dan zijn het twee requests per pagina ipv 1, dat valt dus nog wel mee. En verder gewoon checken of er resultaten gegeven worden, zo niet terugvallen op de laatste pagina met resultaten en die pagina's weghalen.

[Verwijderd]

Dat was de conclusie, inderdaad, alleen gebruik je dan per pagina 2 API-calls, wat flink in je API-budget snijdt.

[Gomez12]

Alhoewel het een schatting is, valt die wel binnen bepaalde grenzen over het algemeen. OFtewel als hij zegt 4 pagina's te hebben, dan hoef je niet direct bij pagina 1 te checken of er een 2e pagina is. Dit hoef je waarschijnlijk pas bij pagina 3 te doen.

En sowieso als er meer als 10 pagina's zijn, dan hoef je die check over het algemeen helemaal niet te doen want niemand gaat pagina 10 of verder bereiken .

[Verwijderd]

Gomez12 schreef op maandag 19 juni 2017 @ 15:21:
...want niemand gaat pagina 10 of verder bereiken .

Heh...zo dacht er ook ooit iemand dat niemand meer dan 640Kb intern geheugen nodig zou hebben...

[Gomez12]

Verwijderd schreef op maandag 19 juni 2017 @ 16:13:
[...]

Heh...zo dacht er ook ooit iemand dat niemand meer dan 640Kb intern geheugen nodig zou hebben...

Wie dacht dat dan?

[Verwijderd]

Iemand genaamd Bill Gates, over MS-DOS - misschien wel eens van gehoord?

[Gomez12]

Verwijderd schreef op maandag 19 juni 2017 @ 17:21:
Iemand genaamd Bill Gates, over MS-DOS - misschien wel eens van gehoord?

Fail... Dat heeft hij nooit gezegd. Maar bedankt voor het herhalen van een hoax...

Ik zou zeggen zoek hem eens na en je zal zien dat er niets van waar is.

[Verwijderd]

Het punt was dat het niet slim is om beperkingen in te bouwen omdat jij je toevallig niet kunt voorstellen dat iets ooit nodig zal zijn, maar goed - dat wist je ook wel. Je wilde alleen graag even dissen, dus bij deze grote dikke vette RePsEcT voor je - hij heeft het inderdaad niet gezegd!

[Caelorum]

semyazaruax schreef op maandag 19 juni 2017 @ 10:43:
[...] rot dan dat je requests moet gaan gebruiken om te kijken naar volgende pagina('s), dan tikt het wel aan kan je flink in de buidel tasten voor een API abonnementje haha.[...]

Dat is waarom, als je veel requests verwacht naar redelijk dezelfde resource, je gewoon moet cachen op je eigen server. Dus alles via een eigen API laten lopen, die cachet en eventueel op de achtergrond de request doorsluist.