De Devschuur Coffee Corner - Iteratie ⑬

[Mugwump]

.oisyn schreef op dinsdag 16 september 2025 @ 13:12:
[...]

En zo fijn om die dingen gewoon lokaal te hebben met een index en search die zo goed als instant is, ipv die klotesite.

Hoorde ik daar iemand Confluence roepen?

[DevWouter]

ThomasG schreef op dinsdag 16 september 2025 @ 08:54:
[...]
Dat is niet wat ik heb gezegd, dat is wat jij er van maakt. Wat ik zei, of althans bedoelde, is dat er verschil zit in de kwaliteit van programmeurs en dat zie je terug in de code.

Ik was het gisteravond aan het herschrijven toen MacOs besloot te herstarten ivm update en toen was het... gaap... en...

Ik wilde meer nadruk leggen op het feit dat "sommige mensen" meer moeite doen dan anderen. Niet helemaal hetzelfde wat jij schreef (gezien jij de nadruk op de code legde), maar wel dat je het op andere punten kon terug vinden zoals bereidheid om in de interne werking van een library te duiken of contact te zoeken met de maker.

[MueR]

Styxxy schreef op dinsdag 16 september 2025 @ 12:56:
[...]

Vraag is dan of je dan wel afhankelijk wilt zijn van zo'n product, zeker voor productiedoeleinden .

Tja, open source heeft z'n nadelen.

[RobertMe]

MueR schreef op dinsdag 16 september 2025 @ 19:25:
[...]

Tja, open source heeft z'n nadelen.

Je hebt voordelen verkeerd geschreven

Lang geleden toen ik nog werkte bij bedrijven die DevExpress (meen ik dat het hete) gebruikte was de documentatie daarvan toch ook regelmatig kwalitatief uitermate teleurstellend, maar daarbij was er dan niet de mogelijkheid om in de code op te zoeken hoe het werkte.

[CodeCaster]

Ik wil echt zo mijn uiterste best doen om niet anti-AI te zijn. Ik ben bekend met de beperkingen van LLM's, ik weet hoe je moet prompten om tekst, plaatjes, samenvattingen, uitleg en berekeningen uit "AI" te krijgen, gebruik het al een paar jaar naar tevredenheid om snel antwoord te krijgen op simpele vragen.

Wat me nog steeds erg tegen de borst stuit, is dat het heel goed is in tekst genereren, en dat dat nog steeds ongeveer het enige (in sommige gevallen nuttige) doel lijkt. Ik zag van de week een collega die echt z'n best had gedaan op een mooi stuk library-code, maar dan moesten de public methods nog gedocumenteerd worden om de compiler wat minder warnings te laten uitpoepen. Hét uitgelezen moment, vind ik, om al je gedachten van tijdens het ontwerpen dan wel implementeren even te stroomlijnen en zelf in te tikken wat een klasse of functie nou eigenlijk doet.

Maar nee, de AI leest de code en typt de grootste lappen tekst uit die nooit meer iemand gaat lezen. Na drie woorden weet je al dat het gegenereerd is, en binnen nog drie woorden is je aandacht dusdanig verslapt dat je niet eens zin hebt om verder te lezen, omdat je toch al weet dat geen mens dit geschreven (noch nagelezen) heeft, laat staan dat iemand heeft gecontroleerd of het klopt.

"Yup, looks like text."

Maar dan: ik wilde zo graag eens een "coding agent" gebruiken. .NET-solution met een paar honderd testfiles, waarvan er een stuk of honderd nog Moq gebruikten. De boy scout rule bij het aanraken van zo'n file was Moq vervangen door NSubstitute (pun intented), maar dat zorgde voor te veel irrelevante changes en voor een te trage verwijdering van Moq.

Dus ik probeerde het met een naïeve prompt in GitHub Copilot Agent (Claude), iets van "vervang Moq in alle testprojecten door NSubstitute". Al heel snel liep de agent vast op triviale problemen. M'n best gedaan om een prompt van een paar paragrafen te schrijven, met "oud vs nieuw", zaken om op te letten, gewenste uitkomsten, enzovoorts.

Wat opviel: leuk, het redeneren van zo'n agent kunnen volgen, maar uiteindelijk besloot hij al z'n werk met regexes te doen. Ondanks expliciet aangeven, bevatten daardoor nog steeds verschillende projectbestanden tweemaal een package-reference naar NSubstitue, omdat hij simpelweg de referentie naar Moq had vervangen.

Nog erger: na elke paar bestanden deed hij een commit, en leek hij context en strategie te vergeten. Daardoor werd een werkende regex ineens een niet-werkende, of nog erger, twee opvolgende regexen omgewisseld.

Van:

C#:

private Mock<IFoo<IBar>> fooMock = new Mock<IFoo<IBar>>(MockBehavior.Strict);

Naar:

C#:

private IFoo<IBar fooMock = new Ifoo<IBar

Omdat er eerst gezocht werd naar Mock<, en dat vervangen werd door niets met sed, waarna de rest spaak liep.

Ook werd de hele tijd gezocht in de map "test" in de repo-root, wat klopt, maar opeens werd dat iets van "find -name /Test*" en vond Bash alleen nog één bestand dat überhaupt geen Mock gebruikte, en claimde de agent ineens klaar te zijn (met nog tientallen onaangeraakte bestanden, maar ja, hoofdlettergevoeligheid).

Ook relatief komisch was dat de agent blijkbaar slechts de beschikking had tot .NET 8, en onze solution allang .NET 9 gebruikt, waardoor het bouwen telkens niet lukte. Maar de agent was overtuigd van z'n eigen kunnen, en bleef steeds meer corrupte commits doen.

Uiteindelijk werd het echt niet grappig meer, zelfs met tig hints (je kunt in comments bijsturen met "@copilot consider <this, that>") werd niet-compilerende code verneukt naar nog minder compilerend.

Ik heb dus de bulk van de changes van Copilot overgenomen, daar de werkende regexes overheen gehaald (geplukt uit de agent logs) en vervolgens alsnog met het handje de rest moeten fixen, want zelfs de Claude in m'n IDE kon er geen chocola van maken (ook niet op de niet-aangepaste versies).

Ik zal nog steeds wat verkeerd doen, maar dit was geen fijne ervaring.

[DevWouter]

CodeCaster schreef op dinsdag 16 september 2025 @ 21:03:
Ik wil echt zo mijn uiterste best doen om niet anti-AI te zijn. Ik ben bekend met de beperkingen van LLM's, ik weet hoe je moet prompten om tekst, plaatjes, samenvattingen, uitleg en berekeningen uit "AI" te krijgen, gebruik het al een paar jaar naar tevredenheid om snel antwoord te krijgen op simpele vragen.

Wat me nog steeds erg tegen de borst stuit, is dat het heel goed is in tekst genereren, en dat dat nog steeds ongeveer het enige (in sommige gevallen nuttige) doel lijkt. Ik zag van de week een collega die echt z'n best had gedaan op een mooi stuk library-code, maar dan moesten de public methods nog gedocumenteerd worden om de compiler wat minder warnings te laten uitpoepen. Hét uitgelezen moment, vind ik, om al je gedachten van tijdens het ontwerpen dan wel implementeren even te stroomlijnen en zelf in te tikken wat een klasse of functie nou eigenlijk doet.

Maar nee, de AI leest de code en typt de grootste lappen tekst uit die nooit meer iemand gaat lezen. Na drie woorden weet je al dat het gegenereerd is, en binnen nog drie woorden is je aandacht dusdanig verslapt dat je niet eens zin hebt om verder te lezen, omdat je toch al weet dat geen mens dit geschreven (noch nagelezen) heeft, laat staan dat iemand heeft gecontroleerd of het klopt.

"Yup, looks like text."

Maar dan: ik wilde zo graag eens een "coding agent" gebruiken. .NET-solution met een paar honderd testfiles, waarvan er een stuk of honderd nog Moq gebruikten. De boy scout rule bij het aanraken van zo'n file was Moq vervangen door NSubstitute (pun intented), maar dat zorgde voor te veel irrelevante changes en voor een te trage verwijdering van Moq.

Dus ik probeerde het met een naïeve prompt in GitHub Copilot Agent (Claude), iets van "vervang Moq in alle testprojecten door NSubstitute". Al heel snel liep de agent vast op triviale problemen. M'n best gedaan om een prompt van een paar paragrafen te schrijven, met "oud vs nieuw", zaken om op te letten, gewenste uitkomsten, enzovoorts.

Wat opviel: leuk, het redeneren van zo'n agent kunnen volgen, maar uiteindelijk besloot hij al z'n werk met regexes te doen. Ondanks expliciet aangeven, bevatten daardoor nog steeds verschillende projectbestanden tweemaal een package-reference naar NSubstitue, omdat hij simpelweg de referentie naar Moq had vervangen.

Nog erger: na elke paar bestanden deed hij een commit, en leek hij context en strategie te vergeten. Daardoor werd een werkende regex ineens een niet-werkende, of nog erger, twee opvolgende regexen omgewisseld.

Van:

C#:

private Mock<IFoo<IBar>> fooMock = new Mock<IFoo<IBar>>(MockBehavior.Strict);

Naar:

C#:

private IFoo<IBar fooMock = new Ifoo<IBar

Omdat er eerst gezocht werd naar Mock<, en dat vervangen werd door niets met sed, waarna de rest spaak liep.

Ook werd de hele tijd gezocht in de map "test" in de repo-root, wat klopt, maar opeens werd dat iets van "find -name /Test*" en vond Bash alleen nog één bestand dat überhaupt geen Mock gebruikte, en claimde de agent ineens klaar te zijn (met nog tientallen onaangeraakte bestanden, maar ja, hoofdlettergevoeligheid).

Ook relatief komisch was dat de agent blijkbaar slechts de beschikking had tot .NET 8, en onze solution allang .NET 9 gebruikt, waardoor het bouwen telkens niet lukte. Maar de agent was overtuigd van z'n eigen kunnen, en bleef steeds meer corrupte commits doen.

Uiteindelijk werd het echt niet grappig meer, zelfs met tig hints (je kunt in comments bijsturen met "@copilot consider <this, that>") werd niet-compilerende code verneukt naar nog minder compilerend.

Ik heb dus de bulk van de changes van Copilot overgenomen, daar de werkende regexes overheen gehaald (geplukt uit de agent logs) en vervolgens alsnog met het handje de rest moeten fixen, want zelfs de Claude in m'n IDE kon er geen chocola van maken (ook niet op de niet-aangepaste versies).

Ik zal nog steeds wat verkeerd doen, maar dit was geen fijne ervaring.

Omdat elke AI bij grote stappen altijd een script schrijf om het werk te automatiseren. Wat wel werkt is dat je van te voren vraagt welke bestanden problematisch zijn, en vervolgens telkens zegt: "Doe deze file nu".

Omdat je dan om kleine stappen vraagt gaat het wel automatisch.

[Merethil]

Ik ben nu mezelf Rust aan het aanleren en dan merk je pas écht hoe sterk een LLM een taalmodel is. Dat woorden achter elkaar in een zin kloppen, de context enigszins klopt en de code enigszins Rust-like is betekent nog niet dat het gaat compileren.
Dingen als borrows en traits snapt een LLM van geen kanten en dus heb je elke keer 80% werkende code (oftewel 0% in het geval van Rust ) en mag je de overige 20% (waar je het vooral om ging eigenlijk) nog zelf uitvogelen. Ondertussen heb ik collega's die lyrisch zijn over het gebruik van LLMs en niets anders meer doen, maar steeds vaker zie ik ze dagen gebruiken voor dingen die uren mogen kosten. Ik ben benieuwd hoe het over 5 jaar is, en of we onszelf dan niet helemaal een hoekje in hebben gehallucineerd.

[Mugwump]

Voor dit soort grootschalige refactorings in bestaande code bases vind ik het ook allemaal niet denderend. Als ik de scope wat kleiner houd, dan zijn de resultaten vaak best aardig. Laatst b.v. in 1 repository de mongo library vervangen door een andere en dat ging vrij aardig. Zat nog een klein bugje in waardoor tests begonnen te falen, maar dat was een verschil in interne werking van de libraries (iets met datumtijd dingetjes) dat ik zelf in eerste instantie waarschijnlijk ook over het hoofd had gezien.

Ben ook wat aan het experimenteren met Jetbrains Junie, de agentic AI van JetBrains, en dat werkt ook niet onaardig. Met opdrachten als 'genereer op basis van de lokale changes een cucumber scenario dat de verschillende uitkomsten test' gaat ie op de achtergrond aan de slag, laat ie zien wat ie stapsgewijs doorloopt en komt er best een aardig resultaat uit wat toch weer het nodige werk scheelt.

[mrc4nl]

ik heb meer koffie nodig, zit al twee uur te debuggen waarom mijn als ik een losse bestandsnaam opgeef mn programma wel netjes gps coordinaten uit een foto kan halen maar crashed zodra ik de bestandsnamen als variable meegeef.

De andere bestanden hadden geen gps data,
heerlijk als je aanneemt dat alle bestanden die data hebben

[ThomasG]

mrc4nl schreef op donderdag 18 september 2025 @ 08:52:
ik heb meer koffie nodig, zit al twee uur te debuggen waarom mijn als ik een losse bestandsnaam opgeef mn programma wel netjes gps coordinaten uit een foto kan halen maar crashed zodra ik de bestandsnamen als variable meegeef.

De andere bestanden hadden geen gps data,
heerlijk als je aanneemt dat alle bestanden die data hebben

Daarom dus altijd eerst zelf controleren

Laatst had een collega geen internet op z'n vaste werk PC. Zat 'ie alle instellingen na te lopen. Wachtwoord misschien verlopen, etc. etc. Wat bleek nou: de UTP kabel bungelde over de vloer langs de muur, en was daardoor tijdens de schoonmaak (dweil die bleef hangen o.i.d.) per ongeluk uit de muursocket getrokken. Zat er nog wel in, maar geen contact

[mrc4nl]

ThomasG schreef op donderdag 18 september 2025 @ 09:09:
[...]
Daarom dus altijd eerst zelf controleren

Laatst had een collega geen internet op z'n vaste werk PC. Zat 'ie alle instellingen na te lopen. Wachtwoord misschien verlopen, etc. etc. Wat bleek nou: de UTP kabel bungelde over de vloer langs de muur, en was daardoor tijdens de schoonmaak (dweil die bleef hangen o.i.d.) per ongeluk uit de muursocket getrokken. Zat er nog wel in, maar geen contact

o das wel sneaky inderdaad. windows kan om de vreemdste redenen geen geen/slechte verbinding hebben, daar zou ik het eerder hebben gezocht ipv de kabel.

[ Voor 3% gewijzigd door mrc4nl op 18-09-2025 10:17 ]

[Janoz]

@CodeCaster zoiets zou ik ook helemaal niet met AI willen doen tbh. Zeker als hij blijkbaar sed scriptjes genereerd. Nu zit ik meer aan de andere kant (jvm-land ipv .net-land), maar aan deze kant word vaak OpenRewrite gebruikt. Misschien zou je AI een openRewrite recipe kunnen laten genereren?

[Janoz]

Merethil schreef op woensdag 17 september 2025 @ 09:54:
Ik ben nu mezelf Rust aan het aanleren en dan merk je pas écht hoe sterk een LLM een taalmodel is. Dat woorden achter elkaar in een zin kloppen, de context enigszins klopt en de code enigszins Rust-like is betekent nog niet dat het gaat compileren.
Dingen als borrows en traits snapt een LLM van geen kanten en dus heb je elke keer 80% werkende code (oftewel 0% in het geval van Rust ) en mag je de overige 20% (waar je het vooral om ging eigenlijk) nog zelf uitvogelen. Ondertussen heb ik collega's die lyrisch zijn over het gebruik van LLMs en niets anders meer doen, maar steeds vaker zie ik ze dagen gebruiken voor dingen die uren mogen kosten. Ik ben benieuwd hoe het over 5 jaar is, en of we onszelf dan niet helemaal een hoekje in hebben gehallucineerd.

Zet je wel aan het denken hoe 'correct' de gegenereerde code is in het geval je in een meer vergevingsgezinde taal werkt

[Merethil]

Janoz schreef op vrijdag 19 september 2025 @ 08:51:
[...]


Zet je wel aan het denken hoe 'correct' de gegenereerde code is in het geval je in een meer vergevingsgezinde taal werkt

Klopt, ik werk professioneel vooral met Python en daar maakt een Copilot, ChatGPT of Claude vaak "werkende" code. Veelal wordt er dan zwaar misbruik gemaakt van het feit dat typing niet strict is en dat je allemaal private functions "van buitenaf" mag misbruiken; zo wordt er doodleuk overal __dict__ en __attr__ e.d. aangeroepen.

Specifiek voor Claude via Cline in VSCode heb ik een .clinerules gemaakt die uitlegt hoe onze code in elkaar zit, waar de libraries staan die gebruikt moeten worden en wat onze coding guidelines zijn, en dan werkt het meestal wel oké. Er komt nog steeds allemaal troep uit met gehallucineerde functies uit zowel mijn eigen libraries als AWS' boto3, maar daar valt mee te werken.

De enige manier waarop ik écht veel lol van AI heb is Copilot gebruiken om dingen aan te vullen in m'n boilerplate (tab drukken en een heel stuk boilerplate krijgen die je anders had moeten uittypen is gewoon fijn), of wanneer 'ie function docs met uitleg van parameters toevoegt / simpele tests voorstelt. Dat is ook het enige moment dat ik iets van efficiëntie-verhoging opmerk.

[ThomasG]

Merethil schreef op vrijdag 19 september 2025 @ 09:46:
[...]

Klopt, ik werk professioneel vooral met Python en daar maakt een Copilot, ChatGPT of Claude vaak "werkende" code. Veelal wordt er dan zwaar misbruik gemaakt van het feit dat typing niet strict is en dat je allemaal private functions "van buitenaf" mag misbruiken; zo wordt er doodleuk overal __dict__ en __attr__ e.d. aangeroepen.

Specifiek voor Claude via Cline in VSCode heb ik een .clinerules gemaakt die uitlegt hoe onze code in elkaar zit, waar de libraries staan die gebruikt moeten worden en wat onze coding guidelines zijn, en dan werkt het meestal wel oké. Er komt nog steeds allemaal troep uit met gehallucineerde functies uit zowel mijn eigen libraries als AWS' boto3, maar daar valt mee te werken.

De enige manier waarop ik écht veel lol van AI heb is Copilot gebruiken om dingen aan te vullen in m'n boilerplate (tab drukken en een heel stuk boilerplate krijgen die je anders had moeten uittypen is gewoon fijn), of wanneer 'ie function docs met uitleg van parameters toevoegt / simpele tests voorstelt. Dat is ook het enige moment dat ik iets van efficiëntie-verhoging opmerk.

Je kunt copilot sturen door zelf door te typen, dan neemt het daarna jou wijze over. Ook je programmeer en commentaar stijl wordt dan overgenomen. Als je in Python de type hints gebruikt neem het dat ook gewoon over. Het is met een autocomplete op steroïde dan dat je het zijn eigen gang moet laten gaan. Als je het O gebruikt is het heel handig.

[Spooksel]

Ok, misschien dat ik gek ben... if so, do tell me.

Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Dit omdat volgens hem de statuscodes gaan over communicatie tussen de client en server en dus is 200 de enige reactie die aangeeft dat de communicatie ok was! Dus als de API een verzoek niet kan afhandelen, bijvoorbeeld om dat de validatie van de inhoud mislukt, dan moet je HTTP 200 OK terug geven met bijvoorbeeld als body:

code:

{
    "status":"error",
    "message":"Hier de reden van het mislukken van de request"
}

Terwijl ik dan bijvoorbeeld denk, dan moet je een HTTP 400 Bad Request terug geven met als inhoud:

code:

{
    "message":"Hier de reden van het mislukken van de request"
}

Ben ik nou zo gek om te denken dat je die HTTP status codes wel degelijk moet kunnen gebruiken om iets inhoudelijks te zeggen over de afwikkeling van een request?

[Kalentum]

Spooksel schreef op vrijdag 19 september 2025 @ 12:20:
Ok, misschien dat ik gek ben... if so, do tell me.

Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Dit omdat volgens hem de statuscodes gaan over communicatie tussen de client en server en dus is 200 de enige reactie die aangeeft dat de communicatie ok was! Dus als de API een verzoek niet kan afhandelen, bijvoorbeeld om dat de validatie van de inhoud mislukt, dan moet je HTTP 200 OK terug geven met bijvoorbeeld als body:

code:

{
    "status":"error",
    "message":"Hier de reden van het mislukken van de request"
}

Terwijl ik dan bijvoorbeeld denk, dan moet je een HTTP 400 Bad Request terug geven met als inhoud:

code:

{
    "message":"Hier de reden van het mislukken van de request"
}

Ben ik nou zo gek om te denken dat je die HTTP status codes wel degelijk moet kunnen gebruiken om iets inhoudelijks te zeggen over de afwikkeling van een request?

Nee hoor je bent niet gek. Genoeg REST API's die 404 Not founds doen, PUT/PATCH correct implementeren, location headers gebruiken etc

Maar je ziet wel veel verschillende implementaties.

[ Voor 3% gewijzigd door Kalentum op 19-09-2025 12:49 ]

[sky-]

Zo lang het gedrag van de API (goed) gedocumenteerd is, is er wat mij betreft niets aan de hand.

[mbe81]

Spooksel schreef op vrijdag 19 september 2025 @ 12:20:
Ok, misschien dat ik gek ben... if so, do tell me.

Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Dit omdat volgens hem de statuscodes gaan over communicatie tussen de client en server en dus is 200 de enige reactie die aangeeft dat de communicatie ok was! Dus als de API een verzoek niet kan afhandelen, bijvoorbeeld om dat de validatie van de inhoud mislukt, dan moet je HTTP 200 OK terug geven met bijvoorbeeld als body:

code:

{
    "status":"error",
    "message":"Hier de reden van het mislukken van de request"
}

Terwijl ik dan bijvoorbeeld denk, dan moet je een HTTP 400 Bad Request terug geven met als inhoud:

code:

{
    "message":"Hier de reden van het mislukken van de request"
}

Ben ik nou zo gek om te denken dat je die HTTP status codes wel degelijk moet kunnen gebruiken om iets inhoudelijks te zeggen over de afwikkeling van een request?

Die developer komt vast nog uit het SOAP tijdperk? Daar is dit volgens mijn gemeengoed (Ook omdat SOAP niet altijd over http gaat en http echt gezien werd als transportprotocol). Een REST-api gaat altijd via http en is daardoor meer verweven. Daarom is daar wel de best practice om de statuscodes van de http response onderdeel te laten zijn van het resultaat.
Je definieert zelfs expliciet in een OpenAPI specificatie de response per statuscode.

[daily.data.inj]

Spooksel schreef op vrijdag 19 september 2025 @ 12:20:
Ok, misschien dat ik gek ben... if so, do tell me.

Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Dit omdat volgens hem de statuscodes gaan over communicatie tussen de client en server en dus is 200 de enige reactie die aangeeft dat de communicatie ok was! Dus als de API een verzoek niet kan afhandelen, bijvoorbeeld om dat de validatie van de inhoud mislukt, dan moet je HTTP 200 OK terug geven met bijvoorbeeld als body:

code:

{
    "status":"error",
    "message":"Hier de reden van het mislukken van de request"
}

Terwijl ik dan bijvoorbeeld denk, dan moet je een HTTP 400 Bad Request terug geven met als inhoud:

code:

{
    "message":"Hier de reden van het mislukken van de request"
}

Ben ik nou zo gek om te denken dat je die HTTP status codes wel degelijk moet kunnen gebruiken om iets inhoudelijks te zeggen over de afwikkeling van een request?

Altijd leuk dat soort gesprekken, soms oprecht omdat het een mogelijkheid is om de onderwerpen en de achterliggende rationales nog beter kan doorgronden en soms... van ohh here we go again .

Ik merk dat ik de laatste tijd vooral zoveel mogelijk informatie van 'authorative sources' probeer te raadplegen en te gebruiken. Ze zijn immers authorative voor een reden en verwoorden het vaak stukken beter dan dat ik zelf kan.
In dit geval zou ik wat RFC# delen die beschrijven hoe de HTTP status codes zijn bedoeld en waarom, bijv. RFC2616: https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1.

Zie trouwens dat Wikipedia ook een mooi overzicht heeft inclusief de bijgewerkte RFC's Wikipedia: List of HTTP status codes

[thof]

Als we dan toch met RFC's bezig zijn, dan is RFC9457 'Problem Details for HTTP APIs' ook wel handig om door te nemen. Die gaat ook over hoe foutafhandeling te doen, mede omdat een HTTP status code meestal niet genoeg informatie geeft. Dit zit overigens (gedeeltelijk) ook ingebakken in ASP.NET, voor de .NET collega's hier. Anyway iets meer standaardisatie rondom foutberichten kan de afhandeling ervan best helpen.

Voorbeeld responses uit de RFC:

code:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
 "type": "https://example.com/probs/out-of-credit",
 "title": "You do not have enough credit.",
 "detail": "Your current balance is 30, but that costs 50.",
 "instance": "/account/12345/msgs/abc",
 "balance": 30,
 "accounts": ["/account/12345",
              "/account/67890"]
}

code:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Language: en

{
 "type": "https://example.net/validation-error",
 "title": "Your request is not valid.",
 "errors": [
             {
               "detail": "must be a positive integer",
               "pointer": "#/age"
             },
             {
               "detail": "must be 'green', 'red' or 'blue'",
               "pointer": "#/profile/color"
             }
          ]
}

[Spooksel]

sky- schreef op vrijdag 19 september 2025 @ 12:48:
Zo lang het gedrag van de API (goed) gedocumenteerd is, is er wat mij betreft niets aan de hand.

Dit ben ik ook met je eens hoor, maar het probleem is hier dat ik degene ben die een API gemaakt heeft en daarin geef ik bijvoorbeeld HTTP 422 Unprocessable Content terug indien een request in principe helemaal valide is, maar toch niet verwerkt kan worden door de server. Ik heb die API zo ontworpen, maar nu roept de andere deverloper dat hij dus mijn reacties niet kan uitlezen omdat ie alleen maar HTTP 200 Ok verwacht , want...

quote: Andere developer

HTTP is een communicatieprotocol. Dus de foutcodes gaan over de communicatie, niet over de inhoud. Dus als een parameter ontbreekt dan verloopt de communicatie niet goed. Of als je geen toegang hebt (403) heb je geen communicatie.

Een casus waarin dit kan gebeuren is bijvoorbeeld als een cursist zich wil inschrijven op een cursus die in de administratie op status 'GAAT NIET DOOR' gezet is en de website hier nog niet van op de hoogte is (ik zou zo graag willen dat die mensen webhooks leren gebruiken), omdat de update job van de websites nog niet gelopen heeft.

De client maakt in dit geval dus een volledig geldig geformuleerd verzoek voor het plaatsen van een inschrijving in de administratie, maar doordat de status van de gewenste cursus het niet toelaat krijg je dus dat het resultaat is dat je geen inschrijving hebt.

In mijn API is het dus zo dat als er een parameter ontbreekt (zie voorbeeld van de andere developer hierboven), dan krijg je een HTTP 400 Bad Request terug en staat er in de body een JSON string met uitleg waarom je deze reactie krijgt, namelijk dat er een parameter ontbreekt. Dit is gewoon goeie communicatie, hij wil er alleen niet aan om het uit te lezen.

Als je je API zo opgebouwd en gedocumenteerd hebt dat je alles via HTTP 200 Ok beantwoord, prima. Maar ik heb dat dus niet, ik geef diverse HTTP statussen terug om aan te geven wanneer iets goed of niet goed gaat en dat heb ik ook zo gedocumenteerd.

[ Voor 9% gewijzigd door Spooksel op 19-09-2025 15:57 ]

[wackmaniac]

omdat ie alleen maar HTTP 200 Ok verwacht

Lijkt me een uitstekend moment om dat dan te verbeteren

[Voutloos]

De server is er al, de werking is bij deze duidelijk.
Als je 3x om je eigen voorkeur bij mij als dienstverlener zeurt, heb ik totaal geen moeite om het antwoord te sturen inc je manager in CC dat enige vertraging van implementatie een client keuze is; de dienst werkt al voor vele anderen.

[Jolijter]

Oef, alleen HTTP 200 erkennen gaat wel heel ver. Zoals de andere developer aangeeft is het de status omtrend de communicatie. Wanneer het om een REST API gaat is een HTTP 404 een prima reactie op een resource die gewoon niet bestaat. Als je een GET op /order/123 doet en die bestaat niet, is HTTP 404 een prima response. Dat je daarmee niet het verschil ziet tussen /0rder/123 die ook een HTTP 404 kan geven omdat je een typo hebt gemaakt maakt het wat verwarrend, in beide gevallen ligt het aan de client die een niet bestaande resource opvraagt. Nog leuker zou zijn als je een HTTP 410 geeft op een resource die wel bestaan heeft om dat verschil ook nog duidelijker te maken.

Ik kan me herinneren dat ik weleens een HTTP 400 heb teruggegeven wanneer een resource waar naar wordt verwezen in een POST request niet bestaat. Als je kijkt naar de RFC voor HTTP 400 klinkt dat niet als de juiste status want dat zou alleen om de syntax van het request moeten gaan, niet om de inhoud ervan. Een request dat een HTTP 400 heeft zou zonder wijzigingen in het request niet tot wat anders dan een HTTP 400 moeten leiden. Welke HTTP status het dan wel zou moeten zijn is me nog niet helemaal duidelijk. Volgens ChatGPT zou het een HTTP 422 kunnen zijn.

[RobertMe]

Het wordt pas leuk als je bewust verkeerde status codes gaat geven. Gewoon altijd esn 404, ook bij toegang geweigerd. Want maak je onderscheid tussen 404 voor bv een order die niet bestaat en 403 voor een order waar de ingelogde gebruiker geen toegang toe heeft "lek" je informatie. Daarom wordt er vaak gekozen voor altijd een 404. Maakt uiteraard bij nummers minder uit dan bij namen. Maar bv GitHub doet dat ook met organisatie en repository namen.

[Marc3l]

Alleen een 200 teruggeven... wat heeft die status dan nog voor zin? 😛 Kan je net zo goed alleen de json message teruggeven.

Maar juist die statussen zijn handig, je weet dan meteen wat er mis is. Nu moet je dat uit de message halen? Bij (automatisch) testen kan je ook testen met het statusnummer, anders moet je bijvoorbeeld een 403 checken aan de hand van message. En mocht dat bericht worden aangepast, dan werkt je test niet meer. Een 403 blijft een 403. Dus zelf geen voorstander om altijd een 200 terug te geven.

[whoami]

Kalentum schreef op vrijdag 19 september 2025 @ 12:46:
[...]


Nee hoor je bent niet gek. Genoeg REST API's die 404 Not founds doen, PUT/PATCH correct implementeren, location headers gebruiken etc

Maar je ziet wel veel verschillende implementaties.

Ook ooit eens tegen een API moeten praten die altijd maar HTTP 200 teruggaf, ook als er iets fout liep. Dat is eigenlijk een hel om tegen te praten. Je moet altijd de response gaan parsen om te weten of je die request kan retryen of niet. Als de juiste statuscodes teruggegeven worden, dan maak je dat alvast al heel wat duidelijker:
- 400 -> het heeft geen zin om te retryen
- 500 -> retry
-> 408 -> retry
-> etc..

[SPee]

Spooksel schreef op vrijdag 19 september 2025 @ 12:20:
Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Dit omdat volgens hem de statuscodes gaan over communicatie tussen de client en server en dus is 200 de enige reactie die aangeeft dat de communicatie ok was! Dus als de API een verzoek niet kan afhandelen, bijvoorbeeld om dat de validatie van de inhoud mislukt, dan moet je HTTP 200 OK terug geven

Dat je een reactie terugkrijgt, geeft al aan dat de communicatie ok is!

Een HTTP code geeft een status van een client request aan. En die kan succesvol zijn (200), een fout opleveren (400) of een echte serverfout geven (500).
Want wat denkt hij over een HTTP 404 in de browser? De communicatie met de server was toch immers ok? Daar krijg je toch ook niet een HTTP 200 met tekst "helaas pindakaas" terug als je een niet-bestaand plaatje opvraagt?
Dus nee, dat nummertje gaat niet over de communicatie.

[SPee]

Mugwump schreef op dinsdag 16 september 2025 @ 13:19:
[...]
Hoorde ik daar iemand Confluence roepen?

Ho, wacht! Nog even geduld! Ik ben nog niet klaar met mijn rust rewrite.
Hopelijk ben ik op tijd klaar als ze stoppen met hun datacenter versie. Dus nog even geduld (3 jaar ofzo).
En dan is er eindelijk weer een betere versie van Confluence/Wordpress/CMS/Wiki/Forum om te proberen.

Ik zit nog te denken aan hoe ik het het beste kan demo-en. Ik zat te denken aan een Tweakers lookalike. Maar misschien is The Next Web een betere optie. Even kijken of die domeinnaam beschikbaar is.

[MueR]

Spooksel schreef op vrijdag 19 september 2025 @ 12:20:
Ok, misschien dat ik gek ben... if so, do tell me.

Maar ik heb dus vanmorgen een discussie gehad met een developer die van mening is dat REST API's altijd alleen maar HTTP code 200 OK terug mogen geven!

Ik zou permanent een HTTP 418 teruggeven op zijn API key. Sorry, maar als je vindt dat een API alleen maar een 200 mag teruggeven snap je http niet. Een 404 op een website geeft toch ook een succesvolle communicatie terug? "Ik zoek X. Sorry, ik heb X niet, maar hier heb je een mooie pagina die je dat vertelt".

[DevWouter]

Eigenlijk hoef je er maar twee te weten
400 = Er gaat iets fout aan jouw kant.
500 = Er gaat iets fout aan mijn kant

Alle andere subcodes vereisen dat je weet hoe de applicatie daar op zal moeten reageren, zoals caching, metadata, content negation, of het wel/niet opnieuw moet proberen.

Verder is er geen verbod om je eigen statuscode te gebruiken zolang het maar in de range van 100 t/m 599 zit. Sterker nog de RFC geeft aan dat je ook de range van 600 t/m 999 mag gebruiken voor interne doeleinden.

[Marc3l]

Ik hanteer altijd wel de standaard codes, https://developer.mozilla...Web/HTTP/Reference/Status
Die zijn er niet voor niets.

[farlane]

Behalve dan dat HTTP een draak van een protocol is en wellicht niet altijd helemaal lekker matched met wat mensen er nu mee doen. Wat op zijn beurt niet allemaal voorzien was door de bedenker in 1989 kan ik me zo voorstellen.

[ Voor 7% gewijzigd door farlane op 20-09-2025 16:52 ]

[Spooksel]

Wat voor code zouden jullie terug geven in mijn voorbeeld?

Een casus waarin dit kan gebeuren is bijvoorbeeld als een cursist zich wil inschrijven op een cursus die in de administratie op status 'GAAT NIET DOOR' gezet is en de website hier nog niet van op de hoogte is, bijvoorbeeld omdat de update job van de websites nog niet gelopen heeft.

De client maakt in dit geval dus een volledig geldig geformuleerd verzoek voor het plaatsen van een inschrijving op een cursus, maar doordat de status van de gewenste cursus het inmiddels niet meer toelaat krijg je dus dat het resultaat is dat je geen inschrijving hebt.

Technisch gezien stuurt de client hier een volledig correct samengestelde request, maar kan de server het niet uitvoeren omdat er tussentijds iets verandert is aan de kant van de server.

Ik neig zelf naar een 422 (Unprocessable Content), maar feitelijk is het natuurlijk geen client error. Then again, geen enkele van de server errors is ook echt een match.

[Haan]

@Spooksel Ik probeer response codes beperkt te houden tot 200, 400, 404 (indien van toepassing) en 500. Dat houdt het voor clients een beetje overzichtelijk. Daarom zou ik in dit geval 500 als response geven aangezien er iets mis is gegaan op de server.

[Cartman!]

Je kunt je afvragen hoeveel het nu echt uitmaakt, kies een code en de frontend moet die error afvangen en een leesbare melding tonen aan de gebruiker. Of die nu uit een 4xx of 5xx komt is voor de gebruiker niet zichtbaar.

[Crazy D]

Ik zou zeggen, gebruik een paar statuscodes en stuur lekker errorcodes en omschrijvingen mee. Doet Microsoft ook met bv de Graph API, dus dan vind ik dat een prima oplossing. 401, 409, 418. Whatever. Er klopte iets niet. Als dat iets te maken heeft met wat de user invoerde, kun je wellicht nog de moeite nemen om per property netjes een errorcodering mee te geven zodat de UI daar nog iets mee kan. Is het technisch, geef je dat een duidelijke code en desnoods een trace ID of zo.

Maar een 200 teruggeven met in de body de foutmelding is dan wel een beetje het andere uiterste

[Merethil]

Spooksel schreef op maandag 22 september 2025 @ 08:38:
Wat voor code zouden jullie terug geven in mijn voorbeeld?


[...]


Technisch gezien stuurt de client hier een volledig correct samengestelde request, maar kan de server het niet uitvoeren omdat er tussentijds iets verandert is aan de kant van de server.

Ik neig zelf naar een 422 (Unprocessable Content), maar feitelijk is het natuurlijk geen client error. Then again, geen enkele van de server errors is ook echt een match.

Ik gebruik voor dit soort zaken een 400 Bad Request met in de response body een menselijk leesbare error massage en een aparte error code uit een enum die ik opneem in m'n OpenAPI docs. Daarmee kan de frontend bepalen wat er moet gebeuren op basis van de 400 + error code terwijl in je logging (frontend én backend) ook een leesbare foutmelding staat.

Ik ben altijd wat voorzichtig met alles boven de ~406 want veel van die codes zijn bedacht voor één of twee situaties. Een 422 is unprocessable vanwege de instructies die de server niet "snapt" volgens de beschrijving. Ik zou nog eerder naar 409 Conflict neigen omdat de status niet meer is zoals verwacht.

[Mugwump]

Cartman! schreef op maandag 22 september 2025 @ 08:51:
Je kunt je afvragen hoeveel het nu echt uitmaakt, kies een code en de frontend moet die error afvangen en een leesbare melding tonen aan de gebruiker. Of die nu uit een 4xx of 5xx komt is voor de gebruiker niet zichtbaar.

Veel applicaties hebben niet enkel een front- en back-end, maar ook APIs die een breder publiek bedienen. Het onderscheid tussen 4xx en 5xx (wat zoals @DevWouter al aangeeft in hoofdlijnen een 'jouw' probleem vs 'mijn probleem' onderscheid is) is vaak ook zeker nuttig voor alerting en monitoring. Een 5xx betekent vaak dat er iets mis is met je dienstverlening omdat er bugs zijn geïntroduceerd of systemen waar je applicatie van afhankelijk is onbeschikbaar zijn, terwijl een bak aan 400 errors vaak ook kan betekenen dat een grotere afnemer domweg een fout heeft omdat ze stug een verkeerde request blijven insturen. Voor het eerste moet je bij 'mission critical' systemen doorgaans je bed uit 's nachts, het tweede kan ter kennisgeving genotificeerd worden om proactief te gaan buurten bij de betreffende afnemer bijvoorbeeld.

Ik heb verder ook weinig met mensen die 3 uur lang willen discussiëren welke obscure 4xx of 5xx code ze in bepaalde gevallen willen gebruiken, maar aan de andere kant is een 200 respons met daarin een foutcode wel echt mijn grootste irritatie bij REST implementaties.

[Kalentum]

Spooksel schreef op maandag 22 september 2025 @ 08:38:
Wat voor code zouden jullie terug geven in mijn voorbeeld?


[...]


Technisch gezien stuurt de client hier een volledig correct samengestelde request, maar kan de server het niet uitvoeren omdat er tussentijds iets verandert is aan de kant van de server.

Ik neig zelf naar een 422 (Unprocessable Content), maar feitelijk is het natuurlijk geen client error. Then again, geen enkele van de server errors is ook echt een match.

409 Conflict

De client heeft een andere state van het object dan de situatie op de server. Bij 409 conflict zou de client dus het object opnieuw kunnen opvragen, dan zien dat de status van de cursus 'geannuleerd' is en de 'fout' correct afhandelen.

Ik lees hier trouwens veel 'frontend'. Maar er zijn ook publieke REST API's en als je aan zo'n API werkt zijn die status codes wel wat relevanter: je wilt dat de code die gebruikt maakt van je API zoveel mogeljik de juiste beslissing kan nemen.

[ThomasG]

Mijn grootste ergernis aan REST API's is dat veel APIs nietszeggende foutmeldingen geven. Dan wil ik bijvoorbeeld een post request down, en krijg ik een 400 Bad Request terug met een json waar dan enkel in staat dat het fout gegaan is. Ben ik een veld vergeten? Is mijn invoer niet goed? Doe ik iets fout of ligt het aan de API? etc. etc. Als het een user error is, geef mij dan ook een foutmelding waar ik iets aan heb.

[whoami]

Spooksel schreef op maandag 22 september 2025 @ 08:38:
Wat voor code zouden jullie terug geven in mijn voorbeeld?


[...]


Technisch gezien stuurt de client hier een volledig correct samengestelde request, maar kan de server het niet uitvoeren omdat er tussentijds iets verandert is aan de kant van de server.

Ik neig zelf naar een 422 (Unprocessable Content), maar feitelijk is het natuurlijk geen client error. Then again, geen enkele van de server errors is ook echt een match.

409 Conflict zou ik hier gebruiken.

[whoami]

Haan schreef op maandag 22 september 2025 @ 08:48:
@Spooksel Ik probeer response codes beperkt te houden tot 200, 400, 404 (indien van toepassing) en 500. Dat houdt het voor clients een beetje overzichtelijk. Daarom zou ik in dit geval 500 als response geven aangezien er iets mis is gegaan op de server.

Een HTTP 500 impliceert een retryable error. Dat wil zeggen dat de caller eigenlijk diezelfde request nog eens kan proberen in de hoop dat het dan wel goed gaat, maar dat is in dit geval niet aan de orde.

[Voutloos]

400, en in de body ‘selected course id is not an open course’.

Klaar, niet zo moeilijk doen mensen. 409 kent men niet en je maakt allemaal aannames over cachelagen e.d. Zolang de response body maar uitlegt welk veld, waarom fout is, is de rest allemaal geneuzel.

[MueR]

Wij gebruiken veel 406 Not Acceptable als validatie niet slaagt, met uiteraard een json response body die een foutmelding teruggeeft. Dat is dan wel een slug (want frontend moet het kunnen vertalen), maar die is best human readable, voor een programmeur zeker.

[ThomasG]

MueR schreef op maandag 22 september 2025 @ 16:05:
Wij gebruiken veel 406 Not Acceptable als validatie niet slaagt, met uiteraard een json response body die een foutmelding teruggeeft. Dat is dan wel een slug (want frontend moet het kunnen vertalen), maar die is best human readable, voor een programmeur zeker.

Strict genomen is dat fout. HTTP 406 Not Acceptable is bedoeld als foutmelding voor de content-negotiation headers (Accept, Accept-Encoding, etc.). Stel de client stuurt een Accept: foo/bar header, dan mag de server een 406 sturen dat het geen foo/bar ondersteund. Het is dus niet bedoeld voor input validation. Daarvoor is o.a. 422.

[Mugwump]

Dit zijn precies het soort semantische neuzeldiscussies voor puristen die ik zinloos vind voor wat betreft ontwerp van APIs. Veel belangrijker is het dat voor gebruikers helder is wat ze kunnen verwachten. Oftewel duidelijk docs die aangeven welke foutcodes je in welke gevallen kunt verwachten van een API en wat de structuur van de responsebody is.

RFCs lijken zo af en toe op de religieuze geschriften van ITers waarbij ze allemaal hun uiterste best doen om te bedenken wat de schrijvers nou eigenlijk bedoeld hadden en er bijna heilige oorlogen worden uitgevochten voor het eigen gelijk.

[Kalentum]

Mugwump schreef op maandag 22 september 2025 @ 18:16:
Dit zijn precies het soort semantische neuzeldiscussies voor puristen die ik zinloos vind voor wat betreft ontwerp van APIs. Veel belangrijker is het dat voor gebruikers helder is wat ze kunnen verwachten. Oftewel duidelijk docs die aangeven welke foutcodes je in welke gevallen kunt verwachten van een API en wat de structuur van de responsebody is.

RFCs lijken zo af en toe op de religieuze geschriften van ITers waarbij ze allemaal hun uiterste best doen om te bedenken wat de schrijvers nou eigenlijk bedoeld hadden en er bijna heilige oorlogen worden uitgevochten voor het eigen gelijk.

Totdat je een REST client gebruikt die wat zinnigs doet met die status codes en dan ben je blij dat de API developer iets van een standaard volgt.

Oeverloos geneuzel is niet goed, dus kies dan wat anders dan REST.

[ Voor 3% gewijzigd door Kalentum op 22-09-2025 18:55 ]

[Mugwump]

Kalentum schreef op maandag 22 september 2025 @ 18:51:
[...]


Totdat je een REST client gebruikt die wat zinnigs doet met die status codes en dan ben je blij dat de API developer iets van een standaard volgt.

Oeverloos geneuzel is niet goed, dus kies dan wat anders dan REST.

Dan mis je het punt. Ik zeg niet dat je alles overboord moet gooien en plots een 404 moet gaan gooien als de syntax van je JSON niet klopt of iets dergelijks.

Het gaat om het semantische nitpicking met name waar het aankomt op alle obscure WebDAV codes.
Of je nou een 400, 406, 409 of 422 gooit bij een bepaalde semantische fout in hetgeen wordt meegestuurd in de request al dan niet in combinatie met de state aan de serverkant maakt echt niet uit als het maar consistent is en duidelijk gedocumenteerd.

Als dit soort zaken echt ondubbelzinnig duidelijk zouden zijn dan had je wat aan een standaard, maar het hele punt is dat in veel van dit soort gevallen de standaard er niet is. Dat zie je al bijvoorbeeld aan het feit dat we niet eens in de buurt komen bij industriestandaarden op dat vlak.

Je hebt er bovendien enkel wat aan als het je bijvoorbeeld in staat stelt om geautomatiseerd te handelen op basis van deze informatie zoals bijvoorbeeld een refresh van een token op een 403, een upgrade van je account bij regelmatig 429s of wanneer de code je direct laat weten waar het probleem zit, maar in het gros van dit soort gevallen als bijvoorbeeld validatie is duidelijke feedback over wat er niet klopt noodzakelijk.

[ThomasG]

Mugwump schreef op maandag 22 september 2025 @ 19:50:
[...]


Dan mis je het punt. Ik zeg niet dat je alles overboord moet gooien en plots een 404 moet gaan gooien als de syntax van je JSON niet klopt of iets dergelijks.

Het gaat om het semantische nitpicking met name waar het aankomt op alle obscure WebDAV codes.
Of je nou een 400, 406, 409 of 422 gooit bij een bepaalde semantische fout in hetgeen wordt meegestuurd in de request al dan niet in combinatie met de state aan de serverkant maakt echt niet uit als het maar consistent is en duidelijk gedocumenteerd.

Als dit soort zaken echt ondubbelzinnig duidelijk zouden zijn dan had je wat aan een standaard, maar het hele punt is dat in veel van dit soort gevallen de standaard er niet is. Dat zie je al bijvoorbeeld aan het feit dat we niet eens in de buurt komen bij industriestandaarden op dat vlak.

Je hebt er bovendien enkel wat aan als het je bijvoorbeeld in staat stelt om geautomatiseerd te handelen op basis van deze informatie zoals bijvoorbeeld een refresh van een token op een 403, een upgrade van je account bij regelmatig 429s of wanneer de code je direct laat weten waar het probleem zit, maar in het gros van dit soort gevallen als bijvoorbeeld validatie is duidelijke feedback over wat er niet klopt noodzakelijk.

Alle HTTP status zijn duidelijk beschreven, bij vele staat het zelfs in de naam. Gebruik ze dan dus ook op de manier waar ze voor bedoeld zijn. Dus niet status X gebruiken A, terwijl in het duidelijk bedoeld is voor B. Helemaal als er een andere status code is die precies A doet.

[Mugwump]

ThomasG schreef op maandag 22 september 2025 @ 20:04:
[...]
Alle HTTP status zijn duidelijk beschreven, bij vele staat het zelfs in de naam. Gebruik ze dan dus ook op de manier waar ze voor bedoeld zijn. Dus niet status X gebruiken A, terwijl in het duidelijk bedoeld is voor B. Helemaal als er een andere status code is die precies A doet.

Lees je wel waar je op reageert? In sommige gevallen zijn de codes duidelijk en ondubbelzinnig geformuleerd. Maar in veel andere gevallen is dat helemaal niet het geval. Ik bedoel als Google en Github al niet consistent zijn om maar wat te noemen, dan kun je ook moeilijk beweren dat het allemaal zo overduidelijk is dat het onmogelijk is dat we geen volstrekt universele REST API specs hebben.

[Soultaker]

Heerlijk fietsenstallingonderwerp.

Ik ben het wel met @Voutloos en @Mugwump eens. Tenzij je een REST API ontwerpt die heel precies aansluit op het resource-model van HTTP, kun je het beter niet te ingewikkeld maken, want de kans dat er een HTTP statuscode is die precies aansluit op de applicatiefout die optreedt is vrij klein, en als het niet superduidelijk is wat de statuscode betekent, moet je toch documenteren wanneer welke statuscodes kunnen voorkomen, en dan win je weinig met het gebruik van gestandaardiseerde statuscodes t.o.v. een algemene code met details in de response body.

Natuurlijk kun je nog wel bepaalde HTTP statuscodes gebruiken voor generieke situaties die eigenlijk nog voor de daadwerkelijke applicatielogica liggen. Bijvoorbeeld 404 voor een API endpoint die überhaupt niet bestaat, of 429 als je tegen rate limiting aanloopt, maar binnen de applicatie zou ik fouten ook gewoon mappen naar 400 (als de client request ongeldig is) of 500 (als er een fout optreedt in de server), en het verder niet ingewikkelder maken.

[wackmaniac]

Er zit een wezenlijk verschil tussen 400 en 429, ook in wat ik aan mijn eindgebruiker moet communiceren - een 400 kan een eindgebruiker waarschijnlijk niet zomaar zelf oplossen, en bij 429 kan je melden dat de eindgebruiker even moet wachten. Dus ik zou het zeer zeker niet allemaal naar 400 mappen, in geen enkele applicatie, als ik eerlijk ben.

[Mugwump]

429 is in mijn ogen dan inderdaad weer een voorbeeld van iets dat compleet onafhankelijk van je specifieke applicatiedomein gewoon een duidelijke betekenis heeft. Vaak trek je hem ook buiten je hele applicatie naar een (API) Gateway laag die zorgt dat (al dan niet bewuste) DoS aanvallen je applicatie niet lamleggen. Wat daarin nog applicatiespecifiek kan zijn is rates gebaseerd op abonnementsvorm of credits of iets dergelijks, maar ook dat trek je vaak naar een generiekere laag.

[Jolijter]

Voutloos schreef op maandag 22 september 2025 @ 15:46:
400, en in de body ‘selected course id is not an open course’.

Klaar, niet zo moeilijk doen mensen. 409 kent men niet en je maakt allemaal aannames over cachelagen e.d. Zolang de response body maar uitlegt welk veld, waarom fout is, is de rest allemaal geneuzel.

Weet je wat ook niet moeilijk is? Altijd een 200 teruggeven met mogelijk een fout in de response. Als we al een 400 gaan gooien wanneer er iets mis is met het request, waarom dan niet ook de moeite nemen om een status code te gebruiken die het probleem beter aangeeft?

[DevWouter]

Het lollige van deze hele discussie is dat hoe je fout afhandelt domein afhankelijk is. Dus een 200 kan vanuit het domein als correct beschouwd worden ook als het technisch onjuist/onwenselijk is.

[Voutloos]

Jolijter schreef op woensdag 24 september 2025 @ 11:12:

Weet je wat ook niet moeilijk is? Altijd een 200 teruggeven met mogelijk een fout in de response.

Hellend vlak en baby met badwater.

Als we al een 400 gaan gooien wanneer er iets mis is met het request, waarom dan niet ook de moeite nemen om een status code te gebruiken die het probleem beter aangeeft?

Over veel vd exotische codes is men het al niet eens dus. Dus ik gebruik ook zeker wél 401, 403, 404 en 429.
Maar voor dit scenario is het niet objectief duidelijk dat 409 het beter aangeeft. Dan wordt het bij mij helaas de 400 kapstokstatus voor clientfout.
Dan spendeer ik vervolgens liever de tijd aan het oplossen waarom die cache zogenaamd vaak stale is, dan de kleur van het fietsenhok.

[eheijnen]

En dan is het nu tijd voor een nieuwe draad waarin er wordt samengewerkt aan het ontwikkelen van een standaard...

[Merethil]

eheijnen schreef op donderdag 25 september 2025 @ 07:53:
En dan is het nu tijd voor een nieuwe draad waarin er wordt samengewerkt aan het ontwikkelen van een standaard...

Ik wil voorstellen dat we een nieuwe standaard opzetten die werkt met remote function calls ipv duidelijk maken met een URL wat we willen, en de server zelf laten verzinnen wat we doen.
We noemen het Zeer Efficiënt Entreepunt Protocol (ZEEP) en het ziet eruit als:

JSON:

{
    "Enveloppe": {
        "Hoofd": {
            "__voorvoegsel": "zeep"
        },
        "Lichaam": {
            "HaalGebruikerOp": {
                "GebruikerIdentificatie": "123"
            },
            "__voorvoegsel": "zeep"
        },
        "_jsonns:zeep": "https://www.zeep.nl/2025/09/zeep-enveloppe",
        "__voorvoegsel": "zeep"
    }
}

[AlphaRomeo]

eheijnen schreef op donderdag 25 september 2025 @ 07:53:
En dan is het nu tijd voor een nieuwe draad waarin er wordt samengewerkt aan het ontwikkelen van een standaard...

Daar hoort een xkcd bij...

[Kalentum]

eheijnen schreef op donderdag 25 september 2025 @ 07:53:
En dan is het nu tijd voor een nieuwe draad waarin er wordt samengewerkt aan het ontwikkelen van een standaard...

Soap, GraphQL, JSON-RPC, gRPC over HTTP

Het idee achter REST is dat een API dus deels HTTP gebruikt als applicatielaag. De URL's zijn belangrijk, de HTTP verbs en dus ook de HTTP Headers.

Bij andere "<whatever> over HTTP"-standaarden is dat anders: HTTP wordt gebruikt worden voor transport, misschien authenticatie (tokens enzo in de header) maar HTTP status codes hebben betrekking op de API zelf: een 404 betekent dat je een verkeerde URL gebruikt voor de API, een 403 betekent dat je geen API toegang hebt, een 301 betekent dat het API endpoint is gewijzigd. Maar dan zeggen de status codes niets over de data zelf.

[ Voor 52% gewijzigd door Kalentum op 25-09-2025 10:59 ]

[Crazy D]

Merethil schreef op donderdag 25 september 2025 @ 08:55:
[...]


Ik wil voorstellen dat we een nieuwe standaard opzetten die werkt met remote function calls ipv duidelijk maken met een URL wat we willen, en de server zelf laten verzinnen wat we doen.
We noemen het Zeer Efficiënt Entreepunt Protocol (ZEEP) en het ziet eruit als:

JSON:

{
    "Enveloppe": {
        "Hoofd": {
            "__voorvoegsel": "zeep"
        },
        "Lichaam": {
            "HaalGebruikerOp": {
                "GebruikerIdentificatie": "123"
            },
            "__voorvoegsel": "zeep"
        },
        "_jsonns:zeep": "https://www.zeep.nl/2025/09/zeep-enveloppe",
        "__voorvoegsel": "zeep"
    }
}

Uh ja maar het ging om de response codes Dus wat doe je als 123 geen bestaande gebruikers ID is. Of je stuurt A1 mee als gebruikers Id?

[CodeCaster]

Kalentum schreef op donderdag 25 september 2025 @ 10:32:
[...]


Soap, GraphQL, JSON-RPC, gRPC over HTTP

Het idee achter REST is dat een API dus deels HTTP gebruikt als applicatielaag. De URL's zijn belangrijk, de HTTP verbs en dus ook de HTTP Headers.

Bij andere "<whatever> over HTTP"-standaarden is dat anders: HTTP wordt gebruikt worden voor transport, misschien authenticatie (tokens enzo in de header) maar HTTP status codes hebben betrekking op de API zelf: een 404 betekent dat je een verkeerde URL gebruikt voor de API, een 403 betekent dat je geen API toegang hebt, een 301 betekent dat het API endpoint is gewijzigd. Maar dan zeggen de status codes niets over de data zelf.

En wat zegt een 404 dan? Dat het endpoint niet bestaat, of de resource die wordt aangemerkt door de verzochte identifier?

En in het geval van een 429, doet de client te veel verzoeken binnen een bepaald tijdsbestek, of mag de klant maar één order per uur plaatsen?

Fielding zei:

quote: https://ics.uci.edu/~fiel...on/evaluation.htm#sec_6_3

If a recipient does not understand the specific semantics of the status code in a given message, then they must treat it in the same way as the x00 code within its class.

Een client die een statuscode kan indelen in "ik doe iets fout en kan het niet opnieuw proberen (4xx)" en "de server doet iets fout (5xx), ik probeer het later nog eens", is één ding.

Weten wat die met een specifieke response moet, zelfs als die het met de server(applicatie) eens is over de betekenis van die code, is heel iets anders - en dat beschrijft REST ook niet, en is juist wel waar de discussie in dit topic op dit moment over gaat.

Dáár is (naar mijn weten) nog geen standaard voor. Een aanpak die wij doen, is samen met RFC 9457 Problem Details en diens members type en errors aangeven wat er mis is. Soms uitgebreid met een code-element.

Zie ook Swagger: Problem Details (RFC 9457): Doing API Errors Well.

Het is dan nog steeds een kwestie van tekstuele documentatie die we delen met gebruikers van de API, en het door hen correct implementeren daarvan. En aan onze, serverende kant zorgen dat nieuwe foutmeldingen adequaat gecommuniceerd worden.

[ Voor 4% gewijzigd door CodeCaster op 25-09-2025 13:36 ]

[Mugwump]

In m'n huidige project gebruiken we inderdaad ook de ProblemDetail RFC. Spring ondersteunt em ook out of the box. Alleen een beetje jammer dat dat weer lastig te integreren is met design first aanpak die centraal wordt afgedwongen omdat je gegenereerde code dan weer niet makkelijk te integreren is.

Maar ach, we moeten ook nog deels SOAP ondersteunen en vergelijken daarmee zijn alle REST-perikelen peanuts.

[Merethil]

Crazy D schreef op donderdag 25 september 2025 @ 13:17:
[...]

Uh ja maar het ging om de response codes Dus wat doe je als 123 geen bestaande gebruikers ID is. Of je stuurt A1 mee als gebruikers Id?

Dan gooit de server natuurlijk gewoon een stacktrace terug, of throwt de exception die jij moet afhandelen in je call, duh! Het is een function invocation!!!!

[DevWouter]

🤣

[.oisyn]

Ugh, er is een hdd gecrasht in mijn nas. Wéér bay 4, dit is echt al de 4e keer oid. Ik heb nog een Syno DS412+, hij is al 12 jaar oud, dus ik zat te kijken naar nieuwe nassen.

Maar wat is die nieuwe Synology policy waardeloos zeg . Alleen nog maar schijven van hen zelf voor alle modellen vanaf 2025. Maar ik wil ook wel graag 2.5Gbps, en dat zie je dan weer niet op de modellen vóór 2025.

Qnap dan maar? Echt totaal geen ervaring mee. Kun je daar ook gewoon custom zooi op draaien (webserver, docker containers, etc)? Is wel allemaal ARM zag ik, maar dat moet tegenwoordig toch niet zo'n issue meer zijn?

Ik kan ook wel voor een 224+ of een 423+ gaan en dan de 2x1Gbps trunken. Maar door dat klotegedrag van Synology wordt het ook wel een beetje een principekwestie

[downtime]

.oisyn schreef op zondag 28 september 2025 @ 12:54:
Ugh, er is een hdd gecrasht in mijn nas. Wéér bay 4, dit is echt al de 4e keer oid. Ik heb nog een Syno DS412+, hij is al 12 jaar oud, dus ik zat te kijken naar nieuwe nassen.

Maar wat is die nieuwe Synology policy waardeloos zeg . Alleen nog maar schijven van hen zelf voor alle modellen vanaf 2025. Maar ik wil ook wel graag 2.5Gbps, en dat zie je dan weer niet op de modellen vóór 2025.

Qnap dan maar? Echt totaal geen ervaring mee. Kun je daar ook gewoon custom zooi op draaien (webserver, docker containers, etc)? Is wel allemaal ARM zag ik, maar dat moet tegenwoordig toch niet zo'n issue meer zijn?

Ik kan ook wel voor een 224+ of een 423+ gaan en dan de 2x1Gbps trunken. Maar door dat klotegedrag van Synology wordt het ook wel een beetje een principekwestie

Er schijnt met WD gewerkt te worden aan een lijst van supported disks voor de nieuwe Synology’s. Als je kunt wachten is het misschien interessant om even af te wachten of dat de situatie verbetert.

Ik ben wel een beetje sceptisch. Dat ze alleen met WD praten wekt bij mij de indruk dat het wel eens om speciale “Approved by Synology” types kan gaan, met een hoger prijskaartje, in plaats van de reguliere WD Reds.

[RobertMe]

.oisyn schreef op zondag 28 september 2025 @ 12:54:
Ik kan ook wel voor een 224+ of een 423+ gaan en dan de 2x1Gbps trunken.

Ik neem aan dat je weet dat dat net wat anders is? 2,5Gbit/s is één rijbaan waar je "250" mag rijden. 2x 1Gbit/s zijn twee rijbanen waar je "100" mag rijden.
Als je verder alleen 1Gbit/s apparatuur hebt is een bond in principe prima want dan kunnen twee apparaten tegelijkertijd nog steeds verdeeld worden over de twee poorten van de bond. Maar 1 2,5Gbit/s zal bij een bond in principe nog steeds maar 1Gbit/s maximaal doen. Tenzij de software meerdere verbindingen tegelijkertijd op zet die vervolgens verdeeld worden. Maar dan heb je effectief dus gewoon 2 verbindingen van 1Gbit/s die tegelijkertijd 2 verschillende delen van hetzelfde bestand (bv) kopiëren.

[ Voor 5% gewijzigd door RobertMe op 28-09-2025 14:23 ]

[.oisyn]

RobertMe schreef op zondag 28 september 2025 @ 14:23:
[...]

Ik neem aan dat je weet dat dat net wat anders is?

Nee? Als ik er een 2.5G switch aan hang die ook pair binding ondersteunt, worden de packets dan niet gewoon verdeeld?

[RobertMe]

.oisyn schreef op zondag 28 september 2025 @ 14:26:
[...]

Nee? Als ik er een 2.5G switch aan hang die ook pair binding ondersteunt, worden de packets dan niet gewoon verdeeld?

Neen. Bonding heeft een "algoritme" die op basis van source + destination MAC (denk ik, want layer 2) en TCP/UDP port bepaald over welke poort het gestuurd wordt. Één TCP verbinding zal dus nooit over beide poorten tegelijkertijd gaan. Mogelijk uberhaupt alleen al omdat de pakketjes dan onbedoeld in de verkeerde volgorde aan kunnen komen?
En je loopt dus ook het risico dat zelfs met bonding het verkeer van 2 apparaten alsnog over dezelfde poort heen gaat. Simpelweg omdat de uitkomst van het algoritme / de formule is dat beiden over de eerste poort moeten. Ook al zouden beiden dus 1Gbit/s dicht willen trekken waardoor van switch naar Syno (/bonded apparaat) maar 1 poort effectief die 1Gbit/s dicht trekt, en de andere poort niks doet. Die hele standaard is AFAIK ook stateless, dus er wordt géén "load balancing" gedaan om in dat scenario wel de load te verdelen over beide poorten.

Nog los van dat je AFAIK ook tegen issues aan kunt lopen dat je vanaf een 2,5Gbit/s PC met 2,5Gbit/s iets naar de switch kunt sturen maar de switch het dus maar met 1Gbit/s "door kan duwen" waardoor de buffers in de switch overflowen. (Met als gevolg retransmits waardoor de snelheid nog lager uit komt dan 1Gbit/s?)

[.oisyn]

Ja ik heb me inmiddels ingelezen. Wat een stom systeem zeg. Ik snap dat het niet precies in sync kan (want verschillende kabels), maar volgorde van ethernet packets is sowieso al niet gegarandeerd, dus je kunt in principe prima een simpel protocol bedenken waarbij je packets interleaved over beide poorten transmit.

Maar goed, zowel Synology als Windows 11 Pro ondersteunen multichannel SMB, dat zou evt een oplossing zijn?

Maar goed ik wil eigenlijk gewoon 2.5+Gbit

.edit: oh bepaalde USB nics werken blijkbaar ook op een Synology. Dan is dat ook nog een optie.

.edit2: en de 723+ en 923+ hebben een pci-e slot waar een 10Gb nic in kan. En daar kan ook meer geheugen in (tot 32GB, ipv de 6GB van de 2xx+/4xx+). En ook een betere CPU. 🤔

[ Voor 22% gewijzigd door .oisyn op 28-09-2025 18:02 ]

[eheijnen]

Praat hier eens mee.
Staat goed aangschreven en schijnt er verstand van te hebben.
https://tweakers.net/gallery/366580/aanbod/

[.oisyn]

Meh, heb gewoon de 923+ besteld + 4x 4TB WD Red Plus

[AW_Bos]

Toch zonde dat Firefox in HTML een type="search" behandelt als een text-veld, en niet zoals een text-veld mét een handig verwijder-input-kruisje wat Edge en Chrome gewoon doen. Waarom blijft Firefox nu achter....

Misschien moet ik dan maar mijn eigen implementatie schrijven.

[ Voor 13% gewijzigd door AW_Bos op 29-09-2025 10:57 ]

[.oisyn]

In other news...

[Maasluip]

Server hier op het werk gaat verhuizen "naar de cloud". Server wordt ook als sFTP server gebruikt. Ik krijg er nu van te horen, de move is over 2 weken.
Zeg ik "krijgen we nieuwe ssh keys?

Grote vraagtekens bij het migratieteams. (lees dit met een Indiaas accent) "Are you connecting via IP"? Nee, hostname. "DNS stays the same, so all will be good".
Nee vrienden, dat is niet hoe het werkt.
...
"I checked, I've been told it's the same ssh key. Maybe you call in the meeting tomorrow?"

Geweldig. Zit ik morgen in een meeting met Indiërs die je maar half verstaat en die je moet overtuigen dat een serverchange toch echt voor een nieuwe ssh key zorgt.

[DevWouter]

Maasluip schreef op dinsdag 30 september 2025 @ 13:19:
Geweldig. Zit ik morgen in een meeting met Indiërs die je maar half verstaat en die je moet overtuigen dat een serverchange toch echt voor een nieuwe ssh key zorgt.

De private key van de server zou, in theorie, toch ook mee kunnen verhuizen? Niet dat ik het verwacht, gezien hoe jij het proces omschrijft.

Verder vind ik het vooral verbazingwekkend dat bij dit soort processen er geen input van de teams gevraagd worden. Succes morgen!

[SPee]

Uitkomst van de meeting morgen:
We wisten niet dat het sFTP draait. We gaan die alsnog toevoegen. En controleren welke andere services er nog meer draaien en of we niet nog meer hebben gemist.

[Maasluip]

DevWouter schreef op dinsdag 30 september 2025 @ 13:32:
[...]

De private key van de server zou, in theorie, toch ook mee kunnen verhuizen? Niet dat ik het verwacht, gezien hoe jij het proces omschrijft.

Verder vind ik het vooral verbazingwekkend dat bij dit soort processen er geen input van de teams gevraagd worden. Succes morgen!

Ik zou zeggen dat die verandert. Anders kan ik een server optuigen, de dns name van de server hijacken en ik krijg je data.
Lijkt me niet helemaal secure dan.

Maar ik heb net ook een call gehad en er werd mij verzekerd dat het niet gaat veranderen. Goed, als het ook niet meer dan een key is die verandert dan heb ik dat ook gauw aangepast.

[RobertMe]

Maasluip schreef op dinsdag 30 september 2025 @ 15:55:
[...]

Ik zou zeggen dat die verandert. Anders kan ik een server optuigen, de dns name van de server hijacken en ik krijg je data.
Lijkt me niet helemaal secure dan.

Daarvoor heb je dan wel nog de private key van de "oude" server nodig. En als hacker (/hijacker) zul je die als het goed is niet hebben. Terwijl die intern in het bedrijf prima over te zetten is. Personal note: ik zou ook gewoon een nieuwe key op een nieuwe server zetten.

[SPee]

Als de huidige server een VM is, dan zou je die makkelijk 1op1 over kunnen zetten en is er idd geen verschil. Maar het is gewoon afwachten hoe ze dat doen en gewoon inplannen dat je daar werk aan hebt.

[.oisyn]

.oisyn schreef op zondag 28 september 2025 @ 23:52:
Meh, heb gewoon de 923+ besteld + 4x 4TB WD Red Plus

En de bijbestelde G.Skill Ripjaws werken hier niet in

[.oisyn]

Echt WTF waarom is het zo fucking gecompliceerd om gewoon files te kopieren van de ene NAS naar de andere.

Shared folder sync bestaat niet op DSM 6
HyperBackup maakt er een eigen folderstructuur van
Remote folder mounten en files copyen via FileStation houdt de metadata niet intact
Syncthing (middels een community package) lijkt sowieso geen files te detecten.
rsync vanuit een SSH sessie lijkt niet te willen connecten

Moet ik nou serieus gewoon gaan robocopyen vanaf een Windows machine? Echt hoe fucking moeilijk kan het zijn

.edit: Ok, remote folder mounten en dan "lokaal" rsyncen lijkt te werken...

.edit2: Oh allejezus, Shared Folder Sync bestaat wel op DSM 6, alleen staat die op een andere plek in het menu

[ Voor 21% gewijzigd door .oisyn op 30-09-2025 23:46 ]

[Damic]

pfffffff omfg dat is een breinbreker (voor mij dan).
ben al een aantal dagen een login pagina aan't debuggen op een (voor mij) nieuw php framework (CodeIgnitor). Ik kreeg telkens een witte pagina maar de data ging wel mee. Wat blijkt, als je van functie naar functie springt mag je natuurlijk telkens de returns niet vergeten

Return toegevoegd en daar is de pagina

[DevWouter]

Aargh…

[sig69]

Php..
Maar dan is je ontwikkel omgeving dus ook kut, die moet daar op z'n minst een waarschuwing op geven.

[ Voor 91% gewijzigd door sig69 op 03-10-2025 02:16 ]

[sig69]

.oisyn schreef op dinsdag 30 september 2025 @ 23:18:


.edit2: Oh allejezus, Shared Folder Sync bestaat wel op DSM 6, alleen staat die op een andere plek in het menu

Dat wist ik. Tijdje niet in het topic geweest alleen. Hij komt niet vaak naar boven. (Heb je niks aan, weet ik )

[Damic]

@sig69 waarom zou die een melding geven?
Volgende probleem heeft zich ook al aangemeld. Hoe naar de db schrijven. Gaat nog een aantal dagen duren

[Matis]

Damic schreef op vrijdag 3 oktober 2025 @ 06:56:
@sig69 waarom zou die een melding geven?
Volgende probleem heeft zich ook al aangemeld. Hoe naar de db schrijven. Gaat nog een aantal dagen duren

Met een beetje geluk heeft / vereist het framework een bepaald type of typen dat de functie moet returnen.
Dat kun je afdwingen in de functie (boilerplate) zelf of in de aanroepende functie die controleert of hij de juiste types ontvangt.

Enniehoe, fijn dat het is gevonden

[wackmaniac]

sig69 schreef op vrijdag 3 oktober 2025 @ 02:11:
Php..
Maar dan is je ontwikkel omgeving dus ook kut, die moet daar op z'n minst een waarschuwing op geven.

Deze fout zou ook in Python of JavaScript kunnen voorkomen. Die vingen dit ook niet af. En als je elders in je functie/method wel een return hebt dan zou het in vrijwel elke taal kunnen voorkomen.

Damic schreef op vrijdag 3 oktober 2025 @ 06:56:
@sig69 waarom zou die een melding geven?
Volgende probleem heeft zich ook al aangemeld. Hoe naar de db schrijven. Gaat nog een aantal dagen duren

Wat je wilt doen in een loosely typed taal (als PHP) is het zo strikt mogelijk maken. Dus zorg dat je functies/methodes een return type definiëren. In dat geval zal PHP het je vertellen als je geen return hebt: https://3v4l.org/pRhCT En je kan daar ook tooling voor gebruiken als Psalm of PHPStan, zodat je dit middels inspecties kan vinden.

[Mugwump]

CodeIgniter, daar heb ik geloof ik een jaar of 15 geleden voor het laatst wat mee gedaan.

[RobertMe]

Mugwump schreef op vrijdag 3 oktober 2025 @ 08:59:
CodeIgniter, daar heb ik geloof ik een jaar of 15 geleden voor het laatst wat mee gedaan.

Zoiets dacht ik ook al. CodeIgniter 2. Was zo dood als wat. Op een of andere manier hebben ze het toen nog voor elkaar gekregen om de boel te verkopen. Waarbij de nieuwe eigenaren nog net een v3 wilden komen met behoud van bepaalde mate van backwards compatibility. Terwijl de totale opzet compleet verrot was (alles ophangen aan 1 groot "God object" i.p.v. fatsoenlijke dependency injection / inversion of control bv).

[Mugwump]

Moet zeggen dat ik me er enkel nog van herinner dat het in die tijd een relatief lichtgewicht frameworkje was vergeleken met de Symfonies van deze wereld. Ook al ongeveer net zo lang geen PHP gedaan, maar volgens mij zijn er inmiddels wel aardige stappen geweest en is de 'fractal of bad design' tegenwoordig niet helemaal terecht meer.

[Voutloos]

Heb je een reden voor CodeIgniter?
• Nee: Doe jezelf een plezier en start met Symfony, Laravel of Api-Platform. Veel meer leven in.
• Ja: Doe jezelf pijn en ga daarna door met bovenste antwoord.

Keuze tussen genoemde alternatieven is al gauw een holy war, doe vooral zelf onderzoek naar gelang smaak en wensen. Maar populariteit voor die pakketten (uiteindelijk allemaal leunend op Symfony) is gewoon dag en nacht verschil met de rest.

[ Voor 42% gewijzigd door Voutloos op 03-10-2025 11:28 ]

[Voutloos]

En elk PHP project, ook hobbymatig: Composer en PHPStan zijn een must. Zonder composer is al direct af. PHPStan, zelfs het minst stricte level, win je altijd terug qua tijd en minder verrassingen later.

[RobertMe]

Voutloos schreef op vrijdag 3 oktober 2025 @ 11:31:
En elk PHP project, ook hobbymatig: Composer en PHPStan zijn een must. Zonder composer is al direct af. PHPStan, zelfs het minst stricte level, win je altijd terug qua tijd en minder verrassingen later.

Mag PSalm ook i.p.v. PHPStan?

Zelf ook PHPStan gebruiker, daar niet van. Maar volgens mij is de een niet echt beter dan de ander. Zeker als je dus op een laag level zou gebruiken. En iets als Symfony gebruikt AFAIK ook Psalm. (Andere, zoals Doctrine, dan weer PHPStan).

[Voutloos]

Psalm mag ook, redelijk gelijk idd. Maar PHPStan gaat momenteel wel echt heel hard qua doorontwikkeling en je ziet projecten switchen. Dus ik noem hem toch het eerste.

Het voorbeeld met missende return was niet helemaal in detail toegelicht, maar ik durf wel te denken dat je met 1 van deze qualitytools inrichten het ook gevonden had, met minder guesswork.

[RobertMe]

Voutloos schreef op vrijdag 3 oktober 2025 @ 12:57:
Het voorbeeld met missende return was niet helemaal in detail toegelicht, maar ik durf wel te denken dat je met 1 van deze qualitytools inrichten het ook gevonden had, met minder guesswork.

Zonder typehints (echte of PHPDoc) wordt het voor een static analyzer natuurlijk ook lastig om een missende return te vinden.

Of de functie moet al meerdere exit paths (/returns) hebben waarvan sommige met een value en anderen zonder value (of geen return aan het eind van de functie).

PHP:

function foo() {}

Is namelijk nogal vaag in of er een return zou moeten zijn.

PHP:

function foo() {
  if (true) {
    return 42;
  }
}

Kun je wel aan zien dat er een return mist en de functie dus geen void "returned" maar dat er of een expliciete return null; mist of dus een daadwerkelijke return (met int value).