Webservice response HTTP statuscodes

[P.O. Box]

Ik heb een vraagje over wat de juiste manier (of de meest gangbare manier) is om een webservice response te genereren.

ik heb nu een aantal webservice communicaties lopen met verschillende klanten / leveranciers. Iedere klant / leverancier heeft natuurlijk op zijn eigen manier zijn webservice opgezet.

ik stuur bijvoorbeeld naar klant A, B en naar C de volgende XML (per klant verschilt de XML uiteraard, maar even voor het idee):

XML:

<?xml>
<request>
<quotation>approved</quotation>
</request>

nu krijg ik van klant A de volgende response, met een HTTP statuscode 200 (OK):

XML:

<?xml>
<response>
<succeeded>false</succeeded>
</response>

nu krijg ik van klant B dezelfde response, maar dan met HTTP statuscode 40x / 50x (x E [0-9]).

van klant C krijg ik een HTTP statuscode 40x / 50x (x E [0-9]) terug, met wat error-tekst als returnwaarde.

Naar mijn idee zou ik alleen een HTTP statuscode 400 of hoger terug moeten krijgen indien mijn XML zelf verkeerd gevormd is, of ik de verkeerde service aanroep. Als mijn request XML gewoon goed is, maar de gevraagde actie een <succeeded>false</succeeded> teruggeeft omdat bijv de order niet bekend is, of de door mij ingevulde waarden niet aan de voorwaarden voldoen, etc, verwacht ik gewoon een HTTP 200 terug, met in de response XML de foutmelding.

m.a.w. m.i. moeten de HTTP statuscodes 400 en hoger alleen gebruikt worden voor fouten in de XML communicatie zelf... voor fouten in de verwerking van de XML (dus bijv. order is reeds afgesloten, dus quotation kan niet) zelf zou m.i. gewoon een HTTP statuscode 200 moeten worden teruggegeven met in de response XML de foutmelding.

In mijn ogen doet klant A uit mijn voorbeeld het dus goed. Maar heb ik hier wel gelijk in? Wat is de norm?

(ik hoop dat ik mijn vraag een beetje duidelijk heb kunnen maken?)

[Grijze Vos]

Doorgaans betekent 40x dat jij iets fout hebt gedaan, en 50x dat de server over zijn nek is gegaan.

[P.O. Box]

Grijze Vos schreef op dinsdag 03 april 2012 @ 16:07:
Doorgaans betekent 40x dat jij iets fout hebt gedaan, en 50x dat de server over zijn nek is gegaan.

ok, maar mijn vraag is dan... als ik 40x terugkrijg, wat voor soort fouten vallen daar dan onder?
als mijn request de verkeerde SOAPaction meekrijgt, of als er een > vergeten is in de XML dan snap ik wel dat ik een 40x terugkrijg... maar als de inhoud van mijn XML goed is, maar de order bijvoorbeeld al afgesloten is, waardoor mijn update "verboden" is... is het dan gangbaar om een 40x terug te geven, of is het dan logischer om een 200 terug te geven, met als inhoud van de response XML de foutmelding?

[MueR]

Ik gooi dit topic even naar Software Engineering & Architecture.

Persoonlijk vind ik een 4xx of 5xx code bij fouten wel logischer. Ik prefereer dergelijke codes boven een geretourneerde XML gaan parsen om te kijken of er misschien toevallig een foutmelding in zit.

[gorgi_19]

200 heeft als kenmerk 'OK', dus lijkt tegenstrijdig om dan fouten terug te geven.
400, al dan niet met subcodes, lijkt logischer.

[CodeCaster]

Als je SOAP als voorbeeld neemt:

quote: http://karpisek.net/2009/12/20/soap-fault-http-status-code/

In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 “Internal Server Error” response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error.
[...]
An INSTANCE MUST use a “500 Internal Server Error” HTTP status code if the response message is a SOAP Fault.

Altijd dezelfde fout dus, 500, met in het SOAP Fault-element het daadwerkelijke foutbericht.

Zie ook deze tabel: eigenlijk zijn alleen "400 Bad Request" (misvormde XML) en "500 Internal Server Error" (aanvraag kon om wat voor reden dan ook niet worden verwerkt) mogelijk.

En uiteraard de HTTP RFC:

quote: http://tools.ietf.org/html/rfc2616#section-10.5

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.

[ Voor 42% gewijzigd door CodeCaster op 04-04-2012 09:25 ]

[P.O. Box]

CodeCaster schreef op dinsdag 03 april 2012 @ 16:34:
Als je SOAP als voorbeeld neemt:

[...]

Maar is bijv een "customer not found" melding een soap-error? of niet?

in de url van je eerste quote staat een link naar:
http://www.ws-i.org/Profi...6.html#refinement16488480
toen ik iets naar boven scrollde dacht ik "nu ga ik het vinden", maar helaas...

Een Error 50x lijkt mij echt een fout te zijn op de ontvangende server. Hetgeen dus nooit mag komen door een fout aan de kant van de client.

Blijft over de 40x reeks. jij noemt het in je reactie al een "misvormde XML"... ik kan er inkomen als dit een Bad Request als resultaat heeft... dit kan dan inhouden dat er een > teveel staat, of dat er een verplicht veld vergeten is.... dat lijkt me nog logisch... maar wat als de fout van het niveau "customer not found" of "order in wrong state" is...
de verstuurde XML is goed geformeerd, de inhoud van de XML is semantisch correct, de XML voldoet aan de standaard die de klant gedefinieerd heeft... maar de actie die de XML zou moeten bewerkstelligen is niet mogelijk omdat de data in de XML niet correct is (verkeerd ordernummer) of dat die bewuste XML op dat moment niet verstuurd had "mogen" worden (order in verkeerde status)....

zoals ik het nu begrijp moet er dan toch een status 40x verstuurd worden... dit gaat tegen mijn gevoel in

[CodeCaster]

P.O. Box schreef op dinsdag 03 april 2012 @ 16:54:
[...]


Maar is bijv een "customer not found" melding een soap-error? of niet?

Ja. Met je "not found" vermoed ik een hint richting 404, maar die mag je server terugsturen als een verzoek naar een niet-bestaande service endpoint wordt gedaan.

Die vraag is interessanter bij puur HTTP, bijvoorbeeld bij een forum. Als gebruiker pietje niet bestaat, wat moet de URL /users/pietje dan teruggeven? En users.php?username=pietje?

Een Error 50x lijkt mij echt een fout te zijn op de ontvangende server. Hetgeen dus nooit mag komen door een fout aan de kant van de client.

Zie het dikgedrukte stuk in mijn laatste quote:

or is incapable of performing the request.

de verstuurde XML is goed geformeerd, de inhoud van de XML is semantisch correct, de XML voldoet aan de standaard die de klant gedefinieerd heeft... maar de actie die de XML zou moeten bewerkstelligen is niet mogelijk omdat de data in de XML niet correct is (verkeerd ordernummer) of dat die bewuste XML op dat moment niet verstuurd had "mogen" worden (order in verkeerde status)....

zoals ik het nu begrijp moet er dan toch een status 40x verstuurd worden... dit gaat tegen mijn gevoel in

De server kan je verzoek niet verwerken, om een niet-4xx reden: het HTTP-verzoek en de SOAP-body zijn immers volledig valide. Rest enkel status 500.

SOAP (nogmaals, als voorbeeld, want zoals ik je OP interpreteer is het meer een "ik stuur XML over HTTP want dat is hip", dus wat jouw leveranciers voor statuscodes terugsturen mogen ze zelf weten) is een laag bovenop HTTP. Als qua protocol met het verzoek an sich niets mis is, is het dus een SOAP error en dus een status 500.

Wat de fout daadwerkelijk inhoudt, mag je in het retourbericht vermelden. Hiervoor mag je wel zelf statuscodes verzinnen.

De enige uitzondering is misvormde XML:

quote: http://www.ws-i.org/Profi...6.html#refinement16488480

R1113 An INSTANCE SHOULD use a "400 Bad Request "HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

[ Voor 38% gewijzigd door CodeCaster op 03-04-2012 17:20 ]

[Kajel]

CodeCaster schreef op dinsdag 03 april 2012 @ 17:10:
[...]

Ja. Met je "not found" vermoed ik een hint richting 404, maar die mag je server terugsturen als een verzoek naar een niet-bestaande service endpoint wordt gedaan.

[...]

De server kan je verzoek niet verwerken, om een niet-4xx reden: het HTTP-verzoek en de SOAP-body zijn immers volledig valide. Rest enkel status 500.

[...]

Wat de fout daadwerkelijk inhoudt, mag je in het retourbericht vermelden. Hiervoor mag je wel zelf statuscodes verzinnen.

De enige uitzondering is misvormde XML:

[...]

toon volledige bericht

Ik ben het hier niet helemaal mee eens. Welke HTTP statuscodes je teruggeeft bij Webservices is nergens vastgelegd, en is zeker geen wet van Meden en Perzen. Daarbij is het ook niet heel relevant of het nou een SOAP webservice of REST betreft. Wat mij betreft is dat een beetje aan de bouwer van de webservice.
Je kunt verschillende kanten op:
- Request en XML kloppen, dus ongeacht of aan de request voldaan kan worden, geef je (met uitzondering van een server error, dus 500) altijd 200 terug, met eventuele "not found" messages oid, in de body.
- Opgevraagde data kan niet gevonden worden, kun je natuurlijk ook altijd als 404 zien. Dat is iig wat ik altijd doe. Dit valt bij gebruik van bepaalde clients nl heel mooi af te vangen in een try catch bijvoorbeeld. Als je dan een status code 200 terugkrijgt, terwijl je data niet gevonden is, dan weet je client niet dat er iets fout is, en dan kom je dus op het volgende punt uit:

MueR schreef op dinsdag 03 april 2012 @ 16:25:
Persoonlijk vind ik een 4xx of 5xx code bij fouten wel logischer. Ik prefereer dergelijke codes boven een geretourneerde XML gaan parsen om te kijken of er misschien toevallig een foutmelding in zit.

In de praktijk zijn er zoveel verschillende implementaties als er webservices zijn op het internet En aangezien er - in ieder geval wat betreft gebruik van HTTP status codes - geen volledig consensus is, kun je stellen dat geen van je klanten ongelijk heeft

[ACM]

't Lijkt me dat je vooral ook onderscheid in 400-codes moet gaan hanteren. Dus een "400 Bad Request" als jouw xml malformed is, "404 Not Found" of "410 Gone" als je een item opvraagt dat niet (meer) bestaat, 403 voor als je niet goed geauthenticeerd bent en 401 als je (dan alsnog) de rechten niet hebt, etc.

Mocht de server om e.o.a. reden niet mee willen werken, dan hoor je een status code uit de 500-reeks terug te krijgen.

En als het goed gaat eentje uit de 200-reeks.

Al die meldingen moeten alsnog ook vergezeld gaan van een response body waar je de oorzaak van de foutsituatie uit zou moeten kunnen afleiden.

Er is inderdaad niet echt iets vastgelegd voor REST. Maar je zou alsnog de http-specificatie kunnen proberen te volgen met statuscodes, waar mogelijk.

[CodeCaster]

Kajel schreef op woensdag 04 april 2012 @ 02:04:
[...]

Ik ben het hier niet helemaal mee eens. Welke HTTP statuscodes je teruggeeft bij Webservices is nergens vastgelegd, en is zeker geen wet van Meden en Perzen. Daarbij is het ook niet heel relevant of het nou een SOAP webservice of REST betreft. Wat mij betreft is dat een beetje aan de bouwer van de webservice.

Wat was die tabel die ik linkte dan? (Je moet even in de adresbalk klikken en op enter drukken, site is gaar). En dit verzin ik ook niet zelf:

quote: http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

If an error occurs processing the request, the HTTP binding specification requires that a HTTP 500 "Internal Server Error" be used with an embedded SOAP message containing a SOAP fault indicating the server-side processing error.

---

Je kunt verschillende kanten op:
- Request en XML kloppen, dus ongeacht of aan de request voldaan kan worden, geef je (met uitzondering van een server error, dus 500) altijd 200 terug, met eventuele "not found" messages oid, in de body.
- Opgevraagde data kan niet gevonden worden, kun je natuurlijk ook altijd als 404 zien. Dat is iig wat ik altijd doe.

ACM schreef op woensdag 04 april 2012 @ 07:52:
't Lijkt me dat je vooral ook onderscheid in 400-codes moet gaan hanteren. Dus een "400 Bad Request" als jouw xml malformed is, "404 Not Found" of "410 Gone" als je een item opvraagt dat niet (meer) bestaat, 403 voor als je niet goed geauthenticeerd bent en 401 als je (dan alsnog) de rechten niet hebt, etc.

In een webservice gebruik je HTTP als transportlaag. De statuscodes hiervan liggen vast. Code 404 betekent dat de resource die je via de URL probeert te benaderen, niet bestaat. Bestaat http://host/JouwService ineens niet meer als je een verzoek doet om bijvoorbeeld een niet-bestaande gebruiker op te vragen? Want dat is wat je met een statuscode van 404 zegt.

Om deze reden moet je gewoon een 500 teruggeven bij om het even welke fout die niet met het transport te maken heeft, omdat deze fouten applicatiespecifiek zijn, en dus in de applicatielaag moeten worden afgehandeld. Enter SOAP Fault, met als code Sender (SOAP 1.2) of Client (1.1):

quote: http://www.w3.org/TR/2007...art1-20070427/#faultcodes

The message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication (uitzondering: Basic Authentication, waarbij 401/403 wordt gebruikt) or payment information. It is generally an indication that the message is not to be resent without change (see also 5.4 SOAP Fault for a description of the SOAP fault detail sub-element).

Vervolgens kun je in de detail-sectie van de SOAP Fault aangeven wat er precies mis was met het verzoek, waarbij je dus applicatiespecifieke foutcodes mag verzinnen, eventueel zelfs voorzien van een gebruikersvriendelijke foutmelding.

Dit valt bij gebruik van bepaalde clients nl heel mooi af te vangen in een try catch bijvoorbeeld. Als je dan een status code 200 terugkrijgt, terwijl je data niet gevonden is, dan weet je client niet dat er iets fout is

Want een 500 gooit geen exception die je kunt afvangen?

In de praktijk zijn er zoveel verschillende implementaties als er webservices zijn op het internet

Omdat mensen niet weten waarmee ze bezig zijn, en geen bestaande frameworks gebruiken maar liever zelf het wiel opnieuw uitvinden.

Mocht de server om e.o.a. reden niet mee willen werken, dan hoor je een status code uit de 500-reeks terug te krijgen.

En "om een of andere reden" is dus ook als je verzoek qua opmaak helemaal valide is, maar op de server niet verwerkt kan worden omwille van de inhoud. Of wil je ook een "481 Factuurnummer al in gebruik" teruggeven?

[ Voor 19% gewijzigd door CodeCaster op 04-04-2012 09:35 ]

[mithras]

P.O. Box schreef op dinsdag 03 april 2012 @ 16:10:
[...]

maar als de inhoud van mijn XML goed is, maar de order bijvoorbeeld al afgesloten is, waardoor mijn update "verboden" is... is het dan gangbaar om een 40x terug te geven, of is het dan logischer om een 200 terug te geven, met als inhoud van de response XML de foutmelding?

De lijst van status codes is uitgebreider dan alleen "400: Bad Request" hoor. Wanneer door een bepaalde reden de order al afgesloten is, en jij vraagt om de order af te sluiten, kan je ook een 422: Unprocessable Entity retourneren. In de response staat dan de melding dat de order reeds gesloten is.

P.O. Box schreef op dinsdag 03 april 2012 @ 16:54:
[...]

de verstuurde XML is goed geformeerd, de inhoud van de XML is semantisch correct, de XML voldoet aan de standaard die de klant gedefinieerd heeft... maar de actie die de XML zou moeten bewerkstelligen is niet mogelijk omdat de data in de XML niet correct is (verkeerd ordernummer) of dat die bewuste XML op dat moment niet verstuurd had "mogen" worden (order in verkeerde status)....

zoals ik het nu begrijp moet er dan toch een status 40x verstuurd worden... dit gaat tegen mijn gevoel in

Daar zou _ik_ een 404 verwachten. Maar ik zit niet zo in SOAP, meer in simpelere XML-RPC en JSON-RPC tegen een REST server

CodeCaster schreef op dinsdag 03 april 2012 @ 17:10:
[...]

Die vraag is interessanter bij puur HTTP, bijvoorbeeld bij een forum. Als gebruiker pietje niet bestaat, wat moet de URL /users/pietje dan teruggeven? En users.php?username=pietje?

Wat is er verkeerd aan om een 404 terug te geven? Het is semantisch wel de juiste response.

CodeCaster schreef op woensdag 04 april 2012 @ 09:05:
[...]

In een webservice gebruik je HTTP als transportlaag. De statuscodes hiervan liggen vast. Code 404 betekent dat de resource die je via de URL probeert te benaderen, niet bestaat. Bestaat http://host/JouwService ineens niet meer als je een verzoek doet om bijvoorbeeld een niet-bestaande gebruiker op te vragen? Want dat is wat je met een statuscode van 404 zegt.

Niemand behalve jij heeft ooit SOAP bedoeld, de TS heeft SOAP niet eens genoemd. Nu moet je ook niet met de SOAP specs gaan strooien als het niet de enige mogelijkheid is. Ook gaf je eerst een voorbeeld /users/pietje wat uiteraard een valide URI kan zijn waar je ook een 404 op kan retourneren mocht pietje niet bestaan. Dat jij ineens komt met http://host/JouwService is natuurlijk niet zo relevant daarbij.

[...]

Vervolgens kun je in de detail-sectie van de SOAP Fault aangeven wat er precies mis was met het verzoek, waarbij je dus applicatiespecifieke foutcodes mag verzinnen, eventueel zelfs voorzien van een gebruikersvriendelijke foutmelding.

Wederom is dit vrij SOAP specifiek. Bij een veel vrijere REST server heb je meer vrijheid en is het (gelukkig!) ook gebruikelijk om HTTP status codes te gebruiken bij het processen van je entities. Je kan namelijk op een zeer eenvoudige manier bekijken wat er aan de hand is, waar je anders de response moet parsen om überhaupt te weten wat de fout is. Ik zou het hoogstens willen doen om meer details over de fout te weten te komen

[...]

Want een 500 gooit geen exception die je kunt afvangen?

We gebruiken ook allemaal throw exception;

[...]

En "om een of andere reden" is dus ook als je verzoek qua opmaak helemaal valide is, maar op de server niet verwerkt kan worden omwille van de inhoud. Of wil je ook een "481 Factuurnummer al in gebruik" teruggeven?

Als je strict wilt zijn, factuurnummer 481 zal je altijd krijgen, nooit zelf posten. Als je probeert een POST uit te voeren op /invoice/481 zal je hoogst waarschijnlijk 405: Method Not Allowed terugkrijgen, je kan nu eenmaal niet POST'en naar die URI. Mocht het toch mogelijk zijn om een factuurnummer als invoer te geven, kan je ook altijd 409: Conflict teruggeven, om aan te geven dat (een deel) van de entity in conflict is met een reeds bestaande.

[CodeCaster]

mithras schreef op woensdag 04 april 2012 @ 09:43:
Niemand behalve jij heeft ooit SOAP bedoeld, de TS heeft SOAP niet eens genoemd. Nu moet je ook niet met de SOAP specs gaan strooien als het niet de enige mogelijkheid is.

Lees de derde post eens, en ook mijn eerste post in dit topic.

Ook gaf je eerst een voorbeeld /users/pietje wat uiteraard een valide URI kan zijn waar je ook een 404 op kan retourneren mocht pietje niet bestaan.

Wat is er verkeerd aan om een 404 terug te geven? Het is semantisch wel de juiste response.

Bij welke dan? Bij /users/pietje kan ik het nog begrijpen, maar users.php?username=pietje? Bestaat users.php ineens niet meer?

Dat jij ineens komt met http://host/JouwService is natuurlijk niet zo relevant daarbij.

Eh, jawel, want dat is juist de kern van mijn post. 404 is een HTTP-statuscode die aangeeft dat de resource niet bestaat:

quote: http://tools.ietf.org/html/rfc2616#section-10.4.5

404 Not Found
The server has not found anything matching the Request-URI.

De query (?username=pietje) is echter ook onderdeel van de Request-URI, vandaar mijn vraag. 'Anything' is natuurlijk ook voor interpretatie vatbaar. De resource zelf (users.php) bestaat, er kan alleen geen user worden gevonden op basis van de query. Welke code is dan logisch?

Als je strict wilt zijn, factuurnummer 481 zal je altijd krijgen, nooit zelf posten. Als je probeert een POST uit te voeren op /invoice/481 zal je hoogst waarschijnlijk 405: Method Not Allowed terugkrijgen, je kan nu eenmaal niet POST'en naar die URI. Mocht het toch mogelijk zijn om een factuurnummer als invoer te geven, kan je ook altijd 409: Conflict teruggeven, om aan te geven dat (een deel) van de entity in conflict is met een reeds bestaande.

Ik bedoelde 481 als HTTP-statuscode. Zoals ik uit diverse reacties begrijp, vinden jullie het logisch om met diverse HTTP-statussen te strooien in de 400- of zelfs 500-reeks, en dat de client aan de hand van die code maar moet kijken wat er mis is. De pest is dus dat dát nergens is vastgelegd, en dan krijg je dus situaties zoals TS die schetst: iedere service doet maar wat, en er worden HTTP-statuscodes verzonnen (of, imho, misbruikt) bij het leven. De "409 Conflict" bijvoorbeeld, wat is het conflict dan? Dat zul je uit de body moeten gaan lezen. Als je dat toch al gaat doen, waarom dan niet één foutcode op HTTP-niveau gebruiken (namelijk 500), als je inhoudelijke fouten toch al uit de body haalt?

Als je geen SOAP gebruikt mag je het inderdaad allemaal zelf weten, het enige punt dat ik probeer te maken is dat ik het niet logisch vind om HTTP-statuscodes als applicatiefoutcodes te gebruiken, als je HTTP als transportlaag gebruikt.

[ Voor 17% gewijzigd door CodeCaster op 04-04-2012 10:34 ]

[Kajel]

CodeCaster schreef op woensdag 04 april 2012 @ 09:05:
[...]

In een webservice gebruik je HTTP als transportlaag. De statuscodes hiervan liggen vast. Code 404 betekent dat de resource die je via de URL probeert te benaderen, niet bestaat. Bestaat http://host/JouwService ineens niet meer als je een verzoek doet om bijvoorbeeld een niet-bestaande gebruiker op te vragen? Want dat is wat je met een statuscode van 404 zegt.

Om deze reden moet je gewoon een 500 teruggeven bij om het even welke fout die niet met het transport te maken heeft, omdat deze fouten applicatiespecifiek zijn, en dus in de applicatielaag moeten worden afgehandeld. Enter SOAP Fault, met als code Sender (SOAP 1.2) of Client (1.1):

De statuscodes liggen dan wel vast, maar zijn blijkbaar voor veelerlei uitleg vatbaar. Je zegt het zelf al in een latere reply: 404 betekent dat de resource niet meer bestaat. De resource is bv. de gebruiker die je opvraagt via de WebService, of het artikel. Dat hoeft niet te betekenen dat de endpoint niet meer bestaat!

[...]

Vervolgens kun je in de detail-sectie van de SOAP Fault aangeven wat er precies mis was met het verzoek, waarbij je dus applicatiespecifieke foutcodes mag verzinnen, eventueel zelfs voorzien van een gebruikersvriendelijke foutmelding.

Dat kan, maar HTTP status codes zijn universeler, dus gebruik ik die liever.

[...]

Want een 500 gooit geen exception die je kunt afvangen?


[...]

Ja, maar 404 is nog specifieker, die geeft nl aan dat iets niet bestaat, dus hoef ik niet de responsebody uit te lezen om een of andere applicatiespecifieke errorcode te vinden.

Omdat mensen niet weten waarmee ze bezig zijn, en geen bestaande frameworks gebruiken maar liever zelf het wiel opnieuw uitvinden.

Jep, Twitter, Facebook, al die partijen hebben het bij het verkeerde eind Die HTTP statuscodes zijn bedacht, lang voordat er WebServices bestonden. Het is dus perfectly valid om die op nieuwe manieren in te zetten, als de technologie evolueert. Dat is namelijk zo'n beetje de spil van het internet: het is in constante flux, er worden constant nieuwe zaken uitgevonden en aan toegevoegd. Als jij dan rigide wil vasthouden aan een set oude regeltjes, be my guest. Wij gaan ondertussen gewoon verder ok?
Innovatie gebeurt juist vaak door het breken of buigen van bestaande regels.

edit: ACM maakt een paar goede punten m.b.t. het onderscheiden van verschillende 4xx status codes. Kan ook heel nuttig zijn voor de client.

[CodeCaster]

Kajel schreef op woensdag 04 april 2012 @ 12:47:
[...]


De statuscodes liggen dan wel vast, maar zijn blijkbaar voor veelerlei uitleg vatbaar. Je zegt het zelf al in een latere reply: 404 betekent dat de resource niet meer bestaat. De resource is bv. de gebruiker die je opvraagt via de WebService, of het artikel. Dat hoeft niet te betekenen dat de endpoint niet meer bestaat!
[...]
Dat kan, maar HTTP status codes zijn universeler, dus gebruik ik die liever.
[...]
Ja, maar 404 is nog specifieker, die geeft nl aan dat iets niet bestaat, dus hoef ik niet de responsebody uit te lezen om een of andere applicatiespecifieke errorcode te vinden.
[...]
Die HTTP statuscodes zijn bedacht, lang voordat er WebServices bestonden. Het is dus perfectly valid om die op nieuwe manieren in te zetten, als de technologie evolueert. Dat is namelijk zo'n beetje de spil van het internet: het is in constante flux, er worden constant nieuwe zaken uitgevonden en aan toegevoegd. Als jij dan rigide wil vasthouden aan een set oude regeltjes, be my guest. Wij gaan ondertussen gewoon verder ok?
Innovatie gebeurt juist vaak door het breken of buigen van bestaande regels.

toon volledige bericht

Je gaat volledig aan mijn argument voorbij dat er een verschil is tussen een transportfout ("endpoint niet gevonden") en een applicatiefout ("gebruiker niet gevonden"). Je kunt toch een configuratiefout hebben, waardoor er naar een verkeerde URL wordt gecommuniceerd? Succes met debuggen als je client dan telkens "Gebruiker niet gevonden" meldt als je voor allebei een 404 gebruikt, want is namelijk juist niet specifiek, het kan meerdere dingen betekenen.

Je enige argument is "de technologie verandert, en jij bent een stugge zak omdat je HTTP-foutcodes niet creatief wil gebruiken". Als je zo wil discussiëren over een interessant onderwerp, be my guest, maar dan stop ik ermee.

Leg me eens uit wat de toegevoegde waarde is aan 'verzonnen' HTTP-foutcodes gebruiken, als je eigenlijk aan 2xx (gelukt), 4xx (transportfout) en 500 (applicatiefout) genoeg hebt? Als je zoals in bovengenoemd 404-geval onderscheid wil gaan maken tussen transport- of applicatiefout, of een applicatiespecifieke foutmelding wil weergeven, zul je dit in de body moeten verwerken, omdat je client niet genoeg informatie heeft aan enkel de code.

Mijn punt is dus: als je als client de body toch al moet gaan lezen om iets aan de foutcode te hebben (omdat de foutcode alléén niet genoeg is), waarom zou je dan niet voor alle applicatiefouten gewoon één HTTP-foutcode gebruiken?

Jep, Twitter, Facebook, al die partijen hebben het bij het verkeerde eind

Ik heb die namen nooit genoemd, ik heb het juist over de honderden partijen die denken dat ze het wel even beter weten zonder zich ook maar aan standaarden (HTTP, SOAP) of richtlijnen (REST) te houden, waardoor het servicelandschap (en zeker business-to-business) één groot drama is, wat TS ook al aangeeft.

---

Ik gooi er even een voorbeeld tegenaan, omdat abstractie leuk is, maar niet in zulke gevallen. Stel, je hebt een webservice waarbij je gebruikers kunt aanmaken. Deze service kent één positieve status, namelijk "1. Gebruiker aangemaakt", en een aantal negatieve statussen:
• 2. Gebruikersnaam al in gebruik
• 3. Wachtwoord niet complex genoeg
• 4. E-mailadres ongeldig

Hoe ga je dit dan terugsturen als je geen gebruik maakt van één "applicatiefout"-code? En waar begin je? "451 Gebruikersnaam al in gebruik"? En wat dan als er meerdere fouten in één bericht zitten?

Waarom dan niet gewoon 200 OK en 500 NOK gebruiken, waar je bij de 500 de fout(en) in de body zet? En dat zit dan ook nog niet eens per se vast aan 500, omdat dat nog discutabel is (de server doet helemaal niets fout, hij weigert het bericht juist omdat 'ie zo geprogrammeerd is), dus ook een 400, 403, 409 en 422 worden geopperd.

[ Voor 31% gewijzigd door CodeCaster op 04-04-2012 14:13 ]

[Anoniem: 241683]

Het probleem is dat je het snel over verschillende dingen hebt. Zoals ook hier te lezen valt: Wikipedia: Representational state transfer

Het is dus perfectly valid om die op nieuwe manieren in te zetten, als de technologie evolueert. Dat is namelijk zo'n beetje de spil van het internet: het is in constante flux, er worden constant nieuwe zaken uitgevonden en aan toegevoegd. Als jij dan rigide wil vasthouden aan een set oude regeltjes, be my guest. Wij gaan ondertussen gewoon verder ok?

Dit is een beetje makkelijk gezegd(daarnaast mag het ook wel iets minder sarcastisch ). Zoals ook in de tweede paragraaf van mijn bron: "Since it doesn't take advantage of HTTP conventions, SOAP works equally well over raw TCP, named pipes, message queues, etc"

Ik ben het CodeCaster eens over het gebruik van SOAP. Wanneer ik met een soap-server communiceer kijk ik naar de soapfaults en messages die terug gestuurd kunnen worden. status-codes hebben daar imho weinig te zoeken. Zodra ik over REST praat wil ik het hebben over statuscodes. Daarom is de topictitel ook niet goed, die moet specifieker.

[ Voor 72% gewijzigd door Anoniem: 241683 op 04-04-2012 13:55 ]

[Voutloos]

Bij een aantal standaarden, bijvoorbeeld SOAP en XML-RPC, ligt gewoon vast welke codes je moet gebruiken.

De REST beweging is wat losser wat dat betreft, maar de conventie is dat je juist zoveel mogelijk standaard HTTP methods en status codes gebruikt.

[Kajel]

Voutloos schreef op woensdag 04 april 2012 @ 14:13:
Bij een aantal standaarden, bijvoorbeeld SOAP en XML-RPC, ligt gewoon vast welke codes je moet gebruiken.

De REST beweging is wat losser wat dat betreft, maar de conventie is dat je juist zoveel mogelijk standaard HTTP methods en status codes gebruikt.

Point taken wat betreft SOAP en XML-RPC. Overigens vind ik REST daarom ook een netter en fijner protocol, al is het niet overal bruikbaar

[mithras]

CodeCaster schreef op woensdag 04 april 2012 @ 09:56:
[...]

Lees de derde post eens, en ook mijn eerste post in dit topic.

Ow, oeps Point taken

[...]

Bij welke dan? Bij /users/pietje kan ik het nog begrijpen, maar users.php?username=pietje? Bestaat users.php ineens niet meer?

In mijn werk (dus, RPC/REST) gaat het niet zozeer om de endpoint en is voor mij de constructie van de URL niet zo relevant. Uiteraard is de beste oplossing /users/pietje.

Als je geen SOAP gebruikt mag je het inderdaad allemaal zelf weten, het enige punt dat ik probeer te maken is dat ik het niet logisch vind om HTTP-statuscodes als applicatiefoutcodes te gebruiken, als je HTTP als transportlaag gebruikt.

_Ik_ ook _niet_ (maar de andere kant van het verhaal)

Voutloos schreef op woensdag 04 april 2012 @ 14:13:
Bij een aantal standaarden, bijvoorbeeld SOAP en XML-RPC, ligt gewoon vast welke codes je moet gebruiken.

De REST beweging is wat losser wat dat betreft, maar de conventie is dat je juist zoveel mogelijk standaard HTTP methods en status codes gebruikt.

^^ lijkt me ook de beste samenvatting voor de meningsverschillen

[P.O. Box]

Voutloos schreef op woensdag 04 april 2012 @ 14:13:
Bij een aantal standaarden, bijvoorbeeld SOAP en XML-RPC, ligt gewoon vast welke codes je moet gebruiken.

De REST beweging is wat losser wat dat betreft, maar de conventie is dat je juist zoveel mogelijk standaard HTTP methods en status codes gebruikt.

ik merk dat het topic een interessante discussie heeft opgeleverd... blijkbaar is "standaard" een rekbaar begrip

bij onze klanten verschilt het, de een gebruikt SOAP, de andere weer iets anders.... onze eigen webservice gebruikt ook SOAP, maar onze eigen webservice is nog verre van goed geprogrammeerd... omdat ik (als de werkzaamheden het ooit toelaten) onze eigen webservice wil uitbreiden en eigenlijk opnieuw wil bouwen, stelde ik deze vraag... mijn nieuwsgierigheid werd gewekt omdat onze klanten een mix van manieren gebruiken...

zoveel mogelijk standaard HTTP methods en status codes gebruiken dus

[matthijsln]

Heb nu een klant met een reverse proxy tussen het Ajax frontend en de backend die HTTP 400 of 500 errors omzet in een stomme foutmelding pagina met 200 OK

Dus altijd maar 200 gebruiken met een { success: false } in de body.

[ Voor 9% gewijzigd door matthijsln op 04-04-2012 17:06 ]