loop-study
개발 공부할래?
loop-study
전체 방문자
오늘
어제
  • 분류 전체보기 (186)
    • 목표 및 회고 (25)
    • 세미나 & 워크샵 (1)
    • 교육 및 인강 (67)
      • TDD, Clean Code with Java (5)
      • ATDD, 클린 코드 with Spring (6)
      • DDD 세레나데 (3)
      • 인프라 공방 (6)
      • 이규원의 현실 세상의 TDD (19)
      • 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 (18)
      • 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 (0)
      • 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한 (8)
      • 코딩으로 학습하는 GoF의 디자인 패턴 (1)
      • 스프링 시큐리티 완전정복 6.x (1)
    • 서적 (62)
      • 객체지향의 사실과 오해 (1)
      • 객체지향과 디자인패턴 (7)
      • 만들면서 배우는 클린 아키텍처 (3)
      • 테스트 주도 개발로 배우는 객체 지향 설계와 실천 (1)
      • 오브젝트: 코드로 이해하는 객체지향 설계 (17)
      • 리팩토링 : 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기 (0)
      • 토비의 스프링 (3)
      • 엔터프라이즈 애플리케이션 아키텍처 패턴 (9)
      • 개발자의 글쓰기 (1)
      • 소프트웨어 장인 (17)
      • Real MySQL 8.0 (2)
      • JVM 밑바닥까지 파헤치기 (0)
    • 개발 & 방법론 (29)
      • Java (13)
      • TDD (5)
      • ATDD (3)
      • DDD (6)
      • 인프라 (2)
      • SQL (0)
    • 개인이야기 (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

  • 백엔드 로드맵

인기 글

태그

  • 백기선
  • DDD 세레나데
  • Test Driven Development
  • ATDD
  • fastcampus
  • 인프런
  • java
  • 추상화
  • 이규원
  • study
  • 자바
  • 장인정신
  • nextstep
  • 소프트웨어 장인
  • 테스트 주도 개발
  • 스프링
  • 스터디
  • 김영한
  • 조영호
  • Patterns of Enterprise Application Architecture
  • TDD
  • 넥스트스탭
  • 모든 개발자를 위한 HTTP 웹 기본 지식
  • 객체지향
  • 현실세상의 TDD
  • 엔터프라이즈 애플리케이션 아키텍처 패턴
  • 오브젝트
  • 인프라공방
  • 마틴 파울러
  • JUnit

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
loop-study

개발 공부할래?

HTTP 상태코드
교육 및 인강/모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한

HTTP 상태코드

2021. 12. 10. 16:22

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 수강하면서 HTTP 내용을 정리한다.

자세한 정보가 궁금하면 수강을 추천드립니다.

 

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

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., 웹 기술을 사용하는 개발자라면 누구나 OK!꼭 필요한 HTTP의 핵심을 알려드립니다. 📣 확인해주세요!본 강의는 자바 스

www.inflearn.com


HTTP 상태코드 소개

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

- 1xx (Informational) : 요청이 처리되어 수신 중 (거의 사용안함)

- 2xx (Successful) : 요청 정상 처리

- 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요

- 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청 수행을 못함

- 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리 못함 

 

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

몇번대 상태코드인지만 보고 파악하자.

- 1xx 처리중이구나

- 2xx 성공했구나

- 4xx 클라이언트 오류구나

- 5xx 서버 오류구나


2xx (Successful)

클라이언트 요청을 성공적으로 처리

- 200 ok : 요청을 성공했다는 뜻, 단순 조회 요청에 자주 접함 

- 201 Created : 리소스 등록 요청에 성공 

- 202 Accepted : 요청이 접수되었지만 처리가 안된 상태 (잘 사용안함) 

ex) 배치 요청 

- 204 No Context : 서버가 요청을 수행했지만, 응답으로 보낼 데이터가 없음.

ex) 문서 작업 중 save 눌러도 아무 변화없음, 결과 내용이 없어도 204 응답 메시지로 성공 인식 가능

 

* 200만 사용하는 회사도 있고 200,201을 같이 사용하는 회사도 있음. 회사마다 정하는 규칙에 따라 다름.


3xx (Redirection) 

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

- 300 Multiple Choices

- 301 Moved Permanently

- 302 Found

- 303 See Other

- 304 Not Modified

- 307 Temporary Redirect 

- 308 Permanent Redirect

 

리다이렉션의 이해

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 해당 Location로 이동한다.

* 리다이렉트라고 말하기도 함.

리다이렉트의 흐름

1. 클라이언트가 요청을 보낸다.

2. 서버가 요청을 처리하고 3xx 상태코드와 Location 경로를 보내준다.

3. 웹 브라우저가 상태코드와 Location을 보고 해당 경로로 자동으로 요청을 보내고 응답을 받는다.

4. 너무 빨라서 사용자의 입장에서는 인식을 하기 힘들다.  

리다이렉션의 종류

- 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

ex) /members -> /users, /event -> /new-event

 

- 일시 리다이렉션 - 일시적인 변경 (PRG: Post/Redirect/Get)

ex) 주문 완료 후 주문 내역 화면으로 이동

 

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

 

영구 리다이렉션

301, 308 상태코드를 가짐

- 리소스의 URI가 영구적으로 이동

    - 원래의 URL를 사용안함, 검색 엔진 등에서도 변경 인지함.

- 301 Moved Permanently

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

301은 메시지가 제거된다.

- 308 Permanent Redirect

    - 301과 기능은 같지만 요청 메서드와 본문 유지 (처음 POST로 보내면 리다이렉트도 POST도 유지) 

301과 다르게 HTTP 메서드와 본문이 유지

 

* 301 위주로 사용함, 요청 데이터까지 유지해야 할 이유가 별로 없기 때문  

일시적인 리다이렉션

302, 307, 303 상태코드를 가짐

- 리소스의 URI가 일시적으로 변경, 영구적인 리다이렉션과 다르게 검색엔진 등에서 URL 변경하면 안됨.

- 302 Found

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

- 307 Temporary Redirect

    - 302와 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드 변경하면 안됨) 

- 303 See Other

    - 302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경 

 

 

일시적인 리다이렉션 - 예시

 

- POST로 주문 후에 웹 브라우저를 새로고침하면?

- 새로고침은 다시 등록 요청을 하게 됨 -> 중복 주문이 될 수 있다. 

* 게시글이나 댓글을 등록할 때, 새로고침하면 중복으로 등록되는 경험을 겪어볼 수도 있다. 

중복 등록되는 모습

 

중복을 막는 PRG: POST/Redirect/Get 

- POST로 주문후에 새로고침으로 인한 중복 주문 등록 방지

- POST로 등록 요청 후에 결과화면을 GET 메서드로 리다이렉트 (Post/Redirct/Get)

- 새로고침해도 등록 요청이 아닌 결과화면만 GET 조회하게 됨

중복이 막힌 상태

302, 307, 303 뭘 써야 할까요?

역사

- 처음의 302 스펙의 의도는 HTTP 메서드를 유지하는 것, 하지만 웹 브라우저들이 대부분 GET으로 바꿔버림. (일부는 다르게 동작)

- 302 대신 307, 303이 등장하게 됨.

 

현실

- 307, 303을 권장해도 많은 애플리케이션 라이브러들이 302를 기본값으로 사용함

- 자동 리다이렉션시에 GET으로 변해도되면 그냥 302 사용해도 무방할 정도. 

 

기타 리다이렉션

- 300 Multiple Choices: 안씀

- 304 Not Modified

    - 캐시 목적으로 사용, 서버는 클라이언트에게 수정되지 않음을 알려줌

    - 로컬 PC에 저장된 캐시로 리다이렉트해서 재사용함.

    - 로컬 캐시를 사용해야 하니 응답에 메시지 바디를 포함안함.

    - 조건부 GET, HEAD 요청시에 사용함


4xx (Client Error)

클라이언트의 오류일 경우 사용

- 클라이언트가 잘못된 요청으로 서버가 요청을 수행할 수 없을 경우 (오류의 원인이 클라이언트)

- 같은 요청을 보내도 계속 실패함. 

* 서버에서 유효성 검사로 철저하게 쳐냄 

 

400 Bad Request

- 요청 구문, 메시지 등등 오류

- 클라이언트는 요청을 재검토해서 보내야함.

 

401 Unauthorized

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

- 인증되지 않음

- 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

참고

- 인증(Authentication) : 본인이 누구인지 확인 ex) 로그인

- 인가 (Authorization) : 권한 여부 확인 ex) 접근 권한

- 오류 메시지가 Unauthorized 이지만 인증되지 않음

 

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

- 인증은 되지만, 접근 권한이 안 되는 경우 ex) 일반 관리자가 최고 등급 관리자 리소스에 접근할 경우

 

404 Not Found

요청 리소스를 찾을 수 없음

- 요청 리소스가 서버에 없음

- 또는 해당 리소스를 숨기고 싶을 때

404 에러 


5xx (Server Error)

서버 오류

- 서버 문제로 오류가 발생

- 4xx와 다르게 재시도하면 성공할 수도 있음 (서버가 복구되면)

* 참고 : 결제 요청 시 고객의 잔액이 부족하면 5xx 에러를 내면 안 된다.

 

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 모두 500 에러

 

503 Service Unavailable

서비스 이용 불가

- 서버가 과부하 되었거나, 배포 작업 등으로 이용 못할 경우 사용

- Retry-After 헤더 필드로 언제 복구되는지 보낼 수도 있음.

 

'교육 및 인강 > 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한' 카테고리의 다른 글

HTTP 헤더2 - 캐시와 조건부 요청  (0) 2021.12.13
HTTP 헤더1 - 일반 헤더  (0) 2021.12.13
HTTP 메서드 활용  (0) 2021.12.10
HTTP 메서드  (0) 2021.12.09
HTTP 기본  (0) 2021.12.09
    '교육 및 인강/모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한' 카테고리의 다른 글
    • HTTP 헤더2 - 캐시와 조건부 요청
    • HTTP 헤더1 - 일반 헤더
    • HTTP 메서드 활용
    • HTTP 메서드
    loop-study
    loop-study
    오늘도 공부하자

    티스토리툴바