✍️
dodeon
  • 개발왕, 도던
  • 스프링 시큐리티 인 액션
    • 오늘날의 보안
    • 안녕! 스프링 시큐리티
    • 사용자 관리
    • 암호 처리
    • 인증 구현
    • 실전: 작고 안전한 웹 애플리케이션
    • 권한 부여 구성: 액세스 제한
    • 권한 부여 구성: 제한 적용
    • 필터 구현
    • CSRF 보호와 CORS 적용
    • 실전: 책임의 분리
    • OAuth 2가 동작하는 방법
    • OAuth 2: 권한 부여 서버 구현
  • 스프링 고급편
    • 스레드 로컬
    • 템플릿 메서드 패턴과 콜백 패턴
    • 프록시 패턴과 데코레이터 패턴
  • 스프링 입문
    • 프로젝트 환경설정
    • 스프링 웹 개발 기초
    • 회원 관리 예제 - 백엔드
    • 스프링 빈과 의존 관계
    • 회원 관리 예제 - MVC
    • 스프링 DB 접근 기술
      • JDBC
      • JPA
    • AOP
  • 스프링 핵심 원리
    • 객체 지향 설계와 스프링
      • 스프링의 탄생
      • 객체 지향 프로그래밍
      • 좋은 객체 지향 설계의 원칙
      • 객체 지향 설계와 스프링
    • 스프링 핵심 원리 이해
      • 회원 도메인 개발
      • 주문 도메인 개발
    • 객체 지향 원리 적용
      • 관심사의 분리
      • 새로운 구조와 정책 적용
      • 정리
      • IoC, DI, 컨테이너
      • 스프링으로 전환하기
    • 스프링 컨테이너와 스프링 빈
      • 스프링 빈 기본 조회
      • 동일 타입이 둘 이상일 때 조회
      • 상속일 때 조회
      • BeanFactory와 ApplicationContext
      • 다양한 설정 형식
      • 스프링 빈 설정 메타 데이터
    • 싱글턴 컨테이너
      • @Configuration과 싱글턴
    • 컴포넌트 스캔
      • 탐색 위치와 기본 탐색 대상
      • 필터와 중복 등록
    • 의존 관계 자동 주입
      • 롬복과 최신 트렌드
      • 조회 빈이 2개 이상일 때
      • 애너테이션 직접 만들기
      • 조회한 빈이 모두 필요할 때
      • 올바른 실무 운영 기준
    • 빈 생명 주기 콜백
      • 인터페이스 방식
      • 메서드 지정 방식
      • 애너테이션 방식
    • 빈 스코프
      • 프로토타입 스코프
      • Provider
      • 웹 스코프
  • 스프링 MVC
    • 웹 애플리케이션 이해
      • 서버
      • 서블릿
      • 멀티 스레드
      • HTML, HTTP API, CSR, SSR
      • 자바 백엔드 웹 기술 역사
    • 서블릿
      • HttpServletRequest
      • HTTP 요청 데이터
      • HttpServletResponse
      • HTTP 응답 데이터
    • 서블릿, JSP, MVC 패턴
      • 서블릿으로 만들기
      • JSP로 만들기
      • MVC 패턴
    • MVC 프레임워크 만들기
      • 프론트 컨트롤러 패턴
      • View 분리
      • Model 추가
      • 단순하고 실용적인 컨트롤러
      • 유연한 컨트롤러
      • 정리
    • 스프링 MVC의 구조 이해
      • 스프링 MVC 전체 구조
      • 핸들러 매핑과 핸들러 어댑터
      • 뷰 리졸버
      • 스프링 MVC 시작하기
      • 스프링 MVC 컨트롤러 통합
      • 스프링 MVC 실용적인 방식
    • 스프링 MVC 기본 기능
      • 프로젝트 생성
      • 로깅
      • 요청 매핑
      • HTTP 요청의 기본 및 헤더 조회
      • HTTP 요청 파라미터
      • HTTP 요청 메시지
      • HTTP 응답
      • HTTP 메시지 컨버터
      • 요청 매핑 핸들러 어댑터
    • 스프링 MVC 웹 페이지 만들기
    • 메시지, 국제화
      • 스프링 메시지 소스
    • Validation
      • BindingResult
      • FieldError, ObjectError
      • 오류 코드와 메시지 처리
      • Validator 분리
    • Bean Validation
      • Form 전송 객체 분리
      • HTTP 메시지 컨버터
    • 로그인
      • 쿠키
      • 세션
      • 서블릿 HTTP 세션
      • 서블릿 필터
      • 스프링 인터셉터
      • ArgumentResolver 활용
    • 예외 처리와 오류 페이지
      • 오류 화면 제공
      • 필터
      • 인터셉터
      • 스프링 부트 오류 페이지
    • API 예외 처리
      • 스프링 부트 기본 오류 처리
      • HandlerExceptionResolver
      • ExceptionResolver
      • ControllerAdvice
    • 스프링 타입 컨버터
      • Converter
      • ConversionService
      • 뷰 템플릿에 적용하기
      • Formatter
    • 파일 업로드
      • 서블릿과 파일 업로드
      • 스프링과 파일 업로드
      • 파일 업로드 및 다운로드 예제
  • 자바 ORM 표준 JPA 프로그래밍
    • JPA 소개
    • JPA 시작하기
    • 영속성 관리
      • 영속성 컨텍스트
      • 플러시
      • 준영속 상태
    • Entity 매핑
      • 객체와 테이블 매핑
      • 데이터베이스 스키마 자동 생성
      • 필드와 칼럼 매핑
      • 기본 키 매핑
      • 실전 예제
    • 연관 관계 매핑
      • 단방향 연관 관계
      • 양방향 연관 관계
      • 실전 예제
    • 다양한 연관 관계 매핑
      • 다대일
      • 일대다
      • 일대일
      • 다대다
      • 실전 예제
    • 고급 매핑
      • 상속 관계 매핑
      • 매핑 정보 상속
      • 실전 예제
    • 프록시와 연관관계 관리
      • 프록시
      • 즉시 로딩과 지연 로딩
      • 영속성 전이와 고아 객체
      • 실전 예제
    • 값 타입
      • 기본값 타입
      • 임베디드 타입
      • 값 타입과 불변 객체
      • 값 타입의 비교
      • 값 타입 컬렉션
      • 실전 예제
    • 객체 지향 쿼리 언어 - 기본
      • 기본 문법과 쿼리 API
      • 프로젝션
      • 페이징
      • 조인
      • 서브 쿼리
      • JPQL 타입 표현과 기타 식
      • 조건식
      • JPQL 함수
    • 객체 지향 쿼리 언어 - 중급
      • 경로 표현식
      • fetch join
      • 다형성 쿼리
      • Entity 직접 사용
      • Named 쿼리
      • 벌크 연산
  • 스프링 부트와 JPA 활용 - 웹 애플리케이션 개발
    • 프로젝트 환경설정
    • 도메인 분석 설계
      • 도메인 분석 설계
      • Entity 클래스 개발
      • Entity 설계 시 주의점
    • 애플리케이션 아키텍처
    • 회원 도메인 개발
    • 상품 도메인 개발
    • 주문 도메인 개발
      • Entity, 리포지토리, 서비스 개발
      • 주문 기능 테스트
      • 주문 검색 기능 개발
    • 웹 계층 개발
      • 변경 감지와 병합
  • 스프링 부트와 JPA 활용 - API 개발과 성능 최적화
    • API 개발 기본
      • 회원 등록 API
      • 회원 수정 API
      • 회원 조회 API
    • 지연 로딩과 조회 성능 최적화
      • Entity 직접 노출
      • Entity를 DTO로 변환
      • JPA에서 DTO 직접 조회
    • 컬렉션 조회 최적화
      • Entity 직접 노출
      • Entity를 DTO로 변환: 페치 조인
      • Entity를 DTO로 변환: 페이징과 한계 돌파
      • DTO 직접 조회
      • DTO 직접 조회: 컬렉션 조회 최적화
      • DTO 직접 조회: 플랫 데이터 최적화
      • 정리
    • OSIV와 성능 최적화
  • 스프링 데이터 JPA
    • 예제 도메인 모델
    • 공통 인터페이스 기능
      • 순수 JPA 기반 리포지토리
      • 공통 인터페이스 설정
    • 쿼리 메서드 기능
      • JPA Named Query
      • @Query
      • 파라미터 바인딩
      • 반환 타입
      • 페이징과 정렬
      • 벌크성 수정 쿼리
      • @EntityGraph
      • JPA Hint & Lock
    • 확장 기능
      • 사용자 정의 리포지토리
      • Auditing
      • Web 확장
    • 스프링 데이터 JPA 분석
    • 나머지 기능
      • Specifications
      • Query By Example
      • Projections
      • Native Query
  • Querydsl
    • 프로젝트 환경 설정
    • 예제 도메인 모델
    • 기본 문법
      • JPQL vs Querydsl
      • Q-Type 활용
      • 검색 조건
      • 결과 조회
      • 정렬
      • 페이징
      • 집합 함수
      • 조인
      • 서브 쿼리
      • Case 문
      • 상수, 문자 더하기
    • 중급 문법
      • 프로젝션과 결과 반환
      • 동적 쿼리
      • 수정, 삭제 벌크 연산
      • SQL Function 호출
    • 순수 JPA와 Querydsl
      • 순수 JPA 리포지토리와 Querydsl
      • 동적 쿼리와 성능 최적화 조회
      • 조회 API 컨트롤러 개발
    • 스프링 데이터 JPA와 Querydsl
      • 스프링 데이터 페이징 활용
      • 스프링 데이터 JPA가 제공하는 Querydsl 기능
  • 데이터 접근 핵심 원리
    • JDBC 이해
      • JDBC와 최신 데이터 접근 기술
      • 데이터베이스 연결
      • JDBC 개발
  • 백엔드 시스템 실무
    • CPU bound 애플리케이션
      • CPU를 극단적으로 사용하는 애플리케이션
      • 스트레스 테스트 툴로 성능 측정
      • Dockerized 애플리케이션 GCP 배포
      • Jenkins를 이용한 배포
    • CPU bound 애플리케이션 무중단 배포
      • nginx를 통한 로드밸런싱 구성
      • 서버를 늘려서 성능 측정
    • 배포 자동화와 협업을 위한 Git
      • GitHub Webhook과 jenkins로 배포 자동화
      • 머지할 때 발생하는 충돌 해결하기
      • 실무에서 유용한 Git 꿀팁
    • I/O bound 애플리케이션
    • Message Queue를 도입하여 데이터 유실 방지
      • 스트레스 테스트
    • 검색과 분석을 위한 저장소 ElasticSearch
    • Kubernetes
  • 모든 개발자를 위한 HTTP 웹 기본 지식
    • 인터넷 네트워크
      • IP
      • TCP, UDP
      • PORT
      • DNS
    • URI와 웹 브라우저 요청 흐름
    • HTTP 기본
      • 클라이언트-서버 구조
      • stateful, stateless
      • 비 연결성
      • HTTP 메시지
    • HTTP 메서드
    • HTTP 메서드 활용
    • HTTP 상태 코드
    • HTTP 헤더 - 일반
      • 표현
      • 콘텐츠 협상
      • 전송 방식
      • 정보
      • Authorization
      • 쿠키
    • HTTP 헤더 - 캐시
      • 검증 헤더와 조건부 요청
      • 조건부 요청 헤더
      • 프록시 캐시
      • 캐시 무효화
  • 김영한의 실전 자바
    • 제네릭
  • 예제로 배우는 스프링 입문
    • 예제로 배우는 스프링 입문(개정판)
      • PetClinic 예제
      • 스프링 IoC
      • 스프링 AOP
      • 스프링 PSA
  • 스프링 프레임워크 핵심 기술
    • 스프링 프레임워크 핵심 기술
      • IoC 컨테이너와 빈
        • 스프링 IoC 컨테이너와 빈
        • ApplicationContext와 빈 설정
        • @Autowired
        • @Component와 컴포넌트 스캔
        • 빈의 스코프
        • Environment
        • MessageSource
        • ApplicationEventPublisher
        • ResourceLoader
      • Resource/Validation
        • Resource 추상화
        • validation 추상화
      • 데이터 바인딩 추상화
      • SpEL
      • 스프링 AOP
      • Null-Safety
  • 스프링 부트 개념과 활용
    • 스프링 부트 원리
      • 자동 설정
      • 내장 서버
        • 컨테이너와 서버 포트
        • HTTPS와 HTTP2
      • 독립적으로 실행 가능한 JAR
    • 스프링 부트 활용
      • Spring Application
      • 외부 설정
      • 프로파일
      • 로깅
      • 테스트
      • Spring Boot Devtools
    • 스프링 웹 MVC
      • 소개
      • HttpMessageConverters
      • ViewResolver
      • 정적 리소스
      • 웹 JAR
      • index 페이지와 파비콘
      • ExceptionHandler
      • Spring HATEOAS
      • CORS
  • THE JAVA
    • JVM 이해하기
      • 자바, JVM, JDK, JRE
      • JVM 구조
      • 클래스 로더
      • Heap
      • Garbage Collector
    • 리플렉션
      • 클래스 정보 조회
  • The Java - Test
    • JUnit 5
      • JUnit 시작하기
      • JUnit 시작하기
    • Mockito
Powered by GitBook
On this page
  • 만약 모르는 상태 코드가 나타난다면?
  • 1xx Informational
  • 2xx Successful
  • 200 OK
  • 201 Created
  • 202 Accepted
  • 204 No Content
  • 3xx Redirection
  • 리다이렉션
  • 영구 리다이렉션(301, 308)
  • 일시 리다이렉션(302, 307, 303)
  • PRG(Post/Redirect/Get)
  • 특수 리다이렉션(300, 304)
  • 4xx Client Error
  • 인증과 인가
  • 5xx Server Error

Was this helpful?

  1. 모든 개발자를 위한 HTTP 웹 기본 지식

HTTP 상태 코드

PreviousHTTP 메서드 활용NextHTTP 헤더 - 일반

Last updated 4 years ago

Was this helpful?

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

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

클라이언트는 인식할 수 없는 상태 코드를 서버로부터 받으면, 상위 상태 코드로 해석해서 처리한다. 따라서 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

1xx Informational

  • 요청이 수신되어 처리중인 상태

  • 거의 사용하지 않는다.

2xx Successful

200 OK

클라이언트가 리소스를 달라고 요청하면 서버가 결과를 정상적으로 처리해서 응답한다.

201 Created

POST는 서버에서 자원을 생성하고 URI도 관리한다. 생성된 리소스의 경로는 응답의 Location 헤더 필드로 담아 보낸다.

응답이 201이면 자원이 생성되었고 Location 헤더 필드가 있을 수 있다고 예측할 수 있다.

202 Accepted

요청이 접수는 됐지만 처리가 완료되지 않았을 때 쓰인다. 클라이언트 요청은 성공했는데 서버는 1시간 뒤에 배치를 돌려 처리해야 할 경우 등에 쓰인다.

204 No Content

보통 요청에 성공하면 응답 바디에 데이터가 있는데 요청을 성공적으로 수행해도 보낼 데이터가 없을 때 쓰인다.

웹 문서 편집기에서 저장 버튼을 누르면 서버에서 저장 처리를 한 뒤 결과로 본문을 줄 필요는 없다. 그냥 잘 저장됐다는 것만 전달하면 된다. 이럴 경우 결과 내용 없이 204로 성공을 알릴 수 있다.

3xx Redirection

서버가 요청을 완료하기 위해 유저 에이전트의 추가 작업이 필요할 때 사용한다. 유저 에이전트는 주로 웹 브라우저를 말한다.

리다이렉션

웹 브라우저가 3xx 응답 결과에 Location 헤더가 있으면 그 위치로 자동 이동하는 것을 의미한다.

이벤트가 새로운 것으로 변경되었을 때, 기존 링크가 이미 공유되었거나 즐겨찾기 되어있을 수 있으므로 새로운 경로로 가도록 리다이렉트 한다.

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

  • /members에서 /users로

  • /event에서 /new-event로

특정 리소스의 URI가 영구적으로 이동된다. 이전 리소스는 사용하면 안되는 상황일 때 해당된다. 검색 엔진들도 이 변경을 인지해서 새로운 URI를 적용한다.

  • 301 Moved Permanently

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

    • 그럼 다시 POST로 기존의 메시지를 보내서 요청한다.

  • 308 Permanent Redirect

    • 301과 기능은 같다.

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

      • 처음 POST를 보낸 거라면 리다이렉트도 POST를 유지한다.

실무에서는 URI가 바뀌면 처리해야 할 메시지도 달라지기 때문에 POST로 와도 그냥 GET으로 돌리는 게 낫다.

일시 리다이렉션(302, 307, 303)

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

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

  • 302 Found

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

  • 307 Temporary Redirect

    • 302와 기능은 같다.

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

      • 요청 메서드를 변경하면 안된다.

  • 303 See Other

    • 302와 기능은 같다.

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

PRG(Post/Redirect/Get)

POST로 주문을 요청하면 주문 데이터에 주문을 저장한 뒤 200을 보낸다. 만약 결과 화면에서 새로고침을 누르면 마지막 요청을 다시 보내는 행위이기 때문에 중복 주문이 발생한다.

주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 하면 새로고침을 해도 결과 하면은 GET 조회만 발생한다. 중복 주문 대신 결과 화면만 요청하는 것이다.

클라이언트가 주문을 요청하면 응답으로 302나 303과 함께 리다이렉트할 Location을 보낸다. 그럼 클라이언트가 코드를 확인하고 302, 303이므로 GET으로 자동 리다이렉트를 한다. 새로고침을 해도 GET 결과 화면만 다시 요청한다.

그럼 302, 307, 303 중 무엇을 써야 할까?

처음 302의 의도는 HTTP 메서드를 유지하는 것이었다. 그런데 대부분의 웹 브라우저들이 GET으로 바꿔버렸고, 그래서 모호한 302 대신 명확한 307과 303이 등장했다. 307과 303을 권장하지만 현실에선 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있기 때문에 GET으로 변해도 되면 그냥 302를 사용해도 된다.

특수 리다이렉션(300, 304)

  • 300 Multiple Choices

    • 사용하지 않는다.

  • 304 Not Modified

    • 캐시를 목적으로 사용한다.

    • 클라이언트가 캐시가 만료됐는지 서버에 확인하기 위해 캐시 정보를 넘기고, 서버는 사용해도 되면 캐시로 다시 조회하라고 응답을 보낸다.

    • 클라이언트에게 리소스가 수정되지 않았음을 알려주면 클라이언트는 캐시로 리다이렉트 해서 로컬 PC에 저장된 캐시를 재사용 한다.

    • 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안된다.

    • 조건부 GET, HEAD 요청 시 사용한다.

4xx Client Error

클라이언트가 잘못된 요청을 해서 서버가 수행할 수 없을 때 사용한다. 클라이언트가 이미 잘못 요청한 것이기 때문에 똑같이 재시도 해도 실패한다. 5xx 에러는 재시도 하면 성공할 수 있다는 차이가 있다.

  • 400 Bad Request

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

    • 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때 발생한다.

    • 클라이언트가 요청 내용을 다시 검토하고 보내야 한다.

    • 백엔드 개발자는 철저하게 validation 해서 스펙 안맞으면 바로바로 튕겨줘야 한다.

  • 401 Unauthorized

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

    • 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.

  • 403 Forbidden

    • 서버가 요청을 이해했지만 승인을 거부한 상태

    • 주로 인증 자격 증명은 있지만 접근 권한이 없을 경우에 해당한다.

    • 로그인은 했지만 ADMIN이 아니면서 해당 리소스에 접근할 경우

  • 404 Not Found

    • 요청 리소스를 찾을 수 없는 상태

    • 또는 클라이언트가 권한이 부족한 리소스에 접근하면 그 리소스를 숨기고 싶을 때 사용

인증과 인가

  • 인증(Authentication)

    • 본인이 누구인지 확인하는 것

    • 로그인

  • 인가(Authorization)

    • 권한을 부여하는 것

    • ADMIN처럼 특정 리소스에 접근할 수 있는 권한

401은 오류 메시지가 Unauthorized이지만 인증에 해당된다.

5xx Server Error

서버에 문제가 있어서 발생하는 오류다. 따라서 서버가 복구되면 재시도 시 성공할 수 있다.

  • 500 Internal Server Error

    • 서버 내부 문제

    • 애매한 문제는 대부분 500 오류로 낸다.

  • 503 Service Unavailable

    • 서비스 이용 불가

    • 서버가 일시적인 과부하에 걸리거나 예정된 작업으로 잠시 요청을 처리할 수 없는 상태

    • Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있다.

보통 오류는 예측 불가한 상태에서 발생하므로 500이 많이 발생한다. 서버는 웬만하면 500을 내뱉으면 안된다. 진짜 서버에 문제가 터졌을 때만 발생시켜야 한다. API 스펙도 맞고 한데 비즈니스 로직 상 실패해서 500을 내면 안된다.

잔고가 없다거나 필요한 연령 제한을 못넘겼다거나 하는 문제는 비즈니스 로직 상 정상 예외 케이스이므로 2xx, 4xx로 해결하고 DB 에러나 NPE 등의 문제에 500을 내야 한다.