정리
• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
클라이언트가 주로 보는건 400 500이고, 개발할때는 200, 300을 종종 보게 될 것이다.
모르는 상태 코드?
클라이언트가 인삭할 수 없는 코드가 나와도, 앞의 백단위 자리수를 보고 적당히 처리해버린다.
100
거의 안쓴다
200
200 OK
- 처리 완료
201 Created
- 요청으로 새로운 리소스 생성
202 Accepted
- 접수되었으나 처리되지 않음
204 No Content
- 성공적으로 요청을 수행했지만, 반환 데이터는 없음
- 주로 save같은 기능에서 사용된다.
이 밖에도 몇개 있는데 주로 안쓰는편이다.
300
리다이렉션
- 300대 응답결과에 리다이렉션 URL이 있다면 그쪽으로 연결해준다.
영구 리다이렉션
- 특정 리소스의 URI가 영구적으로 이동
- 원래의 URL을 사용하면 안되고, 검색엔진에서도 변경을 인지한다.
301 Moved Permanently
308 Permanent Redirect
둘다 기능은 똑같지만, 301은 요청 메서드가 get으로 변하고 본문이 제거될 수 있다(대부분)
308은 요청메서드와 본문을 유지한다.
임시 리다이렉션
- 주문 완료 후 주문 내역 화면으로 이동
- POST Redirect GET
- 일시적으로 URI가 변하고, 검색엔진에서 URL을 변경하면 안된다.
302 Found
303 See Other
307 Temporary Redirect
302의 경우 301처럼 메서드가 get으로 변하고 본문이 제거 될 수 있다. (대부분)
307의 경우 302와 기능은 같으나 리다이렉트 요청시 메서드와 본문을 반드시 유지한다.
303의 경우 메서드만 get으로 바꾼다.
PRG
POST로 주문후에 새로 고침으로 인한 중복 주문 방지
POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
새로고침해도 결과 화면을 GET으로 조회
중복 주문 대신에 결과 화면만 GET으로 다시 요청
무엇을 쓰는가
• 302 Found = GET으로 변할 수 있음
• 307 Temporary Redirect = 메서드가 변하면 안됨
• 303 See Other = 메서드가 GET으로 변경
307, 303을 권장하지만, 많은 라이브러리들이 302를 기본값으로 써서 크게 문제는 없다.
특수 리다이렉션
- 결과 대신 캐시를 사용함
300 Multiple Choices
- 거의 안쓴다
304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스 수정이 없다는것을 알려준다
- 이 때 클라이언트는 로컬피시에 저장된 캐시를 재사용한다
- 캐시로 리다이렉트 해주는것
400
- 클라이언트의 요청이 잘못되었거나 해서 오류가 나는 경우
401 Unauthorized
- 인증되지 않음
- 인증(Authentication): 본인이 누구인지 확인, (로그인)
- 인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
403 Forbidden
인증은 되었지만, 인가되지 않은 경우
404 Not Found
요청 리소스가 서버에 없는 경우
혹은 클라이언트가 권한부족한 리소스에 접근시 이를 숨기고싶은 경우
500
- 서버의 문제로 클라이언트가 같은 요청을 다시 보내면 성공할지도 몰?루
500 Internal Server Error
서버 내부 문제
503 Service Unavailable
서버의 과부화 또는 예정된 작업으로 잠시 욫어 처리 불가
500오류는 진짜 서버에 문제가 생겼을 때 내야지, 아무때나 내버리면 모니터링 프로그램이 혼란스러워한다.
