모든 개발자를 위한 HTTP 웹 기본 지식 - HTTP 상태코드

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

인프런 김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강한 뒤 정리한 글입니다.

 

목차

• 인터넷 네트워크

• URI와 웹 브라우저 요청 흐름

• HTTP 기본

• HTTP 메소드

• HTTP 메소드 활용

• HTTP 상태코드

• HTTP 헤더1(일반헤더)

• HTTP 헤더2 : 캐시와 조건부 요청

 

HTTP  상태코드

HTTP 상태코드 정리

클라이언트가 보낸 요청의 처리상태를 응답에서 알려주는 기능이라고 볼 수 있다. 코드 범위별로 큰 의미는 같으므로 새로운 HTTP 상태코드가 생기는 등의 일로 모르는 HTTP 코드를 받게되는 경우에도 어느정도 처리를 할 수 있다.

 

1xx (Informational)

요청이 수신되어 처리중을 뜻함. 거의 사용되지 않음

 

2xx (Successful)

요청이 정상 처리(성공)되었음을 뜻한다. 

 

200 OK : 요청이 정상적으로 처리되었음을 뜻함. 
 예) GET을 이용한 조회 요청시 응답메시지에 200 OK를 포함시켜 전달 

201 Created : 클라이언트의 요청으로 서버측에서 리소스를 생성하였음. 
 예) POST 메서드를 이용한 새로운 리소스 등록

202 Accepted : 요청은 성공했으나 서버측에서 처리가 완료되지 않았을 때 
 예) 배치 프로세스

204 No Content : 요청은 성공했으나 응답 페이로드 본문에 보낼 데이터가 없을 때
 예) 웹 문서 편집기에서 save 버튼을 눌렀을 때 결과로 전달할 내용이 없어도 된다. 결과가 없어도 204 메시지 만으로 성공을 전달할 수 있다.

 

3xx (Redirection)

요청을 완료하려면 추가 행동이 필요함을 뜻하며, 클라이언트에게 다시 보낸다. 리다이렉트시 주로 사용한다. 리다이렉트시 웹브라우저는 응답메시지에 존재하는 Location 위치로 이동한다.

 

• 영구 리다이렉션 특징 및 종류

특정 리소스의 URI가 영구적으로 이동한 경우

301 Moved Permanently : 리다이렉트시 요청메서드와 본문이 변경, 제거될 수 있다. POST로 요청한 경우 본문이 제거되고 요청은 GET 메서드로 변경된 상태로 리다이렉트될 수 있다. 이럴 경우 리다이렉트된 화면은 조회(GET)화면, 본문제거되므로 입력했던 내용은 날아감

308 Permanent Redirect :  301과 같은 기능 이지만 리다이렉트시 요청메서드와 본문이 유지된다. 클라이언트가 POST로 요청한 경우 리다이렉트로 POST로 유지된다. 이럴 경우 본문 및 메서드가 유지된 상태로 리다이렉트 되지만 URL 변경시에는 전달할 본문도 변경될 가능성이 높으므로 대부분 GET으로 돌리는(301)방식을 이용한다.

• 일시 리다이렉션

리소스의 URI가 일시적으로 이동하는 경우, 변경이 또 이루어 질 수 있으므로 검색엔진에서 URL을 변경하면 안된다. 일시리다이렉션에 이용되는 3xx번대 메시지의 기능은 동일하다.

302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다. (실무에서 많이 사용)

303 See Other : 리다이렉트시 요청메서드와 본문이 유지된다.(변해선 안된다)

307 Temporary Redirect : 리다이렉트시 요청 메서드가 GET으로 변경된다. (확정적으로 변경)

303, 307을 권장하지만 많은 곳에서 302를 디폴트 메시지로 선택해서 사용 중이다. 리다이렉션 시에 GET으로 변해도 된다면 302를 사용해도 문제가 없다고 본다.

• 일시적 리다이렉션이 필요한 경우(PRG: Post/Redirect/Get)
(POST 메소드로)주문 후에 웹 브라우저를 새로고침하면 마지막 요청이 한 번 더 되므로 요청이 중복 될 수 있다.

PRG 사용전 예시
1. 클라이언트가 POST 메서드를 이용해 주문정보를 전송
2. 요청을 받은 서버는 주문 정보를 DB에 저장
3. HTTP 상태코드(200 OK)와 함께 응답 메시지 전송
4. 클라이언트가 주문 화면을 새로고침
5. 요청을 받은 서버는 주문 정보를 DB에 저장
6. HTTP 상태코드(200 OK)와 함께 응답 메시지 전송

 

일시적인 리다이렉션을 통해 주문 후 새로고침으로 인한 중복 주문을 방지할 수 있다. POST로 주문이 들어온 뒤 주문결과 화면을 GET 메서드로 리다이렉트하게되면 새로고침을 해도 화면을 GET 메서드로 조회한다. 이를 통해 사용자의 사용성을 증가시키고 서버측의 오류를 줄일 수 있다.

 

PRG 사용 예시
1. 클라이언트가 POST 메서드를 이용해 주문정보를 전송
2. 요청을 받은 서버는 주문 정보를 DB에 저장
3. HTTP 상태코드(302 Found)와 Location을 응답 메시지로 전송
4. Location으로 자동 리다이렉트(GET 사용)
5. 클라이언트가 주문 화면을 새로고침
6. GET 메서드를 이용해 주문 조회 화면으로 요청
7. HTTP 상태코드(200 OK)와 응답메시지 전송(주문이 이루어지지 않음)


• 특수 리다이렉션

결과대신 캐시 사용하는 경우(클라이언트가 캐시관련 정보를 요청)
300 Multiple Choices

304 Not Modified(★) : 조건부 GET, HEAD 요청시, 캐시를 목적으로 사용된다. 클라이언트에게 리소스가 수정되지 않았음을 알려준다.(=캐시가 만료되지 않았음을). 클라이언트는 로컬에 저장된 캐시를 재사용한다.(=캐시로 리다이렉트 한다)
클라이언트가 로컬캐시를 사용하므로 응답시 메시지에 바디를 포함할 수 없다.

 

4xx (Client Error)

클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음을 뜻한다. 클라이언트의 요청이 잘못된 것이므로 똑같은 요청을 재시도해도 실패한다.(요청이 성공하려면 요청을 수정해서 보내야한다)

 

400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음. 요청구문, 메시지 등에서 오류가 발생한 것으로클라이언트는 요청 내용을 검토해서 다시 보내야한다.

예) 요청 내역의 파라미터 혹은 API 스펙이 맞지 않을 때, 숫자를 문자로 보냈을 때

401 Unauthorized : 클라이언트가 접근하려는 리소스에 대한 인증(Authentication)이 되지않아 인증이 필요함. 
* 인증(Authentication)은 본인이 누구인지 확인하는 것이고 인가(Authorization)는 리소스에 접근할 수 있는 권한을 부여하는 것이다. 인증이 되었더라도 리소스에 대한 인가가 되지 않았다면 접근할 수 없다(403 Forbidden). 401의 메시지는 Unauthorized이지만 인증(Authentication)이 되지 않았음을 알리는 점은 아쉽다.

403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함. 인증은 되었지만 접근권한이 불충분한 경우에 발생

404 Not Found : 요청 리소스를 찾을 수 없음. 요청 리소스가 서버에 없는 경우 또는 클라이언트의 권한이 없지만 403 대신 접근한 리소스 자체를 숨기고 싶을 때 사용

 

5xx (Server Error)

서버측 오류, 서버가 정상 요청을 처리하지 못함을 뜻한다. 서버가 요청을 처리할 수 없는 상태에서 서버오류가 복구되면 똑같은 요청을 재시도했을 때 성공할 수 있다. 서버에 오류(쿼리, DB)가 발생한 경우를 제외하고 클라이언트 요청에 대해서 5xx에러가 발생하지 않도록 해야한다. 

500 Internal Server Error : 서버 내부 문제로 오류 발생. 애매한 상황에서 500 오류 사용

503 Service Unavailable : 서비스 이용불가. 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있다.