...
De HTTP-standaard biedt meer dan 70 statuscodes om de return waarden te beschrijven. We hebben ze niet allemaal nodig. Gebruik HTTP-statuscodes en probeer ze netjes aan relevante standaardcodes toe te wijzen. De meeste REST API-providers gebruiken een kleine subset. Zie: https://www.hl7.org/fhir/http.html#Status-Codes
- retourneer NIET alleen de HTTP-statuscode 200 (OK), ongeacht of het succesvol dan wel een fout betreft
- gebruik de range 2xx, wanneer een aanvraag (volledig) verwerkt en geslaagd is.
- gebruik de range 3xx, wanneer de client aanvullende acties moet ondernemen (omleiding) om een bepaalde aanvraag te voltooien. De vereiste actie kan worden uitgevoerd zonder interactie met de gebruiker, als het tweede verzoek een GET of HEAD is.
- gebruik de range 4xx, wanneer de aanvraag niet (volledig) slaagt en de client deze aanvraag kan laten slagen door de aanvraag aan de client kant aan te laten passen.
- gebruik de range 5xx, wanneer de aanvraag niet (volledig) slaagt door een interne foutmelding aan de server kant
...
- 200 – OK. De aanvraag is verwerkt en geslaagd en de response van de payload is niet leeg (gebruikt met GET- en POST-verzoeken)
- 201 – Nieuwe gegevens zijn aangemaakt en gepersisteerd (gebruikt met POST-verzoeken)
- 202 – Geaccepteerd. Als de verwijderde aanvraag is geaccepteerd, zonder aanvullende informatie over de uitkomst
- 204 – Geen inhoud – De gegevens zijn succesvol aangepast of verwijderd. Geen payload in de response (gebruikt met PUT- en DELETE-verzoeken).
- 301 – Verplaats Verplaatst - De locatie van de gegevens zijn permanent verplaatst naar een andere locatie
- 304 – Niet gewijzigd – de klant kan gebruik maken van cache data met de If-Modified-Since of If-Nonen-Match HTTP headers
- 307 – Tijdelijk verplaatst - De locatie van de gegevens zijn tijdelijk verplaatst naar een andere locatie
...
Typische methoden die veel gebruikt worden, zijn:
Bestaat de FHIR Resource? | Kan autorisatie bepaalt worden? | Geautoriseerd? | HTTP Statuscode |
|---|---|---|---|
| √ | √ | √ | 20x (200 OK) |
| √ | √ | x | 401 Unauthorized |
| √ | x | ? | 403 Forbidden |
| x | √ | √ | 404 Not Found |
| x | √ | x | 403 Forbidden |
| x | x | ? | 403 Forbidden |
Het idee van bovenstaande regels is dat eerst wordt bepaald of de aanroeper (principal) gerechtigd (geautoriseerd) is voor een (FHIR) resource.
...
Op deze manier wordt geen informatie teruggegeven over het al dan niet bestaan van een (FHIR) resource aan een niet-geautoriseerde principal.
Een bijkomend voordeel van de strategie om eerst te bepalen of er toegang is, biedt meer ruimte om de toegangscontrole (volledig) te scheiden van de business code.
Aanvullende informatie over het gebruik van HTTP Statuscodes in REST APIs is te vinden op:
...
.
...
Neem zoveel mogelijk context op in uw berichten en wees beschrijvend (als het geen autorisatie fouten betreft) .
...
De clients moeten onderscheid maken tussen HTTP-statuscodes die een fout aangeven en de statuscodes die een probleem op applicatieniveau aangeven.
Eisen
[link naar eisen pagina (s)]ERR - Eisen (en aanbevelingen) voor foutafhandeling
Voorbeelden
De OperationOutcome resource bevat minimaal de volgende velden, beginnend met minimaal 1 issue en een severity die het type response aangeeft: fatal (fataal), error (fout) , warning (waarschuwing) of information (informatie)
...
Links naar gerelateerde onderwerpen
Aanvullende informatie over het gebruik van HTTP Statuscodes in REST APIs is te vinden op:
Oude tekst (kan op termijn wag)
...