[HTTP/REST] welke status code gedeeltelijk geslaagd?

[Hopscotch]

Welke HTTP status code kan ik het best teruggeven als een deel van de request succesvol is verwerkt. In dit geval heb ik een PATCH in gedachten met een aantal wijzigingen die los van elkaar doorgevoerd kunnen worden. Stel ik stuur op die manier in een request 10 wijzigingen, maar 2 daarvan kunnen niet verwerkt worden. Wat is dan een passende status code?

Of is het dan beter/netter om 10 losse requests te sturen als ze onafhankelijk van elkaar mogen falen. Maar dan doe je een heleboel requests die net zo goed als 1 bulk request gedaan hadden kunnen worden.

De context: Ik ben aan het hobby-en met een toto site voor het aankomende WK voetbal, ik weet dat er een hoop kant en klaar is, maar ik wil het zelf bouwen omdat ik dat leuk en leerzaam vind.

Gebruikers kunnen straks voorspellingen doen van wedstrijden en een aantal bonusvragen. Ze hoeven niet alles van tevoren in te vullen, tijdens het toernooi mogen voorspellingen aangevuld en/of gewijzigd worden. Echter staat voor elke voorspelling wel een deadline.

Gebruikers hebben straks 10 voorspellingen ingevuld voor komende wedstrijden, willen die opslaan, maar voor een wedstrijd is net de deadline verlopen. Ik wil dan wel dat de andere 9 voorspellingen gewoon worden opgeslagen (geaccepteerd door de server), maar tegelijkertijd ook aangeven dat niet alles is verwerkt en tonen welke niet zijn verwerkt, met eventueel de reden erbij.

[Bartoz]

Een HTTP statuscode geeft alleen maar aan wat de server met jouw request gedaan heeft. Het zegt in feite niets over de afhandeling in jouw backend. Ik zou dus een HTTP 200 teruggeven met een response van de opgeslagen wedstrijden. De request is namelijk door de server verwerkt. De frontend kan deze meldingen dan tonen of er wat mee doen.

[DJMaze]

Daarvoor heb je 202 Accepted

In de result body plaats je dan per batch entry de status.

[ Voor 80% gewijzigd door DJMaze op 04-05-2018 15:59 ]

[Hopscotch]

@Bartoz Als ik een van de wijzigingen los zou sturen en deze zou niet verwerkt kunnen worden omdat bijvoorbeeld de deadline verstreken is zou ik wel een foutcode terugsturen, bijvoorbeeld 422 unprocessable en niet een 200.

@DJMaze 202 zegt The request has been accepted for processing, but the processing has not been completed. Dat laatste is zeker niet het geval. k kan de request direct verwerken en weet ook direct het resultaat.

[Bartoz]

Lees dit artikel eens https://stackoverflow.com...-response-to-post-of-data. Ik zou het bij een 200 houden met een json response object waar de niet verwerkte wedstrijden met een melding in verwerkt zijn.

[RobIII]

Ik zou het atomisch houden; óf het hele zwikkie lukt óf alles wordt teruggerold. Als er maar een deel "lukt" kan ik vervolgens gaan zitten uitpuzzelen wat er wel/niet gelukt is. Dan kun je beter 10 losse requests doen en van elke een ok/mislukt status geven.

[Sandor_Clegane]

Dit zou ik ook doen, gewoon een request per change. Http is best licht en het zal sneller gaan dan je denkt.

[farlane]

Sandor_Clegane schreef op vrijdag 4 mei 2018 @ 20:24:
... Http is best licht ...

[Sandor_Clegane]

farlane schreef op vrijdag 4 mei 2018 @ 22:47:
[...]

? Niet?

[The Eagle]

Je haalt twe dingen door elkaar: een technische status code (HTTP code), en een functionele status in je systeem.
Jij moet gewoon een technische code "ontvangen" teruggeven voor het geheel dat opgesturd wordt. . Daarnaast moet je iets maken dat een melding genereert wanneer er iets ingestuurd wordt waarvan de deadline verstreken is. Ontvangen, maar ga hem niet (meer) verwerken. Dat zou ik per mail doen, is wel het makkelijkste.

[farlane]

Sandor_Clegane schreef op vrijdag 4 mei 2018 @ 23:09:
[...]
? Niet?

Naja, alles is relatief natuurlijk, maar ik zou HTTP niet "licht" noemen nee.

[BugBoy]

In het WebDAV protocol is hiervoor HTTP status-code 207 (multi-status) bedacht. Nu is dat niet helemaal standaard HTTP, maar als je het in één call wilt houden dan zou ik dat op die manier doen. Zie RFC-4918 section 13 voor meer informatie.

Als de schrijf-acties volledig onafhankelijk van elkaar zijn, dan zou je ook kunnen overwegen om de requesten (deels) parallel af te vuren in plaats van sequentieel. Dan zet je meteen wat meer cores van je server aan het werk en je legt ook wat latency naast elkaar i.p.v. achter elkaar, waardoor het sneller kan zijn.

[Ed Vertijsment]

farlane schreef op vrijdag 4 mei 2018 @ 23:36:
[...]

Naja, alles is relatief natuurlijk, maar ik zou HTTP niet "licht" noemen nee.

Meh, valt volgens mij nog wel mij, zeker als je HTTP2 gebruikt.

Write first, optimize later

[Sandor_Clegane]

farlane schreef op vrijdag 4 mei 2018 @ 23:36:
[...]

Naja, alles is relatief natuurlijk, maar ik zou HTTP niet "licht" noemen nee.

Ik bedoelde meer dat in de gemiddelde applicatie het aannemen en afhandelen van een HTTP connectie vaak niet de bottleneck zal zijn.

Daarom is het vaak ook zo lame als je van die webserver benchmarks ziet.

[Ed Vertijsment]

Sandor_Clegane schreef op zaterdag 5 mei 2018 @ 00:14:
Daarom is het vaak ook zo lame als je van die webserver benchmarks ziet.

Hoewel ik het met je eens ben dat HTTP an sich echt niet een issue hoeft te zijn, zijn die benchmark indicaties (of gewoon apachebench stats) wel nuttig. Die meten namelijk browser <> webserver <> backend <> database.

Ofwel: hoelang zit it uit mn neus te vreten voordat ik content krijg. Het aandeel webserver zal nihiel zijn, het aandeel backend + database waarschijnlijk veel significanter, de grap is dat die tools dan weer niet kunnen zeggen welke de boosdoener is.

[Sandor_Clegane]

Dat is ook precies wat ik bedoel, je krijgt dan van die Node JS benchmarks die gewoon een status retourneren ipv daadwerkelijk wat werk verrichten.

[Hopscotch]

Bedankt voor alle reacties zover, de 207 is eigenlijk waar ik naar op zoek was, ik twijfel alleen nog of het ook de beste oplossing voor mijn probleem. Mijn hobby projectje is natuurlijk zo klein dat het niet heel veel uit zal maken, maar ik vroeg me het meer in algemene zin af wat je zou doen als het wel om een project zou gaan met veel gebruikers. Ik neig nu naar 1 request, maar alles atomisch verwerken. Eventueel kan ik aan de frontend kant nog iets inbouwen dat ik bij bepaalde fouten de reqeust zonder de gefaalde ietms nog eens stuur.

Ik vind een request per item ook wel mooi, maar als iemand zijn hele formulier in een keer invult kan dat oplopen tot 100 requests achter elkaar (of parallel, maar ik meen me te herinneren dat daar bij veel browsers een limiet op zit), dat lijkt me toch ook niet helemaal lekker.

[DJMaze]

Hopscotch schreef op zaterdag 5 mei 2018 @ 00:54:
als iemand zijn hele formulier in een keer invult kan dat oplopen tot 100 requests achter elkaar.

Dan is één batch request een prima oplossing.

Als voorbeeld hier hoe Google Calendar het doet: https://developers.google.com/calendar/batch
De multipart/mixed wordt dan opgesplitst en vervolgens multi-threaded uitgevoerd.

Dit is voor jou overkill als je database tabel niet multi-threaded werkt en de SQL queue de queries achter elkaar uitvoert. Dan moeten de scripts toch op elkaar wachten
Meerdere losse requests tegelijk heeft dus niet echt zin dan.

Er is wel een verschil:
- Bij een batch moet de gebruiker lang wachten en ziet in 1x het resultaat
- Bij losse requests ziet de gebruiker per item resultaat binnen stromen

Daarom gebruik ik meestal websockets (of simulatie) om de batch response tijd te verkorten en het lijkt op losse requests.
Hoe ik dat doe heb ik gedeeltelijk uitgelegd in DJMaze in "[php] meerdere sessies/clients live update"
Je kan in mijn CMS bijvoorbeeld een XML bestand uploaden met bergen SQL. De gebruiker ziet dan een venster met een progress bar die oploopt totdat alle SQL queries zijn uitgevoerd.
(heb net even een filmpje voor je gemaakt hoe dat er uit ziet)

Je kan natuurlijk alles bedenken met je creatieve brein hoe je het aan de gebruiker toont

[ Voor 67% gewijzigd door DJMaze op 05-05-2018 20:37 ]