Feilhåndtering
Feilmeldingen står i svaret
Tjenestene returnerer en lesbar melding, både i svarkroppen og i headeren
error-message. Den er ment for visning til brukeren, oversatt om nødvendig.
HTTP/1.1 403 Forbidden
error-message: Bruker har ikke tilgang til denne organisasjonen
401 og 403
Det plattformspesifikke å sjekke:
| Status | Sjekk her |
|---|---|
| 401 Unauthorized | Tokenet er utstedt av auth2.sirktek.com, audience stemmer, og det er ikke utløpt. |
| 403 Forbidden | X-auth-owner peker på riktig organisasjon, og brukeren eller API-nøkkelen har rettigheten. |
De åpne endepunktene godtar forespørsler uten token, men avviser et ugyldig eller utløpt token med 401.
Andre statuser
Det som avviker fra eller presiserer standarden her:
- 400:
error-messagesier hvilket felt som er feil. - 404: brukes også når du mangler lesetilgang til objektet.
- 429: rategrense på de åpne endepunktene. Ventetiden står i headeren
X-Rate-Limit-Retry-After-Seconds. - 500: som regel en bug hos oss. Meld fra til Sirktek med tidspunkt og forespørsel.
- 502/503/504: gjerne forbigående, i motsetning til 500.
Tomt svar er ikke feil
Tjenestesøket svarer 200 med tom liste når kategorien er ukjent. Sjekk stavingen av klassenavnet før du leter andre steder. Se Tjenestesøk.
Backend er sannheten
Klienter kan skjule knapper etter rettighetene i tokenet, men det er tjenesten som avgjør. En integrasjon skal derfor alltid håndtere 401 og 403 selv om den «vet» at brukeren har tilgang. Rettigheter kan endres mellom to kall. I ordre-API-et gjelder det samme for lenkene: følg dem, men vær forberedt på avslag.
Videre
- Autentisering. Hvordan tokenet hentes.