HTTP 응답코드

annmj·2021년 11월 21일
0

200 성공

201 Created

  • 요청 성공해서 새로운 리소스 생성
  • 생성된 리소스는 응답의 Location 헤더 필드로 식별 한다.

202 Accepted

  • 요청이 접수는 되었으나 처리가 완료되지 않았음
  • 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리할 때 주는 응답
  • 잘 사용하진 않는다.

204 No Content

  • 서버가 요청을 성공적으로 수행했지만, 응답 Body 에 보낼 데이터가 없음
  • 웹 문서 편집기에서 save 버튼
  • save 버튼의 결과로 아무 내용이 없어도 된다.
  • 결과 내용이 없어도 204 메세지 만으로 성공을 인식할 수 있다.
  • 실패 시에는 다른 코드를 알려주면 된다.

3XX - 리다이렉션

  • 요청을 완료하기 위해 유저 에이전트(웹 브라우저) 의 추가 조치 필요
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동으로 이동한다. 다시 새로운 경로로 다시 서버로 요청한다.

리다이렉션

영구 리다이렉션

  • 특정 리소스의 URI 가 영구적으로 이동
    • ex) /event -> /new-event

일시 리다이렉션

  • 일시적인 변경
    • 주문 완료 후 주문 내역 화면으로 이동할 때 많이 쓴다.
    • PRG (Post / Redirect / Get)

특수 리다이렉션

  • 결과 대신 캐시를 사용
  • 캐시에서 다시 조회하도록 응답하는 것

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

  • 리소스의 URI 가 영구적으로 이동
  • 원래의 URL 을 사용하면 안되는데, 검색 엔진 등에서도 변경을 인지할 수 있다.
  • 301 Moved Permanently
    • 리다이렉트시 요청 메서드가 GET 으로 변하고, 본문(메세지의 바디 부분) 이 제거될 수 있다.(MAY)
    • POST 로 요청하더라도 다시 GET 으로 바뀜
    • 무조건 GET 으로 변하고 본문이 제거되는 건 아니다.
  • 308 Permanent Redirect
    • POST 로 요청하면, POST 그대로 유지를 시켜 준다.
    • 실무에선 거의 이렇게 사용하지는 않아. URL 자체가 바뀌면 전달해주어야 하는 데이터도 바뀌기 때문에

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

  • 리소스의 URI 가 일시적으로 변경
  • 검색 엔진 등에서 URL 을 변경하면 안된다.
  • 302 Found
    • 리다이렉트시 요청 메서드가 GET 으로 변하고, 본문이 제거될 수 있다. ( 301과 상황이 똑같음 )
    • 이 리다이렉트는 무조건 GET 으로 바꾸고 싶어 명확하게, 그래서 303을 만듬. 302를 써도 됩니다.
  • 307 Temporary Redirect
    • 302와 기능은 같다.
    • 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
  • 303 See Other
    • 302와 기능은 같다.
    • 리다이렉트시 요청 메서드가 GET 으로 변경
  • 현실적으로 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다.
  • 자동 리다이렉션시에 GET 으로 변해도 되면 그냥 302를 사용해도 큰 문제가 없다는 점을 기억하자.

PRG : Post / Redirect / Get

  • 일시 리다이렉션에서 많이 사용되는 패턴
  • POST로 주문 후에 웹 브라우저를 새로고침하면 서버에 중복 주문이 될 수 있다.
  • 서버에서 POST 의 결과로 302 Found 나 303 See other 을 줘가지고 , 웹 브라우저(클라이언트)는 Location 정보로 리다이렉션이 된다.
  • POST 로 주문 에 주문 결과 화면을 GET 메서드로 리다이렉트 (주로 주문결과 페이지로)
  • 새로고침해도 결과 화면을 GET으로 조회 , 중복 주문 대신에 결과 화면만을 요청한다.
  • PRG 이후 리다이렉트는 URL 이 이미 POST-> GET 으로 리다이렉트 되니까 사용자 입장에서도 refresh 해도 문제가 없고, 서버에서도 별도로 처리를 너무 신경 안써도 된다.

기타 리다이렉션 ( 300, 304 )

  • 300 Multiple Choices : 안쓴다
  • 304 Not Modified (많이 사용된다.)
    • 캐시를 목적으로 사용한다.(캐시로 리다이렉트 한다.)
    • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.
    • 304의 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
    • 조건부 GET , HEAD 요청시 사용

4xx - 클라이언트 오류

  • 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없다.
    **- 원인이 클라이언트에 있다.
  • 클라이언트가 이미 잘못된 요청을 했기에, 똑같은 재시도를 하더라도 실패한다.**

400 Bad Request

  • 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  • 요청 구문, 메시지 등등의 오류
  • 클라이언트는 요청 내용을 다시 검토하고, 보내야한다.
  • 요청 파라미터가 잘못되었거나, API 스펙을 맞지 않을 때, 숫자를 보내야하는데 문자를 보내거나, 이부분은 서버 개발자가 철저하게 해야한다.

401 Unauthorized

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

  • 인증(Authentication) 되지 않음

  • 401 오류 발생시 응답에 www-authenticate 헤더와 함께 인증 방법을 설명해야 한다.

  • 참고

    • 인증 : 본인이 누구인지 확인(로그인)
    • 인가(Authorization) : 권한부여 (ADMIN 권한 처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
    • 오류 메세지가 Unauthorized 이지만, 인증 되지 않음 그니까 로그인이 안된거라고 이해하면 된다. 401 메세지는

403 Forbidden

  • 서버가 요청을 이해했지만 승인을 거부함
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분
  • 어드민 등급이 아닌 사용자가 접근할 때 이런 오류를 보낸다.

404 Not Found

  • 요청 리소스를 찾을 수 없다.
  • 요청 리소스가 서버에 없음
  • 클라이언트가 권한이 부족한 리소스에 접근해서, 해당 리소스를 숨기고 싶을 때

5xx - Server Error

  • 서버 오류
  • 웬만하면, 서버에서는 이런 에러를 만들면 안된다.
    • 비즈니스 로직 상, API 스펙에 맞는 요청이 서버로 들어왔는데 고객의 잔고가 부족한 경우에는 500을 보내면 안된다.
    • 20살 이상이 안된 사람이 요청을 하면 500에러를 내면 안된다.
    • 진짜 서버에 문제가 있을 때 내야한다.
  • 서버 문제로 오류 발생
  • 서버에 문제가 있어서 재시도 하면 성공할 수도 있다.
  • 주로 DB 접근의 문제나 NullPointerExeception 등이있다.

500 Internal Server Error

  • 서버 내부 문제로 오류가 발생

503 Service Unavailable

  • 서비스 이용 불가
  • 서버가 일시적인 과부하 또는 강제로 서버 다운을 시켜서 예정된 작업으로, 잠시 요청을 처리할 수 없다는 응답을 냄
  • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있다.
  • 주로 503보다는 500을 많이 사용한다.
profile
차근차근

0개의 댓글