본문 바로가기
강의정리/모든개발자를위한HTTP웹기본지식

HTTP 상태코드 요약

by URMOO 2022. 8. 11.
반응형

본 내용은 인프런, 김영한님의 모든 개발자를 위한 HTTP 강의를 듣고 작성한 문서입니다.


클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

  • 1xx : 요청이 수신되어 처리중 (거의 사용안함)
  • 2xx : 요청 정상 처리
  • 3xx : 요청을 완료하려면 추가행동 필요 (리다이렉트)
  • 4xx : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청 수행할 수 없음
  • 5xx : 서버 오류, DB 문제 등으로 서버가 정상 요청을 처리하지 못함

만약, 모르는 상태코드가 나타난다면?

클라이언트는 상위 상태 코드로 해석해서 처리 -> 299로 온다면 대충 2xx.. 성공이구나.. 이렇게..

1XX 상태코드

HTTP 상태 코드 Value 설명
100 Informational 요청이 수신되어 처리중
거의 사용되지 않음

2XX 상태코드

성공

HTTP 상태 코드 Value 설명
200 OK 요청이 성공적으로 들어왔다. (조회 시?)
201 Created 요청 성공해서 새로운 리소스가 생성 되었다.
Http 헤더에 Location: /members/100 이런식으로 생성된 애의 정보를 보내줌.
202 Accepted 요청이 접수되었으나 처리가 완료되지 않음
ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리
잘 사용하지 않는다
204 No Content 서버가 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없는 경우
ex) save 를 눌러도 같은 화면을 유지해야 하는 경우.. 굳이 받을 데이터가 없을 때..
결과 내용이 없어도 204 메세지 만으로 성공을 인식 할 수 있다 (실패하면 다른 메세지 보내줘야함)

3XX 상태코드

요청을 완료하기 위해 유저에이전트 (주로 웹 브라우저)의 추가 조치 필요

리다이렉션?

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

리다이렉션 설명 예시 관련 HTTP 상태 코드
영구 리다이렉션 특정 리소스의 URI가 영구적으로 이동 /members -> /users 이런식으로 완전 바뀜, 거의 안씀 301, 308
일시 리다이렉션 리소스의 URI가 일시적으로 변경
검색 엔진 등에서 URL을 변경하면 안됨
주문 완료 후 주문 내역 화면으로 302, 307, 303
특수 리다이렉션 결과 대신 캐시를 사용   304
HTTP 상태코드 Value 설명
300 Multiple Choices 안씀
301 Moved Permanently 리다이렉트 요청시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
302 Found 리다이렉트 요청시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
303 See Other 302와 기능은 같은데 리다이렉트시 요청메서드가 GET으로 변경
304 Not Modified 캐시를 목적으로 씀 (뒤에 다시 설명)
클라이언트에게 리소스가 수정되지 않았음을 알려줌
304응답은 메세지 바디를 포함하면 안된다.
307 Temporary Redirect 302와 기능은 같은데 요청 메서드와 본문 유지 (POST->POST)
308 Permanent Redirect 301과 기능은 같은데 요청 메서드와 본문 유지 (POST->POST, 객체도 유지)

PRG : Post/Redirect/Get (3xx 상태에 관한 고찰)

만약 Post로 주문 후에 웹브라우저를 새로고침 한다면? -> 새로고침은 다시 재요청 -> 중복으로 주문이 들어갈 수 있다.

이를 막기 위해 일시적인 리다이렉션을 사용한다.

  1. 클라이언트가 POST로 아이템을 주문

서버는 302나 303을 이용하여 Location: /order-result/9 와 같이 헤더 정보를 보냄

  1. 위의 응답을 받은 웹브라우저는 Location 으로 화면을 다시 요청 (이때, GET으로 보내게 된다)
  2. 서버는 Location에 해당하는 응답을 보내줌
  3. 새로고침을 해도 GET 으로만 결과가 조회됨

4XX 상태코드

클라이언트의 오류, 오류의 원인이 클라이언트에 있음

클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같이 요청하면 계속 실패만 하게 됨

HTTP 상태코드 Value 설명
400 Bad Request 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
401 Unauthorized 클라이언트가 해당 리소스에 대한 인증이 필요함
403 Fobidden 서버가 요청을 이해했지만 승인을 거부함
주로 인증 자격은 있지만, 접근 원한이 불충분한 경우 ex) admin 권한인데 일반user가 접근
404 Not Found 요청 리소스를 찾을 수 없음
또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

5XX 상태코드

서버 문제로 오류 발생 ex) DB... Null..

서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음 (서버나 디비가 복구되는 경우..)

서버에서는 500 에러를 거의 만들면 안됨 -> 진짜 서버에 문제가 있을 때만 500 에러 던지기.. 은행잔고 부족 이런건 서버 에러가 아님

HTTP 상태코드 Value 설명
500 Internal Server Error 서버 문제로 오류 발생, 애매하면 그냥 500 에러..
503 Service Unavailable 서비스 이용 불가
서버가 일시적인 과부하, 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음
반응형

'강의정리 > 모든개발자를위한HTTP웹기본지식' 카테고리의 다른 글

HTTP 헤더 - 일반 헤더  (1) 2022.08.11
클라이언트에서 서버로 데이터 전송  (0) 2022.08.11
HTTP API를 만들어 보자  (0) 2022.08.11
HTTP  (0) 2022.08.11
URI  (0) 2022.08.10

댓글