HTTP 상태코드
상태 코드
💡 **상태코드란 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능**상태코드의 종류는 아래와 같다
- 1XX (informational) : 요청이 수신되어 처리 중
- 2XX (successful) : 요청 정상 처리
- 3XX(Redirection) : 요청을 완료하려면 추가 행동이 필요
- 4XX ( Client Error): 클라이언트 오류 , 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
- 5XX (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
2XX (Successful)
클라이언트의 요청을 성공적으로 처리했다는 뜻이고 내부적으로 나누면 아래와 같다
- 200 OK
- 201 Created
- 202 Accepted
- 204 No content
200 OK
200은 요청 성공했다는 것을 의미한다
예를 들어 /memebers/100 URI로 데이터를 get한다는 요청을 보냈다고 가정하자
그러면 서버는 응답 메시지안에 해당 데이터를 담고 상태코드를 200 OK로 설정하여 응답할 수 있다
201 Created
요청 성공해서 새로운 리소스가 생성되는 것을 의미한다
예를 들어 클라이언트에서 /memeber URI에 새로 생성될 고객 데이터를 전달하였다고 가정해보자 이때 서버는 해당 데이터를 가지고 새로운 리소스를 생성하고 생성도니 리소스는 응답의 Location 헤더 필드로 식별한다 즉 생성된 리소스의 URI (ex memebers/100)을 헤더에 전송한다
이때는 요청이 성공해서 새로운 리소스가 생성되었기에 201을 사용한다
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음을 의미한다
예를 들어 요청을 접수하였는데 1시간 뒤 배치 프로세스 요청을 처리한다면 상태 코드 202를 사용할 수 있다 하지만 그닥 많이 사용하진 않는다고 한
( 참고로 배치는 데이터를 실시간으로 처리하는게 아닌 일괄적으로 모아서 처리하는 작업을 의미한다)
204 No Content
서버가 요청을 성공적으로 수행했지만 클라이언트가 현재 페이지에서 벗어나지 않아도 된다는 것을 의미한다
예를 들어 위키 사이트에서 “저장 후 편집 계속 “ 기능을 구현할 떄 사용할 수 있다 put 요청을 사용하여 페이지를 저장하고 서버에서 성공적으로 요청 수행 후 204 응답을 전송하면 다른 페이지로 대체하지 않고 현재 페이지에서 벗어나지 않아도 된다
MDN에서는 위와 같이 말하지만 응답 페이로드 본문에 보낼 데이터가 없을 때 사용하는 것 같다 ( 둘다 알아두자)
3XX (Redirection)
요청은 완료하기 위해 클라이언트에서 추가 조치가 필요한 경우 사용한다
💡 **리다이렉션이란? 웹 브라우저는 3XX 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동한다 ( Location URI로 다시 요청한다)**- 영구 리다이렉션
- 특정 리소스의 URI가 영구적으로 이동한다
- 일시 리다이렉션
- 일시적인 변경이다
- 특수 리다이렉션
- 결과 대신 캐시를 사용한다
301, 308
리소스의 URI가 영구적으로 이동한다는 의미로 원래 URL을 사용하지 않고 검색 엔진 등에서도 변경을 인지한다는 것을 의미한다 즉 SEO 측면에서 해석을 하자면 검색 엔진이 가진 이전 URL 페이지의 랭키과 평가 점수등을 새로운 URL로 이동시킨다는 것이다
예를 들어 /event URI가 /new-event로 변경되었다고 가정해보자 클라이언트에서는 따로 북마크를 했을 수도 있고 기억하던 URI로 페이지를 진입했을 수도 있다 그렇기에 /event URI로 진입을 하면 서버가 /new-event로 리다이렉션한다
-
301과 308의 차이점은?
- 301은 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수도 있다 ( 무조건 제거되는 것은 아니다)
- 308은 301 기능과 동일하게 리다이렉트하지만 요청 메서드인 POST와 본문을 유지한다
- 301 문제를 308이 해결하지만 브라우저들이 다 get으로 요청 메서드를 바꿔버리기에 308보단 301을 많이 사용한다
-
301
301 예시
- 308
308 예시
302,307,303
일시적 리다이렉션은 리소스 URI가 일시적으로 변경한다는 것을 의미한다 따라서 영구적 리다이렉션이랑 다르게 검색 엔진 등에서 URL을 변경하면 안된다
❓이런 일시적 리다이렉션을 언제 사용할까?
우리가 만약 Post로 주문 후에 웹 브라우저를 새로고침하면 어떤 상황이 발생할지 생각해보자
브라우저는 POST를 통해 데이터(결과)를 가져온 상태인데 새로고침을 하면 데이터가 날라가므로 그 데이터를 유지하기 위해서 post로 재요청을 하고 (사용자 양식을 다시 보낸다는 원리) 재주문이 된다
( get 요청을 하고 새로고침을 했을 때 해당 데이터를 다시 받아와 보여주는 것과 같은 원리라고 생각하면 수월하게 이해할 수 있다)
우리는 이런 상황을 방지하기 위해 일시적 리다이렉션을 사용한다
✅그래서 우리는 post 주문 후 주문 결과 화면을 get 메서드로 리다이렉트 시켜서 새로고침해도 결과화면을 get으로 조회하도록 만든다 ( 물론 요즘엔 경고창을 띄어준다)
- 302
- 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다 ( 위 예시에도 /order의 데이터가데이터가 사라졌다)
- 307
- 302와 기능은 같지만 요청 메서드와 본문을 유지한다
- 303
-
리다이렉트시 요청 메서드가 무조건 GET으로 변경된다 (302는 대부분 변경되는것이다) ( 본문이 제거되지 않고 303써서 get 요청하면 본문 있는게 무슨 소용? 그냥 확실히 get을 써서 303쓰라고 하는건가?
실무에서는 307과 303을 권장하지만 이미 많은 라이브러리들이 302를 기본값으로 사용한다 자동 리다이렉션시 get으로 변해도 괜찮으면 302를 사용해도 큰 문제가 없다
-
304
304는 캐시를 목적으로 사용한다
예를 들어 클라이언트에서 캐시가 만료되었다고 인지해서 서버로 요청을 한다 하짐나 서버는 만료되지 않았으니까 캐시에 있는 데이터를 그대로 써도된다고 응답 메시지를 전송할 때 304 메서드를 사용해서 캐시로 리다이렉트한다
이때 로컬 캐시에 있는걸 사용해야하는 게 명확하기에 응답에 메시지 바디를 포함하면 안된다
4XX - 클라이언트 오류
오류의 원인이 클라이언트에게 있을 때 400번대 상태코드를 전송한다 이때 클라이언트 원인인지 서버의 원인인지 구별하는 방법은 클라이언트 재시도했을 때 성공을 기준으로 본다
클라이언트가 재시도를 계속 해도 어차피 잘못된 요청이기에 실패한다 → 클라이언트 오류
클라이언트가 재시도를 했을때 성공할 가능성이 있다(서버만 복구하면 돼서) → 서버 오류
400 Bad Request
클라이언트가 잘못된 요청을 하여 서버가 요청을 처리할 수 없을 때보내는 상태코드이다
ex) 요청 파라미터가 잘못되었거나 api 스펙에 맞지 않다거나..
401 Unauthorized
해당 리소스에 대한 인증이 필요할 때 보내는 상태코드이다
401 오류가 발생했을 때는 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다
❗인증(Authentication) : 본인이 누구인지 확인하는 작업(ex 로그인)
❗인가(Authorization) : 권한부여 (ex ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한 , 추가 결제한 고객만 시청할 수 있는 영상에 접근하는 권한)
401은 인증이 되지 않았을 때 보내는 코드다 (이름은 Unauthorized이지만 헷갈리면 안된다)
403 Forbidden
서버가 요청을 이해했지만 승인을 거부할 때 보내는 상태코드이다
ex) 어드민 등급 아닌 사용자가 로그인은 했지만 어드민 등급의 리소스에 접근하는 경우
404 Not Found
요청 리소스가 서버에 없을 때
또는 클라이언트가 권한이 부족한 리소스에 접근할 떄 해당 리소스를 숨기고 싶을 때 사용한다
권한이 없으면 403을 전송하면 되지 해당 리소스를 숨기고 싶을 때 ( ex이 사이트는 존재하지 않다) 404를 사용한다
5XX 서버 오류
500
서버 내부 문제가 발생했을 때 500 상태 코드로 응답 메시지를 보낸다
503
서버가 일시적으로 과부화되어서 잠시 요청을 처리할 수 없을 때 503 상태코드를 보낸다
또한 Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있다
ex) 서버가 다운되었고 7시 이후에는 복구된다는 응답 메시지
하지만 실제 서버 문제는 예측 불가능한 경우가 대부분이기에 503번 상태코드를 많이 사용하지않고 500 상태코드가 더 많이 사용된다
