HTTP 상태코드 정리

HTTP의 응답 코드는 5개의 클래스(분류)로 구분된다.

첫 번째 숫자로 응답 클래스가 결정된다.

• 1xx (정보, Information) : 요청을 받고, 프로세스를 계속한다.
• 2xx (성공, Successful) : 요청을 성공적으로 받고, 정상적으로 처리했다.
• 3xx (리다이렉션, Redirection) : 요청을 완료하기 위해 추가 작업 조치가 필요하다.
• 4xx (클라이언트 오류, Client Error) : 요청의 잘못된 문법 등으로 처리할 수 없다.
• 5xx (서버 오류, Server Error) : 서버가 정상 요청을 처리하지 못했다.

 

[ 1xx (조건부 응답) ]

요청을 받았으며 작업을 계속한다.

• 실무에서 잘 사용하지 않는다.

 

[ 2xx (성공) ]

클라이언트가 요청한 동작을 수신하여 이해했고, 성공적으로 처리를 한 것이다.

 

• 200 OK : 요청 성공

 

200 OK

• 201 Created : 성공적으로 요청되었고, 서버가 새로운 리소스를 작성한다.

 

POST(포스트) 요청이 성공한 경우에 서버에서 Location을 만든다.

 

• 202 Accepted : 서버가 요청을 접수했지만, 아직 처리하지 않았다.

배치 처리 같은 곳에서 사용한다.

 

• 204 No Content : 서버가 요청을 성공적으로 처리했지만, 응답 페이로드 본문에 보낼 데이터가 없다.

중간중간 저장할 때 사용한다.
결과 내용이 없지만 204 메시지를 확인하면 저장에 성공했다는 것을 알 수 있다.

 

[ 3xx (리다이렉션) ]

요청을 완료하기 위해 유저 에어전트의 추가조치가 필요하다.

 

 

➕ 리다이렉트 : 웹 브라우저는 3xx응답의 결과에 Location헤더가 있으면, Location 위치로 자동 이동한다.

 

📁 리다이렉션 종류

• 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
• 일시 리다이렉션 : 일시적으로 변경

주문 완료 후 주문 내역 화면으로 이동
PRG (Post / Redirect / Get) 

• 특수 리다이렉션 : ex ) 결과 대신 캐시를 사용

 

💚 영구 리다이렉션 (301, 308 존재) 💚

• 리소스의 URI가 영구적으로 이동
• 원래의 URL을 사용하지 않는다. 검색 엔진에서도 변경을 인지한다.
• 301 Moved Permanently

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수도 있다.

• 308 Permanent Redirect

실질적으로 잘 사용하지는 않는다.
301과 기능이 같다.
리다이렉트시 요청 메서드와 본문 유지 (처음 POST를 보내면 리다이렉트도 POST를 유지한다.)

 

💚 일시적인 리다이렉션 (302, 307, 303 존재) 💚

• 리소스의 URI가 일시적으로 변경된다.
• 검색 엔진 등에서 URL을 변경하면 안된다.
• 302 Found

리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있다. 
거의 대부분 GET으로 변경된다.
명확하지는 않은 방법이지만, 실무에서는 자주 사용하고 있다. 
자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 괜찮다.

• 307 Temporary Redirect

302와 기능이 같다.
리다이레트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다.)

• 303 See Other

302와 기능이 같다.
리다이렉트 요청 메서드가 GET으로 변경된다.

 

✍ PRG (Post/Redirect/Get)

• POST로 주문 후에 새로 고침을 하게 되면 중복 주문이 되는데, 이것을 방지하는 것이다.
• POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트한다.
• 새로고침해도 결과화면을 GET으로 조회한다.
• 새로고침 할 경우에 중복 주문 대신에 결과 화면만 GET으로 다시 요청 (GET은 읽기만 가능하므로)

 

 

❌ PRG 사용 전

이렇게 PRG를 사용하지 않으면 새로고침했을 때, POST로 같은 요청을 하기 때문에 중복 주문이 될 수 있다.

 

 

⭕ PRG사용 했을 때

PRG를 사용하게 되면 새로고침을 여러번 해도 GET으로 결과화면만 보여주기 때문에 중복 주문을 방지할 수 있다.

 

 

💚 기타 리다이렉션(300, 304 존재) 💚

300 Multiple Choices 는 잘 사용하지 않는다.

 

304 Not Modified 

• 캐시를 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.
• 304응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야하기 때문에)
• 조건부 GET, HEAD 요청시 사용

 

[ 4xx 클라이언트 오류 ]

• 클라이언트 요청에 잘못된 문법으로 서버가 요청을 수행할 수 없다.
• 오류의 원인이 클라이언트에 있다.
• 클라이언트에게 오류가 있기 때문에 다시 요청해도 실패한다. ( 5xx오류와 가장 다른 점. 5xx오류는 서버가 복구되면 성공할 가능성이 있다.)

 

💙 400 Bad Request 💙

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다.

• 요청 구문, 메시지 오류...
• 클라이언트는 요청 내용을 다시 검토하고 보내야한다.
• ex) 요청 파라미터가 맞지 않을 때(예를 들어 숫자를 보내야하는데 문자를 보냈을 때), API 스펙이 맞지 않을 때. 

 

💙 401 Unauthorized 💙

인증되지 않음(로그인되지 않음)

 

 

💙 403 Forbidden 💙

서버가 요청을 이해했지만 승인을 거부한다.

인증자격은 있지만, 접근 권한이 불충분한 경우. ( ex. 회원이 관리자의 글에 접근을 할 수 없다)

 

 

💙 404 Not Found 💙

요청 리소스를 서버에 없는 경우나 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때

 

 

[ 5xx 서버 오류 ]

• 서버 문제로 오류 발생
• 서버에 문제가 있기 때문에 서버를 복구됐을 때 재시도하면 성공할 수도 있다.
• 웬만에서는 5xx오류를 발생시키면 안된다.

 

💜 500 Internal Server Error 💜

• 서버 내부 문제로 오류 발생
• 애매하면 500오류이다.

 

💜 503 Service Unavailable 💜

• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없다.
• Retry-After 헤더 필드로 얼마뒤 복구되는지 보낼 수 있다.
• 하지만 실무에서 거의 보는 경우가 없다.

 

---

출처 : HTTP 상태코드-위키백과

 

이 글은 인프런 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 듣고 작성된 복습 포스팅입니다.