204 No Content

할 말이 없을 때 뭐라고 하나요?

아무 말도 하지 않는 거죠. 그게 204입니다.

204 No Content 상태 코드는 응답 본문 없이 성공을 나타냅니다. 서버가 요청을 완전히 처리했고, 요청한 작업을 완수했으며, 돌려보낼 내용이 없다는 뜻입니다. 이상하게 느껴질 수도 있습니다—보여줄 것도 없이 성공이라니?—하지만 204는 종종 가장 솔직한 응답입니다.

침묵의 형태

204 응답은 놀랍도록 간결합니다:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

Content-Type도 없습니다. Content-Length도 없습니다. 본문도 없습니다. 헤더가 끝나면 그게 전부입니다. 응답은 완료된 겁니다.

이것은 우연한 비어있음이 아닙니다. 의도된 설계입니다.

침묵이 올바른 답인 경우

무언가를 삭제할 때

204의 가장 자연스러운 사용 사례:

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

사용자가 삭제됐습니다. 무엇을 반환해야 할까요? 삭제된 사용자를? 그건 모순입니다—방금 존재하지 않는다고 했으니까요. 빈 객체를? 그건 아무 의미 없는 잡음입니다. 성공 메시지를? 그건 이미 상태 코드가 말하고 있습니다.

204가 유일하게 솔직한 답입니다: 일은 끝났고, 더 할 말이 없습니다.

확인 없이 처리하는 업데이트

리소스를 업데이트할 때 서버가 그 내용을 다시 돌려줄 필요가 없는 경우:

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{"name": "Alice Updated", "email": "alice@example.com"}

HTTP/1.1 204 No Content

서버에 새로운 상태를 알려줬습니다. 서버가 그것을 수락했습니다. 방금 전송한 내용을 왜 그대로 돌려주겠습니까? 업데이트를 확인하고 싶다면 GET 요청을 보내세요. 하지만 대부분은 자신이 보낸 메시지를 신뢰합니다.

결과물 없이 처리되는 작업들

어떤 작업은 출력이 아니라 효과를 만들어냅니다:

POST /api/cache/clear HTTP/1.1

HTTP/1.1 204 No Content

POST /api/users/123/reset-password HTTP/1.1

HTTP/1.1 204 No Content

캐시가 비워졌습니다. 비밀번호 재설정 이메일이 발송됐습니다. 성공입니다. 어떤 내용을 반환해야 할까요? 비밀번호를? 당연히 안 됩니다. 확인 메시지를? 상태 코드가 곧 확인입니다.

204와 이웃 코드들

200 OK: "요청하신 내용입니다." 반환할 내용이 있을 때 200을 사용하세요.

201 Created: "새로운 항목을 만들었고, 여기서 찾을 수 있습니다." 리소스를 생성할 때 201을 사용하세요.

202 Accepted: "나중에 처리하겠습니다." 처리가 나중으로 미뤄질 때 202를 사용하세요.

204 No Content: "완료됐습니다. 더 할 말이 없습니다." 작업이 성공했고 침묵이 적절한 응답일 때 204를 사용하세요.

200과 204의 차이는 효율성 측면에서 중요합니다. {"success": true}를 담은 200 응답은 바이트를 낭비합니다. 클라이언트는 상태 코드가 이미 알려준 것을 확인하려고 JSON을 파싱해야 합니다. 204는 그 낭비를 없앱니다—전송할 본문도, 파싱할 JSON도 없습니다.

본문 없음 규칙

204 응답에는 메시지 본문이 포함되어서는 안 됩니다. 이것은 권고사항이 아닙니다—명세입니다. 응답은 헤더 이후에 끝납니다:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

그 뒤에는 아무것도 없습니다. 204를 올바르게 처리하지 않는 일부 HTTP 라이브러리는 결코 도착하지 않을 내용을 기다리다 타임아웃이 발생할 수 있습니다. 이 비어있음은 의도적입니다.

포함하지 말아야 할 헤더:

• Content-Type: 내용이 없으면 콘텐츠 타입도 없습니다
• Content-Length: 생략하거나 0으로 설정하세요
• Transfer-Encoding: 인코딩할 것이 없습니다

포함할 수 있는 헤더:

• Date: 응답이 생성된 시각
• Cache-Control: 캐싱 지시자
• 사용자 정의 헤더: 요청 ID, 처리율 제한 등

브라우저가 204에 반응하는 방식

브라우저가 204를 받으면 흥미로운 일이 일어납니다: 아무 일도 일어나지 않습니다.

204를 반환하는 엔드포인트로 제출하는 폼은 페이지를 이동하지 않습니다. 페이지는 정확히 그 자리에 머물러 있습니다. 폼이 제출되고, 서버가 성공으로 응답하고, 브라우저는 그냥... 계속됩니다. 페이지 변화도 없습니다. 리다이렉트도 없습니다. 사용자는 아무 일도 일어나지 않았다고 생각할 수도 있습니다.

<form action="/api/update" method="POST">
    <input type="text" name="value">
    <button type="submit">Update</button>
</form>

/api/update가 204를 반환하면, 제출 버튼을 클릭해도 눈에 보이는 변화가 없습니다. 이것은 유용할 수도 있고(백그라운드 저장), 혼란스러울 수도 있습니다(사용자가 작동했는지 의아해하는 경우). 그에 맞게 설계하세요.

오류 없이 동작하는 클라이언트 코드

흔한 실수는 존재하지 않는 본문을 파싱하려 하는 것입니다:

// 이 코드는 실패합니다
const response = await fetch('/api/users/123', { method: 'DELETE' });
const data = await response.json(); // 오류! 파싱할 내용이 없습니다

파싱 전에 204를 확인하세요:

const response = await fetch('/api/users/123', { method: 'DELETE' });

if (response.status === 204) {
    // 성공, 파싱할 내용 없음
    return { success: true };
}

if (response.ok) {
    // 내용이 있는 성공
    return await response.json();
}

throw new Error(`Request failed: ${response.status}`);

또는 더 방어적으로:

async function request(url, options) {
    const response = await fetch(url, options);
    
    if (!response.ok) {
        throw new Error(`Request failed: ${response.status}`);
    }
    
    if (response.status === 204) {
        return null;
    }
    
    const contentType = response.headers.get('Content-Type');
    if (contentType?.includes('application/json')) {
        return await response.json();
    }
    
    return await response.text();
}

204를 사용하지 말아야 할 경우

클라이언트가 내용을 기대할 때: API 소비자가 업데이트된 리소스를 돌려받아야 한다면, 리소스와 함께 200을 반환하세요. 추측하거나 두 번 요청하게 만들지 마세요.

리소스를 생성할 때: 리소스 생성은 새 리소스의 위치(와 종종 그 내용)를 담은 201을 반환해야 합니다. 무언가를 생성하는 POST 후에 204를 반환하는 것은 혼란스럽습니다.

오류의 경우: 오류에는 절대 204를 사용하지 마세요. DELETE가 존재하지 않는 리소스를 대상으로 한다면 404를 반환하세요. 무언가 잘못됐다면 오류 본문과 함께 적절한 4xx 또는 5xx 코드를 반환하세요. 204는 성공을 의미합니다.

비움의 우아함

204는 하나의 원칙을 구현합니다: 필요 이상으로 말하지 마라.

작업이 성공했고 그 성공 외에 전달할 것이 진정으로 없을 때, 204가 완벽한 응답입니다. 대역폭을 절약합니다. 파싱을 절약합니다. 필요한 것만 정확히 말합니다—작업이 성공했다는 것—그 이상은 아무것도 말하지 않습니다.

다음에 API 엔드포인트를 설계하면서 무엇을 반환할지 고민할 때, 스스로에게 물어보세요: 실제로 할 말이 있나요? 대답이 '아니오'라면, 204가 당신의 답이기도 합니다.

204 No Content에 관한 자주 묻는 질문

DELETE는 204를 반환해야 할까요, 200을 반환해야 할까요?

204가 더 일반적이고 의미론적으로 올바른 선택입니다. 삭제 후에는 리소스가 더 이상 존재하지 않습니다—반환하는 것은 모순일 것입니다. 일부 API는 삭제에 관한 메타데이터와 함께 200을 반환하기도 하지만, 204가 더 깔끔합니다: 리소스는 사라졌고, 더 할 말이 없습니다.

204 응답에 실수로 본문을 포함시키면 어떻게 될까요?

대부분의 클라이언트는 무시하겠지만, HTTP 명세를 위반하는 것입니다. 일부 클라이언트는 예측할 수 없이 동작할 수 있습니다. 내용을 반환해야 한다면 대신 200을 사용하세요.

존재하지 않는 리소스를 삭제할 때 204와 404 중 무엇을 반환해야 할까요?

이것은 API의 철학에 따라 다릅니다. 일부 API는 멱등성을 위해 204를 반환합니다—"리소스가 존재하지 않는데, 그게 바로 원하는 상태입니다." 다른 API는 404를 반환합니다—"존재하지 않는 것을 삭제하려 했습니다." 선택을 명확하게 문서화하세요.

GET 요청에 204를 사용할 수 있나요?

기술적으로는 가능하지만, 드문 경우입니다. GET 요청은 일반적으로 내용을 기대합니다. GET에서의 204는 빈 컬렉션을 나타낼 수 있지만, 빈 배열([])을 담은 200이 보통 더 명확합니다.