En spinner kan fortelle brukeren at noe skjer, men den kan ikke redde et uklart API. Den gode AJAX-opplevelsen begynner i svarformatet: hva serveren returnerer, hvordan feil beskrives, og hva frontend kan gjøre videre.

AJAX starter i svarformatet
AJAX starter i svarformatet visualiserer hovedpoenget i artikkelen.

Frontend trenger kontrakt, ikke gjetting

Et AJAX-endepunkt bør ha et stabilt svarformat. Frontend må vite hvor status, data, feilmeldinger og eventuell neste handling ligger. Uten en slik kontrakt ender JavaScript-koden ofte med mange små spesialtilfeller.

HTTP-status og JSON må støtte hverandre

HTTP-statuskoden bør fortelle den tekniske sannheten. Et valideringsproblem bør ikke fremstå som en vellykket 200-respons bare fordi JSON-feltet inneholder en feilmelding. Tydelige statuskoder gjør feilhåndteringen enklere.

Skille mellom teknisk feil og brukerbeskjed

Brukeren trenger ikke se interne detaljer, men må forstå hva som skjedde. Nettverksfeil, valideringsfeil og manglende tilgang bør gi ulike meldinger og ulik oppførsel i grensesnittet.

Statusmeldinger må være tilgjengelige

Når AJAX oppdaterer siden uten full sidelast, må viktige meldinger annonseres riktig. Statusmeldinger bør kunne oppfattes av både tastaturbrukere og skjermlesere uten at brukeren mister konteksten.

WEBoracle-vurdering

WEBoracle bør bruke samme svarstruktur i login, søk, kontrollpanel og innholdsredigering. Det gir mindre JavaScript, færre spesialtilfeller og bedre feilsøking.

Konklusjon

Spinneren er bare overflaten. Den gode AJAX-opplevelsen kommer fra en tydelig serverkontrakt, forutsigbare statuskoder og brukerrettede meldinger som frontend kan stole på.

Kilder og videre lesning

  1. MDN Web Docs: Using the Fetch API
  2. MDN Web Docs: Response.ok
  3. W3C/WAI: Understanding Status Messages