En API uten resultat og en API med feil krever to forskjellige behandlinger. Et vellykket søk kan returnere ingen steder innenfor det søkte området. Et nettverksfeil, en nådd grense eller en utilgjengelig kilde hindrer derimot å trekke konklusjoner basert på søket.
For ROOTE, kontroller HTTP-responsen, så forretningsstatus, forventet samling og dekning. Denne tilnærmingen unngår å vise «ingen toaletter» når et Tjenester-kall feilet eller «ingen stopp» etter tidsavbrudd.
Les de tre nivåene av et svar
| Nivå | Å kontrollere | Mulig konklusjon |
|---|---|---|
| Transport | Tilkobling, tid og HTTP-status | Lyktes forespørselen? |
| Kontrakt | Gyldig JSON, versjon og forventede felter | Er svaret brukbart? |
| Forretningsresultat | status, samlinger, dekning, advarsler og meta | Hva vet vi innenfor det forespurte området? |
En HTTP 200-kode er ikke nok til å validere et søk. Svaret kan indikere delvis utførelse eller status error. På den andre siden er en 404 på en rute ikke en normal måte å uttrykke en tom samling på: sjekk URL og kontrakt.
Forstå success, empty, partial og error
| Status | Anbefalt handling |
|---|---|
| success | Vis enhetene etter validering og behold begrensningene |
| empty | Informer at ingen resultater ble returnert for dette søket |
| partial | Vis brukbare data med deres advarsler |
| error | Presenter søket som utilgjengelig; ikke konkluder med at steder mangler |
Manglende resultat gjelder for en spesifikk forespørsel og kjente kilder. Det beviser ikke at ingen tjenester fysisk eksisterer. Begrenset dekning, restriktive filtre eller anvendte grenser kan redusere antall resultater.
Et beslutningstre for ditt brukergrensesnitt
1. La requête a-t-elle abouti ?
Non → indisponibilité réseau ou délai dépassé.
2. Le statut HTTP est-il acceptable selon le contrat ?
Non → traiter le code et le message d'erreur.
3. Le JSON respecte-t-il le schéma attendu ?
Non → réponse inexploitable, jamais "aucun résultat".
4. Le statut métier est-il error ?
Oui → recherche indisponible.
5. Le statut est-il partial ou la couverture limitée ?
Oui → résultats utilisables + avertissement.
6. La collection attendue est-elle vide ?
Oui → aucun résultat retourné dans ce périmètre.
Non → afficher les résultats et leurs limites.Sjekk parametere i riktig rekkefølge
Kontroller først breddegrad og lengdegrad, deres rekkefølge og byen som er hentet. Sjekk deretter radius-enheten og filtervokabular. API-tjenester bruker types=toilets; et kart-URL bruker modes=toilets. Disse parametrene tilhører forskjellige kontrakter.
Utvid deretter en dimensjon om gangen: øk radius innen rutegrenser eller fjern et filter for en eksplisitt test. Behold spor av den opprinnelige forespørselen. Ved automatisk utvidelse, informer brukeren om det nye området.
Bygg et API-søk med GPS-koordinater
Håndter en utilgjengelig kilde uten å miste de andre
Et delvis svar kan inneholde steder fra kilder som responderte mens en annen feilet. Behold disse resultatene, deres attributter og relevante advarsler. Presenter ikke listen som fullstendig og erstatt ikke manglende felt med misvisende standardverdier.
Lagret eldre informasjon i cache kan også være nyttig om retningslinjene dine tillater dette som fallback. Den må fortsatt merkes som gammel. Tiden for din forespørsel gjør ikke observasjonen nyere.
Tilpass meldinger og fallback-mekanismer
| Situasjon | Melding tilpasset ditt grensesnitt | Handling |
|---|---|---|
| empty | Ingen resultater returnert i dette området med disse filtrene | Endre område eller filtre |
| partial | Noen resultater er tilgjengelige; søket er ufullstendig | Vis resultater og advarsel |
| Valideringsfeil | Søket inneholder en ugyldig parameter | Rett opp forespørselen |
| Autentisering eller rettigheter | Denne tilgangen tillater ikke dette søket | Sjekk konto eller token |
| Begrensning eller utilgjengelighet | Søket er midlertidig utilgjengelig | Følg retningslinjer for gjenopptakelse |
For en 429, se tjenestens retningslinjer og eventuelt Retry-After. En 400-feil krever korreksjon av argumentene; å genta samme forespørsel løser det ikke. Ikke endre automatisk en 401 til anonymt kall hvis brukeren har gitt token.
Test de fire tilstandene før publisering
Forbered komplette testresponser: fullstendige, tomme, delvise og med feil, samt ugyldig JSON og tidsavbrudd. Verifiser vist melding, beholdte resultater og antall gjenopptakelser. Det viktigste er at en feil aldri skal gi påstand om manglende tjenester.
Bruk disse reglene i en AI-assistent
Forstå formater for mobilitetsdata
Ofte stilte spørsmål
Beviser en tom liste at det ikke finnes toaletter?
Nei. Den indikerer bare at ingen resultater ble funnet i det søket og de konsulterte kildene.
Kan man vise delvis svar?
Ja, hvis de brukte enhetene er gyldige og advarsler og nødvendige begrensninger bevares.
Bør man gjenta hver feil?
Nei. Rette parametere eller tilgangsfeil; begrens gjenopptakelse til midlertidige feil og følg tjenestens retningslinjer.