상태 코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx (Informational): 요청이 수신되어 처리 중
- 2xx (Successful): 클라이언트의 요청을 성공적으로 정상 처리
- 3xx (Redirection): 요청을 완료하기 위해 유저 에이전트의 추가 행동(조치)이 필요
- 4xx (Client Error): 클라이언트 오류. 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
- 5xx (Server Error): 서버 오류. 서버가 정상 요청을 처리하지 못함
1xx (Informational)
거의 사용하지 않는 상태 코드이다.
2xx (Successful)
200 OK
요청 성공
201 Created
요청이 성공해서 새로운 리소스가 생성됨
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
배치 처리 같은 곳에서 사용한다. 예시로 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우가 있다.
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
웹 문서 편집기의 save 버튼을 예시로 들 수 있다. save 버튼을 클릭했을 때 결과로 아무 내용이 없어도 되며, 같은 화면을 유지해야 한다. 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.
3xx (Redirection)
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있는 경우 Location 위치로 자동 이동하는데 이를 리다이렉트라고 한다.
URL이 /event인 페이지가 있었는데, 해당 URL이 /new-event로 변경되었을 때의 경우를 예시로 들어 설명한다.
1. 요청: GET /event HTTP/1.1 Host: localhost:8080
2. 응답: HTTP/1.1 301 Moved Permanently Location: /new-event
3. 자동 리다이렉트
4. 요청: GET /new-event HTTP/1.1 Host: localhost:8080
5. 응답: HTTP/1.1 200 OK ...
1. 요청 단계에서 /event 페이지로 접속한다.
2. 응답 단계에서 /new-evnet를 Location에 넣어주고, 301을 상태 코드로 설정하여 응답한다. 이제 /event를 사용하지 않고 /new-event를 사용하기로 하였으니, /new-event 페이지로 자동 리다이렉트되게끔 알려주는 것이다.
3. /new-event 페이지로 자동 리다이렉트한다.
4. 요청 단계에서 /new-event 페이지로 접속한다.
5. 응답 단계에서 정상 응답한다.
영구 리다이렉션 (301, 308): 특정 리소스의 URI가 영구적으로 이동
위 예시인 /event에서 /new-event로 URI가 변경되는 것처럼 원래의 URL을 사용하지 않는 경우에 사용하는 상태코드이다. 영구적으로 변경된 것이므로 검색 엔진에서도 변경된 URL을 사용해야 한다.
보통 영구 리다이렉션보다 일시 리다이렉션을 많이 사용한다.
301 Moved Permanently
리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다(보통 제거된다).
1. 요청
POST /event HTTP 1.1
Host: localhost:8080
name=hello&age=20
클라이언트가 /event 페이지로 진입한다. POST 메서드를 사용하였고, name=hello&age=20라는 내용의 메시지도 존재한다.
2. 응답
HTTP/1.1 301 Moved Permanently
Location: /new-event
더 이상 /event URL을 사용하지 않고 /new-event URL을 사용하므로 /new-event 페이지로 리다이렉트 될 수 있도록 Location 값을 넣어 301로 응답한다.
3. 자동 리다이렉트
4. 요청
GET /new-event HTTP/1.1
Host: localhost:8080
[3. 자동 리다이렉트] 후 클라이언트가 /new-event 페이지를 다시 [4. 요청]한다. 이때 [1. 요청]과는 다르게 GET으로 변경되었고, 메시지도 제거되었다.
이러한 경우 기존에 작성하였던 내용(name 값과 age 값)이 제거된 상태의 깨끗한 첫 이벤트 페이지가 나오게 될 것이다. 클라이언트가 등록하려고 했던 내용을 다시 입력해야 한다.
308 Permanent Redirect
301과 기능은 같으나 리다이렉트 시 요청 메서드와 본문을 유지한다. 처음에 POST를 보내면 리다이렉트도 POST로 보낸다.
1. 요청: POST /event HTTP/1.1 Host: localhost:8080 name=hello&age=20
2. 응답: HTTP/1.1 308 Moved Permanently Location: /new-event
3. 자동 리다이렉트
4. 요청: POST /new-event HTTP/1.1 Host: localhost:8080 name=hello&age=20
5. 응답: HTTP/1.1 200 OK ...
[2. 응답]을 301이 아닌 308 코드로 응답하여서 [4. 요청] 시 [1. 요청]과 동일하게 POST 메서드를 사용하고 메시지 값도 보존된 상태로 요청된다.
하지만 보통 308 상태 코드는 사용되지 않는다. 대게 페이지가 변경된 경우에는 필요한 요청 정보도 달라지기 때문이다. /event 페이지에서는 name과 age만 요구했다면, /new-event 페이지에서는 이와 다르게 name, age, phone 정보까지 요구할 수도 있다. 이러한 상황에선 요청에 필요한 정보가 달라지게 되므로 308 코드를 사용하면 안 될 것이다.
일시 리다이렉션 (302, 307, 303): 일시적인 변경
주문 완료 후 주문 내역 화면으로 이동하는 경우를 예로 들 수 있다.
리소스의 URI가 일시적으로 변경되는 경우로, 검색 엔진 등에서 URL을 변경하면 안 된다.
PRG: Post/Redirect/Get
일시적인 리다이렉션의 예시이다.
POST를 사용하여 주문 한 뒤 웹 브라우저를 새로고침하는 경우, 새로고침을 할 때 다시 요청이 된다. 이때 이전과 같이 POST로 다시 요청하면 중복 주문이 될 수 있으므로 이를 방지하기 위함이다.
PRG 사용 전과 사용 후를 예시로 들어 설명한다.
PRG 사용 전 (URL: /order)
1. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
2. 주문 데이터 저장 (mouse 1개)
3. 응답: HTTP/1.1 200 OK <html>주문완료</html>
4. 결과 화면에서 새로고침
5. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
6. 주문 데이터 저장 (mouse 1개)
7. 응답: HTTP/1.1 200 OK <html>주문완료</html>
1~3번부터 5~7번의 동작이 동일하게 수행된다.
[4. 결과 화면에서 새로고침]을 하게 되면 마지막에 시도한 요청을 다시 요청한다. 따라서 마지막 요청인 [1. 요청]부터 다시 요청하게 되어 중복 주문이 들어가게 된다.
위와 같은 POST로 주문 후 새로고침으로 인한 중복 주문을 막기 위해 일시 리다이렉션을 사용할 수 있다. POST로 주문이 완료되면 주문 결과 화면으로 GET 메서드를 사용해 리다이렉트 시키면 된다.
1. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
2. 주문 데이터 저장 (mouse 1개)
3. 응답: HTTP/1.1 302 Found Location: /order-result/19
4. 자동 리다이렉트
5. 요청: GET /order-result/19 HTTP/1.1 Host: localhost:8080
6. 주문데이터 조회 19번 주문
7. HTTP/1.1 200 OK <html>주문완료</html>
8. 결과 화면에서 새로고침 -> 마지막 요청인 [5. 요청]을 다시 요청하여 결과 화면이 나옴
1~2번 과정은 같으나, [3. 응답] 과정에서 서버가 302 코드를 반환하며 Location 정보를 준다.
302 코드 값으로 응답이 왔으므로 자동 리다이렉트 할 것이다. 클라이언트는 Location에 담긴 페이지를 GET 메서드를 사용해 다시 [4. 요청]한다. 리다이렉트 후 요청되는 페이지는 주문 결과 페이지이므로 오로지 주문 데이터만 조회한다.
이미 리다이렉트 된 결과 페이지에서 클라이언트가 새로고침을 한다고 해도 조회 기능만 수행하는 주문 결과 페이지만 다시 뜨게 될 것이다. PRG 사용 전처럼 주문이 중복으로 요청되는 문제점이 없어진다.
302 Found
리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다(보통 제거된다).
307 Temporary Redirect
302와 기능은 같으나, 리다이렉트 시 요청 메서드와 본문을 유지한다(요청 메서드를 변경하면 안 된다).
303 See Other
302와 기능은 같다. 리다이렉트 시 요청 메서드가 GET으로 변경된다.
처음 302 코드 스펙 의도는 HTTP 메서드를 유지하는 것이었으나 대부분의 웹 브라우저들이 유지하지 않고 GET 메서드로 바꾼다. 그래서 모호한 302를 대신하는 명확한 307, 303 코드가 등장하게 되었다.
307, 303 코드를 권장하나 이미 많은 애플리케이션 라이브러리가 302를 기본 값으로 사용하고 있다. 따라서 자동 리다이렉션 시 GET 메서드로 변해도 된다면 302 코드를 사용해도 된다.
기타 리다이렉션
300 Multiple Choices
사용하지 않음
304 Not Modified
많이 사용된다. 캐시를 목적으로 사용된다. 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
클라이언트가 서버에게 캐시가 만료된 것 같으니 다시 캐시를 요청한다. 캐시가 만료되지 않은 경우 서버가 클라이언트에게 캐시 만료되지 않았으니 그대로 해당 캐시를 사용하라고 304 응답을 보내 캐시로 리다이렉트 시킨다. 이때 304 응답에 메시지 바디를 포함하면 안 된다. 서버와는 상관없이 클라이언트의 로컬 캐시를 사용해야 하기 때문이다.
조건부 GET, HEAD 요청 시에 사용한다.
4xx (Client Error)
오류의 원인이 클라이언트에 있음
클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없을 때이다. 클라이언트가 이미 잘못된 요청이나 데이터를 보내고 있으므로 재시도하는 경우에도 똑같이 실패한다.
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
요청 구문, 메시지 등에서 오류가 존재할 때이다. 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때를 예시로 들 수 있다. 이때 클라이언트는 요청 내용을 다시 검토하여 요청해야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요함
인증(Authentication)되지 않았을 때를 의미한다(오류 메시지가 Unauthorized이지만 인증되지 않음을 뜻함). 401 오류 발생 시에는 응답에서 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야 한다.
- 인증(Authentication): 본인이 누구인지 확인 (ex. 로그인)
- 인가(Authorization): 권한 부여 (관리자 권한처럼 특정 리소스에 접근할 수 있는 권한. 인증이 있어야 인가 존재 가능)
403 Forbidden
서버가 요청을 이해했지만 승인을 거부함
인증 자격은 있지만 접근 권한이 불충분한 경우이다. 위에서 설명한 인가가 되지 않았을 때이다. 관리자 등급이 아닌 사용자가 로그인 후 관리자 등급의 리소스에 접근하는 경우에 발생한다.
404 Not Found
요청 리소스를 찾을 수 없음
클라이언트가 요청한 리소스 자체가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 사용한다.
5xx (Server Error)
서버 문제로 오류가 발생하는 경우
서버에 문제가 있는 것이므로 재시도하면 성공할 수도 있다(서버가 복구되는 경우). 웬만하면 서버에서는 5xx 에러를 발생시키면 안 된다. 진짜 Exception이나 쿼리 오류 같은 문제가 발생했을 때만 사용해야 한다.
500 Internal Server Error
서버 내부 문제로 발생하는 오류로, 애매하면 거의 다 500 오류로 응답한다.
503 Service Unavailable
서비스 이용 불가
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때이다. Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있다.
[인프런] 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한
상태 코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx (Informational): 요청이 수신되어 처리 중
- 2xx (Successful): 클라이언트의 요청을 성공적으로 정상 처리
- 3xx (Redirection): 요청을 완료하기 위해 유저 에이전트의 추가 행동(조치)이 필요
- 4xx (Client Error): 클라이언트 오류. 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
- 5xx (Server Error): 서버 오류. 서버가 정상 요청을 처리하지 못함
1xx (Informational)
거의 사용하지 않는 상태 코드이다.
2xx (Successful)
200 OK
요청 성공
201 Created
요청이 성공해서 새로운 리소스가 생성됨
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
배치 처리 같은 곳에서 사용한다. 예시로 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우가 있다.
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
웹 문서 편집기의 save 버튼을 예시로 들 수 있다. save 버튼을 클릭했을 때 결과로 아무 내용이 없어도 되며, 같은 화면을 유지해야 한다. 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.
3xx (Redirection)
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있는 경우 Location 위치로 자동 이동하는데 이를 리다이렉트라고 한다.
URL이 /event인 페이지가 있었는데, 해당 URL이 /new-event로 변경되었을 때의 경우를 예시로 들어 설명한다.
1. 요청: GET /event HTTP/1.1 Host: localhost:8080
2. 응답: HTTP/1.1 301 Moved Permanently Location: /new-event
3. 자동 리다이렉트
4. 요청: GET /new-event HTTP/1.1 Host: localhost:8080
5. 응답: HTTP/1.1 200 OK ...
1. 요청 단계에서 /event 페이지로 접속한다.
2. 응답 단계에서 /new-evnet를 Location에 넣어주고, 301을 상태 코드로 설정하여 응답한다. 이제 /event를 사용하지 않고 /new-event를 사용하기로 하였으니, /new-event 페이지로 자동 리다이렉트되게끔 알려주는 것이다.
3. /new-event 페이지로 자동 리다이렉트한다.
4. 요청 단계에서 /new-event 페이지로 접속한다.
5. 응답 단계에서 정상 응답한다.
영구 리다이렉션 (301, 308): 특정 리소스의 URI가 영구적으로 이동
위 예시인 /event에서 /new-event로 URI가 변경되는 것처럼 원래의 URL을 사용하지 않는 경우에 사용하는 상태코드이다. 영구적으로 변경된 것이므로 검색 엔진에서도 변경된 URL을 사용해야 한다.
보통 영구 리다이렉션보다 일시 리다이렉션을 많이 사용한다.
301 Moved Permanently
리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다(보통 제거된다).
1. 요청
POST /event HTTP 1.1
Host: localhost:8080
name=hello&age=20
클라이언트가 /event 페이지로 진입한다. POST 메서드를 사용하였고, name=hello&age=20라는 내용의 메시지도 존재한다.
2. 응답
HTTP/1.1 301 Moved Permanently
Location: /new-event
더 이상 /event URL을 사용하지 않고 /new-event URL을 사용하므로 /new-event 페이지로 리다이렉트 될 수 있도록 Location 값을 넣어 301로 응답한다.
3. 자동 리다이렉트
4. 요청
GET /new-event HTTP/1.1
Host: localhost:8080
[3. 자동 리다이렉트] 후 클라이언트가 /new-event 페이지를 다시 [4. 요청]한다. 이때 [1. 요청]과는 다르게 GET으로 변경되었고, 메시지도 제거되었다.
이러한 경우 기존에 작성하였던 내용(name 값과 age 값)이 제거된 상태의 깨끗한 첫 이벤트 페이지가 나오게 될 것이다. 클라이언트가 등록하려고 했던 내용을 다시 입력해야 한다.
308 Permanent Redirect
301과 기능은 같으나 리다이렉트 시 요청 메서드와 본문을 유지한다. 처음에 POST를 보내면 리다이렉트도 POST로 보낸다.
1. 요청: POST /event HTTP/1.1 Host: localhost:8080 name=hello&age=20
2. 응답: HTTP/1.1 308 Moved Permanently Location: /new-event
3. 자동 리다이렉트
4. 요청: POST /new-event HTTP/1.1 Host: localhost:8080 name=hello&age=20
5. 응답: HTTP/1.1 200 OK ...
[2. 응답]을 301이 아닌 308 코드로 응답하여서 [4. 요청] 시 [1. 요청]과 동일하게 POST 메서드를 사용하고 메시지 값도 보존된 상태로 요청된다.
하지만 보통 308 상태 코드는 사용되지 않는다. 대게 페이지가 변경된 경우에는 필요한 요청 정보도 달라지기 때문이다. /event 페이지에서는 name과 age만 요구했다면, /new-event 페이지에서는 이와 다르게 name, age, phone 정보까지 요구할 수도 있다. 이러한 상황에선 요청에 필요한 정보가 달라지게 되므로 308 코드를 사용하면 안 될 것이다.
일시 리다이렉션 (302, 307, 303): 일시적인 변경
주문 완료 후 주문 내역 화면으로 이동하는 경우를 예로 들 수 있다.
리소스의 URI가 일시적으로 변경되는 경우로, 검색 엔진 등에서 URL을 변경하면 안 된다.
PRG: Post/Redirect/Get
일시적인 리다이렉션의 예시이다.
POST를 사용하여 주문 한 뒤 웹 브라우저를 새로고침하는 경우, 새로고침을 할 때 다시 요청이 된다. 이때 이전과 같이 POST로 다시 요청하면 중복 주문이 될 수 있으므로 이를 방지하기 위함이다.
PRG 사용 전과 사용 후를 예시로 들어 설명한다.
PRG 사용 전 (URL: /order)
1. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
2. 주문 데이터 저장 (mouse 1개)
3. 응답: HTTP/1.1 200 OK <html>주문완료</html>
4. 결과 화면에서 새로고침
5. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
6. 주문 데이터 저장 (mouse 1개)
7. 응답: HTTP/1.1 200 OK <html>주문완료</html>
1~3번부터 5~7번의 동작이 동일하게 수행된다.
[4. 결과 화면에서 새로고침]을 하게 되면 마지막에 시도한 요청을 다시 요청한다. 따라서 마지막 요청인 [1. 요청]부터 다시 요청하게 되어 중복 주문이 들어가게 된다.
위와 같은 POST로 주문 후 새로고침으로 인한 중복 주문을 막기 위해 일시 리다이렉션을 사용할 수 있다. POST로 주문이 완료되면 주문 결과 화면으로 GET 메서드를 사용해 리다이렉트 시키면 된다.
1. 요청: POST /order HTTP/1.1 Host: localhost:8080 itemId=mouse&count=1
2. 주문 데이터 저장 (mouse 1개)
3. 응답: HTTP/1.1 302 Found Location: /order-result/19
4. 자동 리다이렉트
5. 요청: GET /order-result/19 HTTP/1.1 Host: localhost:8080
6. 주문데이터 조회 19번 주문
7. HTTP/1.1 200 OK <html>주문완료</html>
8. 결과 화면에서 새로고침 -> 마지막 요청인 [5. 요청]을 다시 요청하여 결과 화면이 나옴
1~2번 과정은 같으나, [3. 응답] 과정에서 서버가 302 코드를 반환하며 Location 정보를 준다.
302 코드 값으로 응답이 왔으므로 자동 리다이렉트 할 것이다. 클라이언트는 Location에 담긴 페이지를 GET 메서드를 사용해 다시 [4. 요청]한다. 리다이렉트 후 요청되는 페이지는 주문 결과 페이지이므로 오로지 주문 데이터만 조회한다.
이미 리다이렉트 된 결과 페이지에서 클라이언트가 새로고침을 한다고 해도 조회 기능만 수행하는 주문 결과 페이지만 다시 뜨게 될 것이다. PRG 사용 전처럼 주문이 중복으로 요청되는 문제점이 없어진다.
302 Found
리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다(보통 제거된다).
307 Temporary Redirect
302와 기능은 같으나, 리다이렉트 시 요청 메서드와 본문을 유지한다(요청 메서드를 변경하면 안 된다).
303 See Other
302와 기능은 같다. 리다이렉트 시 요청 메서드가 GET으로 변경된다.
처음 302 코드 스펙 의도는 HTTP 메서드를 유지하는 것이었으나 대부분의 웹 브라우저들이 유지하지 않고 GET 메서드로 바꾼다. 그래서 모호한 302를 대신하는 명확한 307, 303 코드가 등장하게 되었다.
307, 303 코드를 권장하나 이미 많은 애플리케이션 라이브러리가 302를 기본 값으로 사용하고 있다. 따라서 자동 리다이렉션 시 GET 메서드로 변해도 된다면 302 코드를 사용해도 된다.
기타 리다이렉션
300 Multiple Choices
사용하지 않음
304 Not Modified
많이 사용된다. 캐시를 목적으로 사용된다. 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
클라이언트가 서버에게 캐시가 만료된 것 같으니 다시 캐시를 요청한다. 캐시가 만료되지 않은 경우 서버가 클라이언트에게 캐시 만료되지 않았으니 그대로 해당 캐시를 사용하라고 304 응답을 보내 캐시로 리다이렉트 시킨다. 이때 304 응답에 메시지 바디를 포함하면 안 된다. 서버와는 상관없이 클라이언트의 로컬 캐시를 사용해야 하기 때문이다.
조건부 GET, HEAD 요청 시에 사용한다.
4xx (Client Error)
오류의 원인이 클라이언트에 있음
클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없을 때이다. 클라이언트가 이미 잘못된 요청이나 데이터를 보내고 있으므로 재시도하는 경우에도 똑같이 실패한다.
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
요청 구문, 메시지 등에서 오류가 존재할 때이다. 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때를 예시로 들 수 있다. 이때 클라이언트는 요청 내용을 다시 검토하여 요청해야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요함
인증(Authentication)되지 않았을 때를 의미한다(오류 메시지가 Unauthorized이지만 인증되지 않음을 뜻함). 401 오류 발생 시에는 응답에서 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야 한다.
- 인증(Authentication): 본인이 누구인지 확인 (ex. 로그인)
- 인가(Authorization): 권한 부여 (관리자 권한처럼 특정 리소스에 접근할 수 있는 권한. 인증이 있어야 인가 존재 가능)
403 Forbidden
서버가 요청을 이해했지만 승인을 거부함
인증 자격은 있지만 접근 권한이 불충분한 경우이다. 위에서 설명한 인가가 되지 않았을 때이다. 관리자 등급이 아닌 사용자가 로그인 후 관리자 등급의 리소스에 접근하는 경우에 발생한다.
404 Not Found
요청 리소스를 찾을 수 없음
클라이언트가 요청한 리소스 자체가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 사용한다.
5xx (Server Error)
서버 문제로 오류가 발생하는 경우
서버에 문제가 있는 것이므로 재시도하면 성공할 수도 있다(서버가 복구되는 경우). 웬만하면 서버에서는 5xx 에러를 발생시키면 안 된다. 진짜 Exception이나 쿼리 오류 같은 문제가 발생했을 때만 사용해야 한다.
500 Internal Server Error
서버 내부 문제로 발생하는 오류로, 애매하면 거의 다 500 오류로 응답한다.
503 Service Unavailable
서비스 이용 불가
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때이다. Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있다.
[인프런] 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한
