Welke response code te gebruiken?

[NeFoRcE]

Dag iedereen,

Ik heb een korte vraag, maar kom er niet achter wat nou het juiste antwoord is.

Ik heb een PHP script waarbij een externe partij data naar toe post. Nou wordt die data afgehandeld, maar voor het zover is, worden er meerdere checks uitgevoerd. Bijvoorbeeld of de incoming data wel van een bepaald type is, of de request wel toegestaan is, en - en nu komt het - of de gegevens al reeds in de DB staan / verwerkt zijn.

Wat voor response code zou je nou het beste kunnen gebruiken voor bijvoorbeeld dat laatste puntje?

[denyos]

Je zou kunnen denken aan code 409 - Conflict omdat het conflicterende data is.
Een 304 - Not modified zou natuurlijk ook kunnen. Je wijst de nieuwe data af, en de oorspronkelijke data blijft ongewijzigd.

[Devilly]

denyos schreef op donderdag 03 maart 2016 @ 10:13:
Je zou kunnen denken aan code 409 - Conflict omdat het conflicterende data is.
Een 304 - Not modified zou natuurlijk ook kunnen. Je wijst de nieuwe data af, en de oorspronkelijke data blijft ongewijzigd.

304 Not Modified is meer voor het ophalen van data en daarmee voor een GET. De 409 Conflict vind ik een passelijke status code. Je stuurt data op en de server kan de request niet uitvoeren vanwege een conflict in de data (die is meegestuurd met de request ten opzichte van de data die al op de server aanwezig is).

[NeFoRcE]

Dank mensen! 409 it is. Heb 'm denk ik over het hoofd gezien (het zijn er ook zo veel). Dank!

[Haan]

Afhankelijk van hoe je de externe partij precies van je API gebruik maakt, zou je ook nog de meer generieke 400: Bad request kunnen gebruiken. Meer detail kan mooi zijn, maar meer foutcodes zorgt ook voor meer documentatie en meer werk voor de andere aanroepende partij om met alle verschillende foutcodes om te gaan.

[YakuzA]

Ik zou zelf een http200 doen met een bericht met een application level error die je terug geeft.

Het is raar om application level errors in je http response code te gaan verwerken.

[NeFoRcE]

YakuzA schreef op donderdag 03 maart 2016 @ 13:26:
Ik zou zelf een http200 doen met een bericht met een application level error die je terug geeft.

Het is raar om application level errors in je http response code te gaan verwerken.

Hier twijfelde ik ook over inderdaad. Ik heb de andere partij gevraagd of dit standaard 200 moest worden (nog voor jouw bericht). Maar geen reactie op gekregen (nog).

[Voutloos]

Tja, dat is gewoon een keuze, in hoeverre je het REST noemt en enkel HTTP methods en/of status codes gebruikt op resource names.

En dat kan gewoon allebei, maar die keuze is soms voer voor jarenlange discussies met miljoenen berichten. Dus begin flamewar na deze post.

[Siebsel]

Een 422 is beter op z'n plaats. Een 409 gaat meer over conflicterende requests (van 2 kanten komt exact dezelfde request, maar met andere data), 422 betekend dat je request wel goed is, maar ergens in je data wat faalt.

Zie ook de flowcharts op http://racksburg.com/choosing-an-http-status-code/.

En een 200 kan wel, maar moet je eigenlijk niet willen. Wat er ook gebeurd, het is niet "200 OK", er is ergens iets verkeerd gegaan.

Het is raar om application level errors in je http response code te gaan verwerken.

Een HTTP-code is zelden de volledige error. Het is slechts een indicatie, zoals hierboven ook al ergens staat zou je ook een generieke 400 kunnen gooien. In de body van de pagina kun je prima je application errors laten zien. Ik vind het zelf nog veel gekker dat als ik een request doe, ik eerst de hele body (of iig een deel ervan) moet parsen om te zien of (en wat) er verkeerd is gegaan.

edit:

Haan schreef op donderdag 03 maart 2016 @ 13:13:
[...]
meer werk voor de andere aanroepende partij om met alle verschillende foutcodes om te gaan.

Mwoah, niet helemaal waar. Als je lui bent, kun je checken op "statuscode >= 200 && < 300" en als dat het geval is, je content tonen en anders een foutmelding.

[ Voor 20% gewijzigd door Siebsel op 03-03-2016 15:54 ]

[CodeCaster]

YakuzA schreef op donderdag 03 maart 2016 @ 13:26:
Ik zou zelf een http200 doen met een bericht met een application level error die je terug geeft.

Het is raar om application level errors in je http response code te gaan verwerken.

Dat valt wel mee, en die discussie is al veel vaker gevoerd.

Zie bijvoorbeeld mjin topic hier: Programmers.SE: Do web applications use HTTP as a transport layer, or do they count as an integral part of the HTTP server?.