HTTP -status 204 - Geen inhoud: uitleg en best practices

De meeste mensen in de digitale ruimte herkennen bekende HTTP -statuscodes zoals 200 OK of 404 niet gevonden, maar sommige nuttige krijgen niet zoveel aandacht.

Een van deze is 204 geen inhoud.Laten we eens nader bekijken wat deze status betekent, hoe deze werkt en wanneer het geschikt is om te gebruiken.

Wat betekent HTTP 204?

HTTP -statuscodes helpen servers en browsers op dezelfde pagina te blijven door te laten zien wat er met een verzoek is gebeurd.De 2xx categorie codes zijn meestal degenen die we het meest waarderen, omdat ze aantonen dat het verzoek succesvol was.

Onder deze staat 204 geen inhoud een unieke plek in.Het bevestigt dat de server met succes het verzoek van de client heeft afgehandeld, maar geen inhoud heeft om terug te sturen.Met andere woorden, de server vertelt de client: "Alles is goed gegaan, maar er is niets nieuws voor u om te zien."

Verder begrijpen van de reactie

Een status van 204 verschilt van andere succesvolle reacties doordat deze geen inhoud bevat buiten de HTTP -headers.Terwijl een 200 OK HTML, JSON of andere soorten media zou kunnen retourneren, retourneert een 204 alleen metadata in de koptekst en laat het responslichaam leeg.

Hier is een voorbeeld van hoe een 204 -reactie eruit ziet op het protocolniveau:

HTTP/1.1 204 No Content
Date: Mon, 09 Jun 2025 15:22:30 GMT

Er is geen lichaam na de header - geen markup, geen JSON, geen bericht.De client kan veilig aannemen dat de actie is voltooid zoals verwacht, maar hij hoeft de gebruikersinterface niet bij te werken of inhoud opnieuw te laden.

Dit is een bijzonder nuttige toepassing in situaties waarin de klant al alles heeft weergegeven wat hij nodig heeft en alleen maar wil bevestigen dat een achtergrondbewerking (zoals een formulier opslaan of API -oproep) is geslaagd.

Hoe http 204 werkt

Wanneer een client - zoals een browser, mobiele app of script - een verzoek verzendt, vraagt ​​deze de server om een ​​actie uit te voeren.Dit kan alles zijn van het bijwerken van gebruikersinstellingen, het verwijderen van een bron of het controleren op nieuwe informatie.

Dit is wat meestal gebeurt wanneer een 204 -reactie wordt gebruikt:

1. Client verzendt verzoek: De client initieert een verzoek aan de server.Dit kan een bericht zijn om gegevens op te slaan, een verwijderen om een ​​bron te verwijderen of een te controleren op updates.
   
   
2. Server verwerkt het verzoek: De server voert de gevraagde actie uit.Het kan nieuwe informatie opslaan, een item verwijderen of controleren of er geen wijzigingen zijn opgetreden.
   
   
3. Geen inhoud om terug te keren: Als het niet nodig is om een ​​berichtlichaam terug te sturen - geen nieuwe pagina, niet bijgewerkte gegevens - reageerde de server met een status van 204.
   
   
4. Klant ontvangt bevestiging: De klant ziet de 204 -reactie en begrijpt dat het verzoek is geslaagd, maar er is niets nieuws te tonen of vernieuwen.
   
   
5. Geen pagina opnieuw laden of UI wijzigen: Omdat het antwoord geen inhoud bevat, houdt de client het huidige scherm of de interface ongewijzigd, waardoor een naadloze gebruikerservaring wordt behouden.

Waarom u misschien 204 -status wilt gebruiken

Hoewel 204 er minimaal uitziet, dient het een specifiek doel in staatloze communicatie, met name in RESTful API's.Het is ideaal voor lichtgewicht interacties waarbij de server niets nieuws heeft om terug te keren, maar de client heeft nog steeds een definitieve bevestiging nodig.

Wanneer moet u statuscode 204 gebruiken

Als je het juiste moment kent om een ​​204 -geen contentrespons te verzenden, kunnen de site en app -interacties soepel worden verwerken, onnodige pagina opnieuw laden en de algehele gebruikerservaring verbeteren.

Achtergrond slaat op in webapplicaties

Veel web -apps slaan gebruikersinvoer automatisch op, zoals wanneer een gebruiker instellingen of voorkeuren wijzigt.In plaats van de pagina opnieuw te laden of elke keer een bevestigingsbericht weer te geven, verzendt de app de update rustig op de achtergrond.Een reactie van 204 bevestigt dat de verandering werkte zonder de stroom van de gebruiker te onderbreken.

Voorbeeld: een instellingenpagina slaat wijzigingen op zodra een gebruiker een schakelaar schakelt:

fetch('/api/save-setting', {
  method: 'POST',
  body: JSON.stringify({ darkMode: true })
});

De server reageert met:

HTTP/1.1 204 No Content

De pagina vernieuwt of geeft geen bericht weer, maar de voorkeur wordt achter de schermen opgeslagen.

Peiling of controle op updates

Sommige apps controleren de server periodiek op nieuwe informatie met behulp van achtergrondverzoeken.Wanneer er geen nieuwe gegevens zijn, vertelt een reactie van 204 de klant dat alles actueel is, waardoor onnodige inhoud wordt verzonden.

Voorbeeld:

GET /api/notifications
→ 204 No Content

Verwijder verzoeken in API's

Wanneer een API een bron verwijdert, hoeft deze vaak geen inhoud te retourneren.Een 204 -statuscode signaleert de verwijdering, waardoor het antwoord licht wordt behouden.

Voorbeeld:

DELETE /api/posts/123
→ 204 No Content

De klant weet dat het bericht is verwijderd zonder extra gegevens te ontvangen.

Plaats of patch -aanvragen zonder retourgegevens

Voor het bijwerken van bronnen waarbij de client geen nieuwe gegevens of bevestiging nodig heeft dan succes, sluit 204 de interactie netjes.

Voorbeeld:

PATCH /api/user/profile
→ 204 No Content

De client gaat ervan uit dat de update succesvol was en de huidige weergave niet opnieuw laadt of wijzigt.

Wanneer niet om 204 geen inhoud te gebruiken

Hoewel 204 zijn plaats heeft, zijn er situaties waarin het gebruik ervan verwarring kan veroorzaken of de verwachte functionaliteit kan doorbreken:

Wanneer de klant inhoud verwacht

Als de client is ontworpen om gegevens in de reactie te verwerken of weer te geven - zoals HTML, JSON of zelfs een eenvoudig succesbericht - zal een 204 problemen veroorzaken omdat het niets verders levert dan headers.In deze gevallen is een 200 OK met een responslichaam meestal een betere keuze.

Voor het omleiden of bijwerken van de gebruikersinterface

Als uw app de interface moet bijwerken, feedback aan de gebruiker moet tonen of na een verzoek omleidt, helpt 204 niet.Andere statuscodes zoals 200, 201 of zelfs een 307 omleiding kan meer geschikt zijn.

Bij gebruik met bepaalde aanvraagtypen

Sommige klantbibliotheken en browsers kunnen zich onvoorspelbaar gedragen als ze een 204 ontvangen na een post of ander staatsveranderend verzoek.Als de bewerking client-side logica activeert op basis van de reactie van de respons, kan het overslaan van de carrosserie bugs veroorzaken of debuggen moeilijker maken.

Voor foutafhandeling

Een 204 betekent dat alles goed is gegaan.Als er iets mis is gegaan - zoals een mislukte validatie, ontbrekende invoer of serverprobleem - moet 204 niet worden gebruikt.Een status van het 4xx- of 5xx -bereik zou in die gevallen beter geschikt zijn.

Meer informatie: controleer de HTTP-foutcodes Overzicht of duik dieper met onze 403 verboden Gids voor een beter begrip en tips voor probleemoplossing.

Kortom, 204 werkt het beste wanneer de klant niets nieuws nodig heeft - en beide partijen zijn daarover duidelijk.Als er een kans is dat de klant een payload verwacht, vermijdt het gebruik van een reactie met werkelijke inhoud ambiguïteit.

Vergelijking van 204 met andere 2xx statuscodes

HTTP -statuscodes in het 2xx -bereik geven allemaal succesvolle verzoeken aan, maar elk dient een ander doel, afhankelijk van wat de klant moet weten of vervolgens moet doen.Inzicht in deze verschillen helpt u om de juiste code voor uw serverreacties te kiezen en houdt de communicatie tussen de client en server duidelijk en efficiënt.

De 204 No Content Status valt op omdat het succes signaleert zonder inhoud te retourneren of wijzigingen aan de clientzijde aan te richten.

Hoe 204 verschilt van andere 2xx statuscodes

• 200 OK: De meest voorkomende succesrespons, omvat meestal inhoud die de client moet weergeven of gebruiken.Bijvoorbeeld het laden van een webpagina of het ontvangen van gegevens van een API.
  
• 201 gemaakt: Gebruikt wanneer een nieuwe bron wordt gemaakt, zoals na een aanmelding of recordcreatie.Het bevat vaak details over de bron, maar de responsorgaan is optioneel.
  
• 202 geaccepteerd: Betekent dat het verzoek is ontvangen en begrepen, maar de verwerking zal later plaatsvinden.Geen onmiddellijke responsinhoud, gebruikelijk in asynchrone acties.
  
• 204 Geen inhoud: Bevestig succes zonder inhoud om terug te keren.Vertelt de client niet nodig om het display bij te werken of de pagina opnieuw te laden - ideaal voor stille achtergrondbewerkingen zoals opslaan of verwijderen.
  
• 205 Reset inhoud: Stuurt geen inhoud maar instrueert de client om de gebruikersinterface te resetten of te wissen, zoals het wissen van invoervelden na het indienen van een formulier.

SEO -overwegingen

Als het gaat om zoekmachines, kan hoe uw server reageert, beïnvloeden of uw pagina's in zoekresultaten verschijnen.Hoewel de 204 NO-inhoudsstatuscode meestal wordt gebruikt voor interacties achter de schermen, is het belangrijk om de effecten ervan op indexering en zichtbaarheid te begrijpen.Het gebruik ervan in de verkeerde context kan onbedoeld voorkomen dat uw pagina's worden herkend door zoekmachines of het verwarren van kruipende bots.

204 antwoorden worden niet geïndexeerd

Aangezien een 204 -status aangeeft dat de server het verzoek met succes heeft verwerkt, maar geen inhoud heeft om aan te tonen, behandelen zoekmachines deze antwoorden als leeg.Pagina's die een 204 retourneren, worden niet toegevoegd aan zoekmachine -indexen, wat betekent dat ze niet in zoekresultaten zullen verschijnen.

Vermijd 204 voor openbare webpagina's

Als een pagina bedoeld is voor gebruikers om te bekijken - zoals een productpagina, blogpost of startpagina - reageert met 204, zullen zoekmachines deze leeg vinden.Dit kan ertoe leiden dat de pagina volledig uit zoekresultaten wordt verwijderd, waardoor de zichtbaarheid en potentieel verkeer van uw site wordt beperkt.

Gebruik 204 alleen voor API of achtergrondverzoeken

De status van 204 is het best gereserveerd voor API -oproepen, achtergrondbesparingen of andere bewerkingen die geen zichtbare inhoud leveren.Voor pagina's en bronnen die moeten worden geïndexeerd en weergegeven, gebruikt u standaard succescodes zoals 200 met de volledige inhoud opgenomen.

Kijk uit naar Accidental 204 reacties

Soms zorgen configuratiefouten of bugs ervoor dat pagina's per ongeluk 204 retourneren.Controleer uw site regelmatig op onverwachte 204 antwoorden op belangrijke URL's om verlies van zoekmachines te voorkomen.

Voorbeeld: als uw/over pagina 204 retourneert in plaats van 200 met inhoud, zal Google het indexeren.

Prestatievoordelen

Hoewel de 204 No Content Status -code zelf uw site niet versnelt door magie, kan het gebruik ervan doordacht onnodige gegevensoverdrachten en verwerking verminderen.Dit leidt tot een slankere ervaring voor gebruikers, vooral op apparaten met langzamere verbindingen of beperkte bronnen.

Kleinere respons maten

Omdat een 204 -reactie geen lichaam bevat, stuurt het alleen de headers terug naar de klant.Dit betekent dat minder gegevens over het netwerk reizen in vergelijking met een volledige HTML -pagina of JSON -reactie.Kleinere antwoorden besparen de bandbreedte en kunnen de laadtijden verminderen, wat het belangrijkst is voor gebruikers op mobiele netwerken of lagere internetsnelheden.

Snellere interacties

Door succes te bevestigen zonder extra inhoud te verzenden, laten 204 antwoorden apps in stilte en snel achtergrondbewerkingen verwerken.Auto-saving-instellingen of het bevestigen van verwijderingen onderbreekt bijvoorbeeld niet de gebruikersinterface, waardoor de app meer responsiever en soepel kan aanvoelen.

Verminderde verwerking van de klantzijde

Wanneer de browser of app een 204 ontvangt, hoeft deze geen inhoud te parseren of te maken, wat de werklast op de klant verlaagt.Dit maakt bronnen vrij voor andere taken, het verbeteren van de algehele prestaties en gebruikerservaring, vooral op apparaten met een lager vermogen.

Beter resource management

Het gebruik van 204 helpt servers en netwerken om onnodige gegevens te verzenden.Dit kan de serverbelasting verlagen en verkeer verminderen, waardoor het gemakkelijker is om uw toepassing op te schalen bij het hanteren van veel gebruikers of frequente achtergrondverzoeken.

Veel voorkomende fouten om te vermijden

De 204 Geen inhoudscode heeft specifieke regels en gedragingen die moeten worden gevolgd om onverwachte problemen voor gebruikers te voorkomen of de site/app -functionaliteit te doorbreken.Het kennen van deze gemeenschappelijke valkuilen helpt ervoor te zorgen dat de implementatie soepel en voorspelbaar blijft, zowel voor gebruikers als voor ondersteunende systemen.

Retourneren van een antwoordlichaam met 204

De HTTP -specificatie stelt duidelijk dat een reactie van 204 geen responsorgaan mag bevatten.Dit betekent dat geen HTML, JSON of andere inhoud deze statuscode moet vergezellen.Het opnemen van een lichaam kan browsers en klanten verwarren, die geen inhoud verwachten.Sommige klanten kunnen het lichaam negeren, terwijl anderen zich onvoorspelbaar kunnen gedragen.

Voorbeeldfout:
Een server reageert op een achtergrondverzoek met 204 -status, maar bevat per ongeluk een klein JSON -bericht zoals {"status": "OK"}.Hierdoor kan de klant er niet inlijden om het antwoord correct te verwerken.

Beste praktijk:
Zorg er altijd voor dat uw server alleen headers verzendt met een antwoord van 204 - geen berichtlichaam.

Met 204 voor pagina's die bedoeld zijn om inhoud weer te geven

Als een gebruiker een URL bezoekt die een webpagina verwacht, zal reageren met 204 een volledig lege pagina weergeven - geen fouten, geen inhoud, gewoon lege ruimte.Dit verwart gebruikers, leidt tot slechte gebruikerservaring en zorgt ervoor dat zoekmachines de pagina overslaan.

Voorbeeldfout:
Een pagina "Over ons" retourneert ten onrechte 204 in plaats van 200 met HTML -inhoud, zodat bezoekers een leeg scherm zien en zoekmachines de pagina niet indexeren.

Beste praktijk:
Gebruik 200 OK voor alle pagina's die bedoeld zijn om inhoud weer te geven.Reserve 204 voor achtergrond API -oproepen of acties die geen zichtbare feedback vereisen.

Met behulp van 204 om foutafhandeling te omzeilen

Soms kunnen ontwikkelaars een reactie van 204 verzenden, zelfs als een bewerking niet is geslaagd om te voorkomen dat er een foutstatus omgaan.Dit verbergt het probleem van de klant en kan leiden tot verwarring of gegevensverlies.

Voorbeeldfout:
Een API ontvangt ongeldige input maar reageert met 204, waardoor de klant gelooft dat het verzoek is geslaagd wanneer het daadwerkelijk is mislukt.

Beste praktijk:
Gebruik geschikte foutcodes zoals 400 slecht verzoek of 422 niet -verwerkbare entiteit voor validatieproblemen en 500 interne serverfout voor serverproblemen.Stuur alleen 204 wanneer de operatie echt slaagt en er is geen inhoud om terug te keren.

Negeren van de impact op de logica aan de klant aan de klant

Aangezien 204 antwoorden geen instantie bevatten, kunnen clienttoepassingen die verwachten dat gegevens bijwerken dat de gebruikersinterface zal bijwerken of zich onverwacht gedragen als ze een 204 ontvangen zonder deze goed te verwerken.

Voorbeeldfout:
Een front-end script verwacht JSON-gegevens na een opslagbewerking, maar de server retourneert 204. Als het script niet controleert op 204, kan het falen of oude gegevens weergeven.

Beste praktijk:
Ontwerp client-side code om 204 antwoorden sierlijk te verwerken-behandel ze als successignalen zonder gegevens-en werk de gebruikersinterface dienovereenkomstig bij.

204 mengen met omleidingen of cache -headers verkeerd

HTTP -responscodes moeten consistent zijn met andere headers zoals omleidingen of cache -bedieningselementen.Het verzenden van een 204 samen met een omleidingsstatus of conflicterende cache -instructies kan bijvoorbeeld leiden tot niet -gedefinieerd gedrag.

Voorbeeldfout:
Retourneer 204 met een locatiekop om de client om te leiden, die ongeldig is.Redirects vereisen 3xx statuscodes.

Beste praktijk:
Houd 204 antwoorden eenvoudig en vrij van conflicterende headers.Als u moet omleiden, gebruikt u een juiste omleidingsstatuscode zoals 301 of 302.

Afsluiten

HTTP -status 204 is een leuke kleine code die een schone en efficiënte manier biedt om succes te signaleren zonder inhoud terug te verzenden.Het houdt apps responsief door achtergrondtaken stil en efficiënt te bevestigen.

Op de juiste manier gebruikt, helpt het uw site of app snel en soepel te blijven.Gebruik het gewoon op pagina's die inhoud moeten weergeven of worden geïndexeerd door zoekmachines.