Eine API ohne Ergebnis und eine API mit Fehler erfordern unterschiedliche Behandlungen. Eine erfolgreiche Suche kann im abgefragten Bereich keine Orte zurückgeben. Ein Netzwerkfehler, erreichte Limits oder eine nicht verfügbare Quelle verhindern hingegen eine abschließende Bewertung der Suche.
Für ROOTE prüfen Sie zunächst die HTTP-Antwort, dann den geschäftlichen Status, die erwartete Sammlung und die Abdeckung. Diese Vorgehensweise vermeidet die Anzeige von „keine Toilette“, wenn ein Service-Aufruf fehlschlägt, oder „keine Haltestelle“, nachdem eine Wartezeit überschritten wurde.
Die drei Ebenen einer Antwort lesen
| Ebene | Zu prüfen | Mögliche Schlussfolgerung |
|---|---|---|
| Transport | Verbindung, Zeitüberschreitung und HTTP-Status | War die Anfrage erfolgreich? |
| Vertrag | Gültiges JSON, Version und erwartete Felder | Ist die Antwort nutzbar? |
| Geschäftsergebnis | Status, Sammlungen, Abdeckung, Warnungen und Meta-Daten | Was ist im abgefragten Bereich bekannt? |
Ein HTTP-Code 200 reicht nicht aus, um eine Suche zu validieren. Die Antwort kann eine teilweise Ausführung oder einen Fehlerstatus melden. Umgekehrt ist ein 404 auf einer Route kein normaler Weg, um eine leere Sammlung auszudrücken: Prüfen Sie URL und Vertrag.
Verstehen von success, empty, partial und error
| Status | Empfohlene Behandlung |
|---|---|
| success | Entitäten nach Validierung anzeigen und Limits beibehalten |
| empty | Angeben, dass für diese Suche kein Ergebnis zurückgegeben wurde |
| partial | Verwendbare Informationen mit Warnhinweisen anzeigen |
| error | Suche als nicht verfügbar darstellen; nicht auf Abwesenheit von Orten schließen |
Ein fehlendes Ergebnis betrifft eine Anfrage und bekannte Quellen. Es beweist nicht, dass kein physischer Service existiert. Eine unvollständige Abdeckung, restriktive Filter oder angewandte Limits können Ergebnisse reduzieren.
Ein Entscheidungsbaum für Ihre Benutzeroberfläche
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.Parameter in der richtigen Reihenfolge prüfen
Prüfen Sie zuerst Breiten- und Längengrad, deren Reihenfolge und die erhaltene Stadt. Überprüfen Sie dann die Einheit des Radius und die Filtervokabeln. Die Service-API verwendet types=toilets; eine Karten-URL verwendet modes=toilets. Diese Parameter gehören zu unterschiedlichen Verträgen.
Erweitern Sie anschließend jeweils nur eine Dimension: Erhöhen Sie den Radius innerhalb der Routenbeschränkungen oder entfernen Sie einen Filter für einen expliziten Test. Behalten Sie die ursprüngliche Anfrage im Blick. Falls Sie automatisch erweitern, zeigen Sie dem Nutzer den neuen Bereich an.
Eine API-Suche rund um GPS-Koordinaten aufbauen
Eine nicht verfügbare Quelle behandeln, ohne andere zu verlieren
Eine Teilantwort kann Orte enthalten, die von Quellen stammen, die geantwortet haben, während eine andere fehlgeschlagen ist. Bewahren Sie diese Ergebnisse, ihre Zuordnungen und die relevante Warnung. Stellen Sie die Liste nicht als vollständig dar und ersetzen Sie fehlende Felder nicht durch irreführende Standardwerte.
Auch im Cache gespeicherte alte Informationen können nützlich sein, wenn Ihre Richtlinie diesen Rückgriff erlaubt. Sie müssen als alt gekennzeichnet bleiben. Der Zeitpunkt Ihrer Anfrage erneuert nicht die ursprüngliche Beobachtung.
Meldungen und Wiederholungen anpassen
| Situation | Meldung zur Anpassung an Ihre Schnittstelle | Aktion |
|---|---|---|
| empty | Kein Ergebnis in diesem Bereich mit diesen Filtern | Bereich oder Filter anpassen |
| partial | Einige Ergebnisse sind verfügbar; die Suche ist unvollständig | Ergebnisse und Warnung anzeigen |
| Validierungsfehler | Die Suche enthält einen ungültigen Parameter | Anfrage korrigieren |
| Authentifizierung oder Berechtigungen | Dieser Zugriff erlaubt diese Suche nicht | Konto oder Token prüfen |
| Limit oder Nichtverfügbarkeit | Die Suche ist vorübergehend nicht verfügbar | Wiederholungsanweisungen befolgen |
Bei 429 beachten Sie die Anweisungen des Dienstes und das eventuelle Retry-After. Ein Fehler 400 erfordert eine Korrektur der Argumente; dieselbe Anfrage zu wiederholen löst das Problem nicht. Wandeln Sie einen 401 nicht automatisch in einen anonymen Aufruf um, wenn der Nutzer ein Token geliefert hat.
Die vier Zustände vor Veröffentlichung testen
Bereiten Sie vollständige, leere, teilweise und fehlerhafte Testantworten vor, sowie ungültiges JSON und Zeitüberschreitungen. Prüfen Sie die angezeigte Meldung, die erhaltenen Ergebnisse und die Anzahl der Wiederholungen. Der wichtigste Test ist, dass ein Ausfall niemals eine Behauptung über das Fehlen von Services erzeugt.
Diese Regeln in einem KI-Assistenten anwenden
Die Datenformate der Mobilität verstehen
Häufige Fragen
Beweist eine leere Liste das Fehlen von Toiletten?
Nein. Sie zeigt nur, dass keine Ergebnisse für diese Suche und die abgefragten Quellen zurückgegeben wurden.
Kann man eine Teilantwort anzeigen?
Ja, wenn die verwendeten Entitäten gültig sind und die notwendigen Warnungen sowie Limits beibehalten werden.
Muss man bei jedem Fehler neu versuchen?
Nein. Korrigieren Sie Parameter- oder Zugriffsfehler; begrenzen Sie Wiederholungen bei vorübergehenden Problemen und beachten Sie die Anweisungen des Dienstes.