[HTTP] 상태코드

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

---

HTTP 상태코드

상태코드

1xx (Informational) : 요청이 수신되어 처리중  ->  거의 사용이 되지 않음
2xx (Successful) : 요청 정상 처리
3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

HTTP 상태 코드는 클라이언트가 서버로 요청을 보내면 요청이 잘 처리가 되어있는지 문제가 있는지 요청의 처리 상태를 응답에서 알려주는 기능이다. 

 

만약 모르는 상태코드가 나타나면

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트는 상위 상태코드로 해석해서 처리하면 된다.

미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

299  -> 2xx (Successful)
451  ->  4xx (Client Error)
599  ->  5xx (Server Error)

 

100번대 - 정보

요청이 수신되어 처리 중이다. 거의 사용하지 않는다.

 

200번대 - 성공

200 OK 

1. 클라이언트가 서버에  GET으로 리소스를 요청함
2. 서버가 리소스를 조회함
3. Stauts code: 200 과 리소스를 HTTP 응답 메시지를 만들어 클라이언트에 보냄

 

201 Created

요청 성공 후 새로운 리소스 생성됨

1. 클라이언트가 서버에  POST로 신규 자원을 등록 요청함
2. 서버가 리소스를 생성하고 리소스의 URI를 관리함
3. Stauts code: 201, Location: 생성된 리소스의 URI 로 HTTP 응답 메시지를 만들어 클라이언트에 보냄

 

202 Accepted

요청이 접수되었으나 처리가 완료되지 않은 상태코드이다.

작업을 미뤄야할 때나 특수한 경우에 사용한다.

잘 사용하지 않는다. 

 

204 No Content

서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 데이터가 없는 상태코드이다.

말 그대로 요청을 받고 정상적으로 수행을 했는데 보내줄 값, 함수로 따지면 return 할 값이 없다는 의미이다.

 

300번대 - 리다이렉션

300 : Multiple Choices
301 : Moved Permanently
302 : Found
303 : See Other
304 : Not Modified
307 : Temporary Redirect
308 : Permanent Redirect

 

리다이렉션 이해

웹 브라우저는 300번대 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동으로 이동한다.

 

기존 /event 이벤트 페이지에서 /new-event 라는 페이지를 쓰기로 변경했다면 기존 경로를 북마크를 해둘 수 있고 기존의 링크가 여러 군데로 공유가 될 수 있다.

 

클라이언트가 /event 로 요청하면 서버 입장에서는 /event 를 더이상 쓰지 않으니까 /new-event 를 클라이언트에게 알려줄 때 301 상태코드로 알려준다.

 

 

클라이언트는 301 상태코드를 보고 /new-event 를 URL 서버에게 다시 요청을 한다.

 

정리를 하면, 기존의 경로로 요청을 하면 서버는 새로 만들어진 경로를 알려주게되고, 서버에게 받은 새로운 경로로 다시 요청을 하게 된다.

 

리다이렉션의 종류

1) 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동
-> 이벤트 페이지 URI가 바뀌어 더이상 사용하면 안되거나 내부적으로 URI 경로가 아예 바뀐 경우
- /members -> /users
- /event -> /new-event

2) 일시 리다이렉션: 일시적인 변경
- 주문 완료 후 주문 내역 화면으로 이동
- PRG: Post/Redirect/Get

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

 

영구 리다이렉션

영구 리다이렉션은 상태코드가 301, 308이 있다.

리소스의 URI가 영구적으로 이동했다는 것 알려준다. 원래의 URI를 더 이상 하면 안된다.

검색 엔진들이 원래의 URI로 들어올 수 있지만 검색 엔진에서도 변경을 인지한다. 

 

301 Moved Permanently

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

 

1. 클라이언트가 메세지 바디에 리소스를 담아 POST 방식으로 /event 를 서버에 요청하면
2. 서버는 메세지 바디를 제거하고 301 코드와 Location에 /new-event를 담아 응답한다.
3. 웹 브라우저의 URL이 자동 리다이렉트 되고
4. 클라이언트는 메시지를 제거하고 GET방식으로 /new-event 를 서버에 요청한다.
5. 서버는 200 코드와 /new-event 의 리소스를 응답한다.
6. 이벤트 페이지에서 회원 정보를 등록하려고 했으나, 메시지 바디가 제거된 채로 자동 리다이렉트 되어 입력한 정보가 날라가서 처음부터 회원 정보를 다시 입력해서 등록해야 한다.

이러한 불편함 때문에 308이 나왔다.

 

308 Permanet Redirect

리다이렉트시 요청 메서드와 본문 유지

• 클라이언트가 메세지 바디에 리소스를 담아 POST방식으로 /event 를 서버에 요청하면
• 서버는 메세지 바디를 제거하고 308 코드와 Location에 /new-event를 담아 응답한다.
• 웹 브라우저의 URL이 자동 리다이렉트 되고 클라이언트는 메시지를 유지해서 POST방식으로 /new-event 를 서버에 요청한다.
• 서버는 200 코드와 /new-event 의 리소스를 응답한다.
  -> 이벤트 페이지에서 회원 정보를 등록하면 자동 리다이렉트 되어 입력한 정보가 유지되어 회원 정보가 정상 등록된다.

 

실무에서는 308을 거의 사용하지 않는다고 한다.

만약 /event 에서 /new-event로 URI가 바뀌면 내부적으로 전달해야하는 데이터 자체가 바뀌기 때문에, POST로 요청을 받아도 리다이렉트시 GET으로 바꾼다고 한다.

 

일시적인 리다이렉션

리소스의 URI를 일시적으로 변경한다.

검색 엔진 등에서 URI 변경하면 안될 때 사용한다.

 

302 Found

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

프레임워크나 기술 레벨에서 보면 라이브러리들이 기본값으로 302를 많이 쓰인다. 

 

307 Temporary Redirect

리다이렉트시 요청 메서드와 본문이 유지된다. 요청 메서드를 변경하면 안된다. 

 

303 See Other

리다이렉트 시 요청 메서드가 GET으로 변한다. 

 

302, 303, 307 정리

• 302 - 메서드가 GET으로 변할 수 있음
• 307 - 메서드가 변하면 안됨
• 303 - 메서드가 GET으로 변경됨

현실적으로 307, 303을 권장하지만 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다.

자동 리다이렉션 시에 GET으로 변해도 되면 302를 사용해도 큰 문제가 없다.

 

PRG (Post/Redirect/Get)

POST로 주문 후에 웹 브라우저를 새로고침하면 중복 주문이 될 수 있다. 이러한 경우, PRG를 사용한다.

• POST로 주문 후에 주문 결과 화면으로 리다이렉트
• 새로고침해도 결과화면을 GET으로 서버에 요청
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청

새로고침(Refresh)는 마지막에 요청한 request를 재요청한다.

 

PRG 사용 전

1. 클라이언트가 마우스 1개를 POST로 주문 요청한다.
2. 서버는 주문 데이터(마우스 1개)를 DB에 저장한다.
3. 서버가 200 코드와 주문완료 html 리소스를 클라이언트에 응답한다.
4. 결과 화면을 새로고침하면 마지막 POST 요청을 새로고침 하게 된다.
5. 클라이언트가 마우스 1개를  POST로 중복 주문 요청을 한다.
6. 서버는 주문 데이터(마우스 1개)를 DB에 중복 저장한다.
7.  서버가 200 코드와 주문완료 html 리소스를 클라이언트에 응답한다.
-> 서버차원에서 중복 주문 방지: "잘못된 주문코드번호입니다"같은 응답으로 중복 주문을 방지해야 함

 

PRG 사용 후

클라이언트차원에서 중복 주문을 방지한다는 개념이다.

주문 요청을 할 때는 POST 메소드를 사용 하고 주문 완료창으로 리다이렉트 시킨다.

주문 완료창은 GET 메소드를 사용한다.

따라서 새로고침해도 GET으로 결과 화면만 조회한다.

 

기타 리다이렉션

300 Multiple Choice

안 쓴다.

 

304 Not Modified - 캐시 목적

클라이언트에게 리소스가 수정되지 않았음을 알려줌 -> 클라이언트는 로컬PC에 저장된 캐시 재사용(캐시로 리다이렉트

• 응답에 메시지 바디를 포함하면 안됨(로컬 캐시를 사용해야하기 때문)
• 조건부 GET, HEAD 요청 시 사용

 

400번대 - 클라이언트 오류

클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 상태코드이다.

오류의 원인이 클라이언트에 있다.

클라이언트가 이미 잘못된 요청을 데이터를 보내고 있기 때문에 똑같이 재시도하면 실패한다. 

 

400 Bad Request

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

• 요청 구문, 메시지 등 오류
• 클라이언트는 요청 내용을 재검토 후 보내야 함
• 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

 

401 Unauthorized 

클라이언트가 해당 리소스에 대한 인증이 필요하다.

오류 발생시 응답에 WWW-Authenticate라는 헤더와 함께 인증하는 방법을 설명을 해줘야 한다. 

인증(Authentication) : 본인이 누구인지 확인하는 과정
인가(Authorization) : 특정 리소스에 접근할 수 있는 권한이 있는 사람만 볼 수 있는 권한 부여
오류 메시지가 Unauthorized이지만 실제로는 인증이 되지않아 생긴 오류이다.

 

403 Forbidden

클라이언트가 보낸 요청을 서버가 이해했지만 승인을 거부하는 상태코드이다.

주로 인증 자격 증명은 있지만 접근 권한이 없을 때 볼 수 있다.

어드민 등급이 아닌 사용자가 다른 리소스로 로그인은 했지만 어드민 등급의 리소스에 접근할 때 오류가 나타난다.

 

404 Not Found

요청 리소스를 찾을 수 없는 상태코드이다.

클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때 사용할 수도 있다.

 

500번대 - 서버 오류

서버 오류

• 오류의 원인 = 서버 ( NullPointerException, DB 접근 불가 등)
• 서버에 문제가 있으므로 복구된 뒤 재시도하면 성공할 수도 있음

왠만하면 5xx 오류는 내면 안된다. 심각한 서버 오류가 있을 때만 500번대 오류를 내야 한다.

 

500 Internal Server Error

서버 내부 문제로 오류 발생한 상태코드이다.

애매한 오류는 500 상태코드이다.

 

503 Service Unavaliable

서버가 일시적인 과부하 되거나 예정된 작업으로 잠시 요청을 처리할 수 없는 것을 나타냄

Retry-After 헤더로 얼마 뒤에 복구되는지 예상 시간을 보낼수 있다.