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을 많이 사용한다.
차근차근