Hostwinds 블로그
에 대한 검색 결과:
디지털 공간에있는 대부분의 사람들은 200 OK 또는 404와 같은 친숙한 HTTP 상태 코드를 인식하지만 유용한 일부는 스포트라이트를 많이 얻지 못합니다.
이 중 하나는 204 내용이 없습니다.이 상태가 무엇을 의미하는지, 작동 방식 및 사용하기에 적절한시기를 자세히 살펴 보겠습니다.
HTTP 상태 코드는 요청에 따라 발생한 일을 보여줌으로써 서버 및 브라우저가 같은 페이지를 유지하는 데 도움이됩니다.2xx 카테고리의 코드 범주는 일반적으로 요청이 성공했음을 보여주기 때문에 가장 감사하는 코드입니다.
이 중 204 개의 콘텐츠는 독특한 장소를 보유하고 있습니다.서버가 클라이언트의 요청을 성공적으로 처리했지만 다시 보낼 내용이 없음을 확인합니다.다시 말해서 서버는 클라이언트에게 "모든 것이 잘되었지만 새로운 것은 없습니다."
204 상태는 HTTP 헤더 이외의 컨텐츠가 포함되어 있지 않다는 점에서 다른 성공적인 응답과 다릅니다.200 OK는 HTML, JSON 또는 기타 유형의 미디어를 반환 할 수 있지만 204 개는 헤더 섹션에서 메타 데이터 만 반환하고 응답 본문을 비워 둡니다.
다음은 프로토콜 수준에서 204 응답이 어떻게 보이는지에 대한 예입니다.
HTTP/1.1 204 No Content
Date: Mon, 09 Jun 2025 15:22:30 GMT
헤더 후에는 마크 업, JSON, 메시지가 없습니다.클라이언트는 예상대로 완료 한 작업을 안전하게 가정 할 수 있지만 사용자 인터페이스를 업데이트하거나 컨텐츠를 다시로드 할 필요는 없습니다.
이는 클라이언트가 이미 필요한 모든 것을 렌더링하고 배경 작업 (양식 저장 또는 API 호출)이 성공한다는 확인을 원하는 상황에서 특히 유용한 응용 프로그램입니다.
브라우저, 모바일 앱 또는 스크립트와 같은 클라이언트가 요청을 제기 할 때 서버에 작업을 수행하도록 요청합니다.이는 사용자 설정을 업데이트하거나 리소스 삭제 또는 새 정보를 확인하는 것의 모든 것일 수 있습니다.
다음은 204 응답이 사용될 때 일반적으로 발생합니다.
204는 최소한으로 보일 수 있지만, 특히 RESTFUL API에서는 무국적 통신의 특정 목적을 달성합니다.서버가 새로운 반품이 없지만 클라이언트는 여전히 결정적인 승인이 필요한 가벼운 상호 작용에 이상적입니다.
204 컨텐츠 응답을 보내기에 적절한시기를 알면 사이트 및 앱 상호 작용이 원활하게 실행되는 데 도움이되고 불필요한 페이지 재 장전을 피하고 전반적인 사용자 경험을 향상시킬 수 있습니다.
많은 웹 앱은 사용자가 설정 또는 환경 설정을 변경할 때와 같이 사용자 입력을 자동으로 저장합니다.페이지를 다시로드하거나 매번 확인 메시지를 표시하는 대신 앱은 배경에서 조용히 업데이트를 보냅니다.204 응답에 따르면 사용자의 흐름을 방해하지 않고 변경이 작동했음을 확인합니다.
예 : 설정 페이지는 사용자가 스위치를 전환하자마자 변경 사항을 저장합니다.
fetch('/api/save-setting', {
method: 'POST',
body: JSON.stringify({ darkMode: true })
});
서버는 다음과 같이 응답합니다.
HTTP/1.1 204 No Content
페이지는 메시지를 새로 고치거나 표시하지 않지만 선호도는 무대 뒤에서 저장됩니다.
일부 앱은 배경 요청을 사용하여 새 정보를 정기적으로 확인합니다.새로운 데이터가 없으면 204 응답에 따르면 클라이언트가 모든 것이 최신임을 알려주며 불필요한 컨텐츠가 전송되는 것을 방지합니다.
예:
GET /api/notifications
→ 204 No Content
API가 리소스를 삭제하면 컨텐츠를 반환 할 필요가 없습니다.204 상태 코드는 삭제가 작동하여 응답을 가볍게 유지합니다.
예:
DELETE /api/posts/123
→ 204 No Content
클라이언트는 추가 데이터를 수신하지 않고 게시물이 제거되었음을 알고 있습니다.
클라이언트가 성공할 수없는 새로운 데이터 나 확인이 필요하지 않은 리소스를 업데이트하려면 204는 상호 작용을 깨끗하게 닫습니다.
예:
PATCH /api/user/profile
→ 204 No Content
클라이언트는 업데이트가 성공했다고 가정하고 현재보기를 다시로드하거나 변경하지 않습니다.
204는 그 자리에 있지만 그것을 사용하는 상황이 혼란을 일으키거나 예상 기능을 중단 할 수있는 상황이 있습니다.
클라이언트가 HTML, JSON 또는 간단한 성공 메시지와 같이 응답에서 데이터를 처리하거나 표시하도록 설계된 경우 204는 헤더 이상을 제공하지 않기 때문에 문제를 일으킬 수 있습니다.이 경우 응답 본문이있는 200 확인이 일반적으로 더 나은 선택입니다.
앱이 인터페이스를 업데이트 해야하는 경우 사용자에게 피드백을 표시하거나 요청 후 리디렉션하면 204는 도움이되지 않습니다.200, 201 또는 a와 같은 다른 상태 코드 307 리디렉션 더 적합 할 수 있습니다.
일부 클라이언트 라이브러리 및 브라우저는 게시물 또는 기타 상태 변경 요청 후 204를 받으면 예측할 수 없을 정도로 행동 할 수 있습니다.작업이 응답 내용에 따라 클라이언트 측로 로직을 트리거하면 신체를 건너 뛰면 버그가 발생하거나 디버깅을 더 어려워 질 수 있습니다.
204는 모든 것이 잘되었음을 의미합니다.유효성 검사 실패, 입력 누락 또는 서버 문제와 같은 문제가 발생하면 204를 사용해서는 안됩니다.이러한 경우 4xx 또는 5xx 범위의 상태가 더 적합합니다.
자세히 알아보십시오 : 확인하십시오 HTTP 오류 코드 우리와 함께 개요 또는 더 깊이 다이빙하십시오 403 금지 더 나은 이해 및 문제 해결 팁을위한 안내서.
요컨대, 204는 클라이언트가 새로운 대가를 필요로하지 않을 때 가장 잘 작동하며 양측은 명확합니다.클라이언트가 페이로드를 기대할 가능성이있는 경우 실제 컨텐츠와 함께 응답을 사용하면 모호함을 피합니다.
2xx 범위의 HTTP 상태 코드는 모두 성공적인 요청을 나타냅니다. 그러나 고객이 다음에 알고 있거나 수행 해야하는 내용에 따라 각각 다른 목적을 제공합니다.이러한 차이점을 이해하면 서버 응답에 적합한 코드를 선택하고 클라이언트와 서버 간의 통신을 명확하고 효율적으로 유지할 수 있습니다.
204 No Content 상태는 컨텐츠를 반환하거나 클라이언트 측의 변경 사항을 제기하지 않고 성공을 알리기 때문에 눈에 띄게 나타납니다.
상태 코드 | 기술 | 응답 본문 | 사용 사례 예제 |
200 | OK - 요청이 성공했습니다 | 예 | 웹 페이지로드 또는 JSON 검색 |
201 | 생성 - 새로운 자원 | 선택 과목 | 사용자를 생성하는 양식을 제출합니다 |
202 | 허용 - 나중에 처리 | 즉각적인 내용이 없습니다 | 나중에 처리 할 파일 업로드 |
204 | 내용 없음 - 더 이상 보여줄 것이 없습니다 | 아니 | 백그라운드에서 조용히 설정을 저장합니다 |
205 | 컨텐츠 재설정 - UI보기를 지우십시오 | 아니 | 양식을 제출하고 입력을 청소합니다 |
검색 엔진과 관련하여 서버 응답 방법이 검색 결과에 페이지가 나타나는지 여부에 영향을 줄 수 있습니다.204 NO Content 상태 코드는 대부분 비하인드 스토리 상호 작용에 사용되지만 인덱싱 및 가시성에 미치는 영향을 이해하는 것이 중요합니다.잘못된 맥락에서 사용하면 의도하지 않게 검색 엔진으로 페이지가 인식되는 것을 방지하거나 크롤링 봇을 혼동 할 수 있습니다.
204 상태는 서버가 요청을 성공적으로 처리했지만 표시 할 내용이 없으므로 검색 엔진은 이러한 응답을 비어있는 것으로 취급합니다.204를 반환하는 페이지는 검색 엔진 인덱스에 추가되지 않으므로 검색 결과에 나타나지 않습니다.
제품 페이지, 블로그 게시물 또는 홈페이지와 같이 사용자가 볼 수있는 페이지가 204로 응답하는 경우 검색 엔진이 비어 있습니다.이로 인해 페이지가 검색 결과에서 완전히 삭제되어 사이트의 가시성과 잠재적 트래픽을 제한 할 수 있습니다.
204 상태는 API 통화, 백그라운드 저장 또는 가시 콘텐츠를 제공하지 않는 기타 작업에 가장 적합합니다.색인 및 표시 해야하는 페이지 및 리소스의 경우 전체 컨텐츠가 포함 된 200과 같은 표준 성공 코드를 사용하십시오.
때때로 구성 오류 또는 버그로 인해 페이지가 실수로 204를 반환합니다.검색 엔진 트래픽 손실을 방지하기 위해 중요한 URL에 대한 예상치 못한 204 개의 응답을 정기적으로 확인하십시오.
예 : 귀하의/About Page가 컨텐츠가있는 200 대신 204를 반환하면 Google이 인덱싱을 건너 뜁니다.
204 No Content Status Code 자체는 Magic에 의해 사이트 속도를 높이지는 않지만 신중하게 사용하여 불필요한 데이터 전송 및 처리를 줄일 수 있습니다.이로 인해 사용자, 특히 연결이 느려지거나 리소스가 제한된 장치에 대한 경험이 더 큽니다.
204 응답에는 신체가 포함되어 있지 않기 때문에 헤더 만 클라이언트로 다시 보냅니다.이는 전체 HTML 페이지 또는 JSON 응답에 비해 네트워크를 통한 데이터 여행이 적습니다.더 작은 응답은 대역폭을 절약하고 로딩 시간을 줄일 수 있으며, 이는 모바일 네트워크의 사용자 또는 인터넷 속도가 느린 경우 가장 중요합니다.
추가 컨텐츠를 보내지 않고 성공을 확인함으로써 204 개의 응답을 통해 앱은 배경 작업을 조용하고 빠르게 처리 할 수 있습니다.예를 들어 자동 절약 설정 또는 삭제 확인 삭제는 사용자 인터페이스를 방해하지 않으므로 앱이보다 반응이 좋고 매끄럽게 느껴질 수 있습니다.
브라우저 나 앱이 204를 수신하면 컨텐츠를 구문 분석하거나 렌더링 할 필요가 없으므로 클라이언트의 워크로드가 낮아집니다.이를 통해 다른 작업에 대한 리소스를 해방시켜 전반적인 성능 및 사용자 경험, 특히 저전력 장치에서는 개선됩니다.
204를 사용하면 전략적으로 서버와 네트워크가 불필요한 데이터를 보내지 않도록 도와줍니다.이렇게하면 서버로드를 낮추고 트래픽을 줄일 수 있으므로 많은 사용자 또는 빈번한 백그라운드 요청을 처리 할 때 응용 프로그램을 쉽게 확장 할 수 있습니다.
204 No Content Code에는 사용자에게 예기치 않은 문제를 피하거나 사이트/앱 기능을 중단하기 위해 따라야하는 특정 규칙 및 동작이 있습니다.이러한 일반적인 함정을 아는 것은 사용자와 지원 시스템 모두에서 구현이 매끄럽고 예측 가능하도록하는 데 도움이됩니다.
HTTP 사양은 분명히 204 응답에 응답 본문이 포함되어서는 안됩니다.이는 HTML, JSON 또는 기타 컨텐츠 가이 상태 코드와 함께 제공되지 않음을 의미합니다.신체를 포함하면 콘텐츠를 기대하지 않는 브라우저와 클라이언트를 혼동 할 수 있습니다.일부 고객은 신체를 무시할 수 있지만 다른 고객은 예측할 수 없을 정도로 행동 할 수 있습니다.
실수 예 :
서버는 204 상태의 배경 요청에 응답하지만 실수로 { "status": "Ok"}과 같은 작은 JSON 메시지가 포함됩니다.이로 인해 클라이언트가 응답을 올바르게 처리하는 데 실패 할 수 있습니다.
모범 사례 :
서버는 항상 메시지 본문이 아닌 204 응답으로 헤더 만 보내도록하십시오.
사용자가 웹 페이지를 기대하는 URL을 방문하면 204로 응답하면 완전히 빈 페이지가 표시됩니다. 오류가없고 콘텐츠가없고 빈 공간 만 표시됩니다.이를 통해 사용자를 혼란스럽게하고 사용자 경험이 좋지 않으며 검색 엔진이 페이지 인덱싱을 건너 뛸 수 있습니다.
실수 예 :
"미국 정보"페이지는 HTML 컨텐츠로 200 대신 204를 실수로 반환하므로 방문자는 빈 화면을보고 검색 엔진이 페이지를 색인화하지 않습니다.
모범 사례 :
컨텐츠를 표시하려는 모든 페이지에는 200 확인을 사용하십시오.배경 API 호출 또는 눈에 보이는 피드백이 필요하지 않은 작업에 대해 204를 예약하십시오.
때때로 개발자는 오류 상태를 다루지 않기 위해 작업이 성공하지 못하더라도 204 응답을 보낼 수도 있습니다.이것은 클라이언트의 문제를 숨기고 혼란이나 데이터 손실로 이어질 수 있습니다.
실수 예 :
API는 유효하지 않은 입력을받지 만 204로 응답하여 클라이언트가 실제로 실패했을 때 요청이 성공했다고 믿습니다.
모범 사례 :
유효성 검사 문제에 대해서는 400 불량 요청 또는 422 개의 처리 할 수없는 엔티티와 같은 적절한 오류 코드와 서버 문제에 대해 500 개의 내부 서버 오류를 사용하십시오.작전이 실제로 성공하고 반환 할 내용이 없을 때 204를 보내십시오.
204 개의 응답에는 신체가 포함되어 있지 않기 때문에 데이터를 업데이트 할 수있는 클라이언트 응용 프로그램은 제대로 처리하지 않고 204를받을 경우 예기치 않게 잠시 또는 작동 할 수 있습니다.
실수 예 :
프론트 엔드 스크립트는 저장 작업 후 JSON 데이터를 기대하지만 서버는 204를 반환합니다. 스크립트가 204를 확인하지 않으면 실패하거나 오래된 데이터를 표시 할 수 있습니다.
모범 사례 :
클라이언트 측 코드를 설계하여 204 개의 응답을 우아하게 처리 (데이터없이 성공 신호로 트리트하고 그에 따라 UI를 업데이트하십시오.
HTTP 응답 코드는 리디렉션 또는 캐시 컨트롤과 같은 다른 헤더와 일치해야합니다.예를 들어, 리디렉션 상태 또는 충돌하는 캐시 지침과 함께 204를 보내면 정의되지 않은 동작이 발생할 수 있습니다.
실수 예 :
클라이언트를 리디렉션하기 위해 위치 헤더로 204를 반환합니다.리디렉션에는 3xx 상태 코드가 필요합니다.
모범 사례 :
204 개의 응답을 간단하고 상충되는 헤더가 없도록 유지하십시오.리디렉션이 필요한 경우 301 또는 302와 같은 적절한 리디렉션 상태 코드를 사용하십시오.
HTTP Status 204는 컨텐츠를 다시 보내지 않고도 성공을 알리는 깨끗하고 효율적인 방법을 제공하는 재미있는 작은 코드입니다.배경 작업을 조용하고 효율적으로 확인하여 앱의 반응을 유지합니다.
적절하게 사용하면 사이트 나 앱이 빠르고 매끄럽게 유지하는 데 도움이됩니다.컨텐츠를 표시하거나 검색 엔진에서 색인화 해야하는 페이지에서 사용하지 마십시오.
작성자 Hostwinds Team / 유월 11, 2025