...
- 500 – Interne serverfout, Dit kunnen technische of connectie problemen zijn met het backend systeem.
- 501 – Server heeft de HEAD aanvraag niet geïmplementeerd. HEAD is hetzelfde als GET, maar dan zonder body.
- 503 – Dienst niet beschikbaar. De aangeboden dienst kan in onderhoud zijn.
Autorisatie fouten.
In een productieomgeving is het wenselijk om voor het (kunnen) autoriseren zo min mogelijk informatie weg te geven.Bij autorisatie fouten moet de dienstverlener (server) zo min mogelijk informatie weggeven. Het retourneren van te veel informatie kan details over de toegang blootleggen die NIET naar gebruikers gecommuniceerd mogen worden.
Bijvoorbeeld de toegang tot het systeem wordt geweigerd omdat de vereiste verificatie ontbreekt of omdat de gebruiker NIET is geautoriseerd om toegang te krijgen of NIET toegang krijgt tot specifieke gegevens of om andere beleidsredenen.
Om de bruikbaarheid van de response af te wegen tegen de juiste hoeveelheid (detail) informatie te openbaren aan de gebruiker, moeten we dit met een bepaald beleid doordacht doorvoeren.
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.
Is het antwoord ‘nee’ of kan dat niet worden bepaald, bijvoorbeeld omdat de (FHIR) resource nodig is om deze beslissing te kunnen nemen en de resource niet bestaat, dan wordt 403 "Forbidden" teruggegeven.
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 biedt om de toegangscontrole (volledig) te scheiden van de business code.
...
Neem zoveel mogelijk context op in uw berichten en wees beschrijvend (als het geen autorisatie fouten betreft) .
Als dit niet gedaan wordt, kost het veel ondersteuning: als de applicatie ontwikkelaars niet kunnen achterhalen waarom een aanvraag fout is gegaan, zullen ze hulp zoeken - en uiteindelijk zullen anderen tijd moeten besteden aan het opsporen van fouten.
...