RFC 9457 (Problem Details for HTTP APIs)

Az RFC 9457 ("Problem Details for HTTP APIs") az IETF szabványa, amely egységes, gép által olvasható formátumot definiál a HTTP API-k hibaválaszaihoz. A probléma részleteit JSON-objektumként (vagy XML-ként) adja át a válasz törzsében, a application/problem+json médiatípus alatt, így az API-kliensek anélkül értik meg a hiba okát, hogy minden szolgáltató saját hibastruktúrát találna ki. Az RFC 7807 (2016) utódja; 2023 júliusában jelent meg Standards Track státuszban.

Mi az az RFC 9457?

A HTTP státuszkódok (pl. 400 Bad Request, 403 Forbidden, 404 Not Found) önmagukban gyakran nem adnak elég információt a hibáról. Emberi felhasználóknak a böngészőbe érkező HTML-oldal még érthető, de egy gépi API-kliens számára nincs mód a hibadokumentum egységes feldolgozására, ha minden API más formátumot használ.

Az RFC 9457 erre ad megoldást: egy közös, bővíthető JSON-objektumot ("problem details" — hibadetailed leíró dokumentumot) definiál, amelybe az API a hiba típusát, címét, részleteit és egyedi előfordulását teszi. A generikus HTTP-szoftverek (proxik, gyorsítótárak, tűzfalak, terheléselosztók) továbbra is a státuszkód alapján döntenek, az API-specifikus részletek pedig a válasz törzsében, szabványos formában jelennek meg.

Például a 403 Forbidden státuszkódot használhatjuk arra, hogy jelezzük: nincs elegendő egyenleg a vásárláshoz. A hiba miértjét (és például az aktuális egyenleget) azonban csak a válasz törzsében tudjuk átadni — pontosan erre való a problem details objektum.

A problem details objektum mezői

A hibaobjektum az alábbi, szabványos mezőkből állhat:

Mező Típus Jelentés
type URI-hivatkozás (string) A hibaprobléma-típus azonosítója. Alapértelmezett értéke about:blank.
title string A hibatípus rövid, embereknek szóló összefoglalója.
status szám A szerver által generált HTTP státuszkód (tájékoztató jellegű).
detail string Az adott hiba-előfordulásra jellemző, emberi magyarázat.
instance URI-hivatkozás (string) A hiba konkrét előfordulásának egyedi azonosítója.

Egyetlen mező sem kötelező. A type hiánya esetén a rendszer about:blank-nak tekinti, ami azt jelenti, hogy a hibának nincs többletjelentése a státuszkódon túl — ekkor a title a státuszkód szabványos szövegével (pl. "Not Found") egyezzen meg.

Kulcsfontosságú szabályok

  • A type URI a hibatípus elsődleges azonosítója. Lehetőleg abszolút URI legyen, és ha feloldható, HTML-dokumentációra mutasson a hiba megoldásáról.
  • A status mező csak tájékoztató: a generátornak ugyanazt a státuszkódot kell a tényleges HTTP-válaszba is tennie, nehogy a generikus HTTP-szoftverek rosszul reagáljanak.
  • A detail-t a kliensek ne elemezzék géppel (pl. reguláris kifejezéssel) — erre a problémaspecifikus bővítmények (extension) valók.
  • Az ismeretlen bővítményeket a kliensnek kötelessége figyelmen kívül hagyni, így a hibatípusok biztonságosan bővíthetők.

Példák

Egyenleghiány (403 Forbidden)

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: hu

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "Nincs elegendő egyenleg.",
  "detail": "A jelenlegi egyenleged 30, de a tétel ára 50.",
  "instance": "/account/12345/msgs/abc",
  "balance": 30,
  "accounts": ["/account/12345", "/account/67890"]
}

Itt a balance és accounts mezők a "nincs kredit" hibatípus saját bővítményei: a kliens ez alapján tudja kezdeményezni az egyenlegfeltöltést.

Validációs hiba (422 Unprocessable Content)

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Language: en

{
  "type": "https://example.net/validation-error",
  "title": "A kérés nem érvényes.",
  "errors": [
    { "detail": "must be a positive integer", "pointer": "#/age" },
    { "detail": "must be 'green', 'red' or 'blue'", "pointer": "#/profile/color" }
  ]
}

A validációs hibák listája a errors bővítménnyel adható át; a pointer mező JSON Pointer alapján (RFC 6901) mutat a hibás mezőre a kérés törzsében. A JSON mellé az RFC XML-változatot is definiál (application/problem+xml, urn:ietf:rfc:7807 névtér).

Mikor használd, és mikor ne?

Az RFC javaslata szerint:

  • Generikus hibák (pl. "nincs írási jogosultság") esetén ne definiálj külön hibatípust — a 403 Forbidden önmagában is érthető.
  • Ha már létezik domain-specifikus hibadokumentum-formátumod, az API-d saját formátumát érdemes használni; a problem details célja a saját "hiba/error" formátumok kidolgozásának elkerülése, nem azok felülírása.
  • A problem details nem debuggoló eszköz a szerver belső működéséhez; a hibaüzenet a HTTP-interfész részletességét hivatott növelni, nem a call stack-et kiszivárogtatni.

Mi változott az RFC 7807-hez képest?

Az RFC 9457 az RFC 7807-tel szemben a következőket pontosította (2023):

  • Problem Type Registry: az IANA új nyilvántartást vezetett (http-problem-types), ahová közös, újrahasznosítható hibatípus-URI-k regisztrálhatók.
  • Több hiba kezelése: ha egy kérésben több, eltérő típusú hiba van, a "legrelevánsabb" vagy legsürgősebb probléma reprezentálása javasolt; a különböző típusokat összefogó "batch" hibatípusok nem illenek jól a HTTP-szemantikába.
  • Nem feloldható type URI-k: útmutatást ad a nem dereferálható URI-k (pl. tag: séma) használatához, ugyanakkor a feloldható URI-ket részesíti előnyben.

Biztonsági megfontolások

Új hibatípus definiálásakor és a hibaválasz generálásakor is óvatosan kell eljárni: a hibadokumentum ne fedjen fel szerverspecifikus belső részleteket (stack dump, adatbázis-szerkezet, belső üzenetek), mert ezek támadási vektorrá válhatnak. A status mező megkettőzi a HTTP státuszkódot — ha a kettő eltér, az jelezheti, hogy egy köztes elem (pl. proxy) módosította a választ, a generikus szoftverek viszont a tényleges státuszkódot veszik alapul.

Gyakran ismételt kérdések (FAQ)

Mi az az RFC 9457? Az IETF szabványa, amely egységes JSON/XML formátumot (problem details) definiál a HTTP API-k hibaválaszaihoz.

Milyen médiatípust használ? JSON formátum esetén application/problem+json, XML esetén application/problem+xml.

Melyik RFC-t váltja fel? Az RFC 7807-et (2016) váltja fel; a hivatkozás szerint az RFC 9457 "Obsoletes: 7807".

Kötelezők a mezők? Nem. Csak a type-nek van alapértelmezett értéke (about:blank); a többi mező opcionális, és a type jelentését bővítő egyéni mezők is megengedettek.

Mikor érdemes használni? Amikor a 4xx/5xx státuszkód önmagában nem elég, és gép-olvasható hiba-részleteket is át kell adni a kliensnek — pl. 403 egyenleg hiba, 422 validációs hibák, 429 rate limit.

Hivatkozások