상태코드

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

상태코드는 크게 5가지가 있다.

• 1xx (Informational): 요청이 수신되어 처리중. 잘 쓰이지 않는다.
• 2xx (Successful): 요청 정상 처리. 우리가 제일 많이 봤던 200 OK 도 해당된다. 그외에도 201, 202 등등 많은 코드들이 있는데 주로 사용한 것들만 밑에서 따로 보여주겠다.
• 3xx (Redirection): 요청을 완료하려면 추가적인 행동이 필요하다. HTTP에서 Redirect에서 주로 사용한다.
• 4xx (Client Error): 클라이언트에서 잘못 보낸 오류이다. (잘못된 문법 등)
• 5xx (Server Error): 서버에서 나온 오류이다. 서버가 일시적으로 데이터베이스가 중단되었다던지 여러 문제로 서버에서 요청을 해결못했을때 나오는 코드이다.

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

예를 들어 299 코드가 들어왔을때 이 코드가 어떤 코드인지 모르면 어떻게 해야될까?

299 -> 2xx 즉 이백의 범위이기 때문에 (Successful)로 처리하면 된다.
451 -> 4xx (Client Error) 아 뭔가 클라이언트가 잘못했구나
599 -> 5xx (Server Error) 아 뭔가 서버가 잘못했구나

정리하면 큰 범위로 해결하면 된다.

1xx (Informational)

요청이 수신되어 처리중

• 거의 사용하지 않으므로 생략한다.

2xx (Successful)

클라이언트의 요청을 성공적으로 처리

• 200 OK
• 201 Created - 클라이언트에서 요청한 것을 서버에서 리소스를 생성한 것이다. 주로 POST를 사용했을때 나온다.
• 202 Accepted
• 204 No Content

200 OK

요청 성공

201 Created

요청 성공해서 새로운 리소스가 생성됨

POST로 보내면 서버는 새로운 리소스를 생성하고 클라이언트에서 보낸 정보를 입력한 다음 저장하고
만든 리소스의 URI를 Location으로 보낸다.

202 Accepted

요청이 접수되었으나 처리가 완료되지 않았음

예를 들어 서버 입장에서 요청을 1시간 뒤에 배치 프로세스가 요청을 처리할 때 202 Accepted를 통해 접수 되었다는 문구를 응답으로 보낼 수 있다.

근데 잘 사용안함.

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

언제 쓰면 좋냐
웹 브라우저에서 웹 문서에 편집기가 있는데 저장 버튼을 누르면, POST 라서 서버로 넘어가는데 서버에서 저장하고 보낼게 없다.

계속 편집하고 저장하고 편집하고 저장하고 반복한다면 save 버튼을 눌러도 같은 화면을 유지해야하고 성공 여부만 알고싶을때 사용한다.

 
그렇다면 이걸 다 사용하는 것이 좋냐
아니다. 처음 개발할때 어디까지 사용할 것인가 미리 정하고 하는것이 좋다. 200과 201만 사용하자 라고 하는 경우도 있고, 너무 많으면 협업할때 서로 헷갈리는 경우도 있기 때문이다.

3xx (Redirection)

요청을 완료하기 위해 유저 에이전트(클아이언트 프로그램 - 웹 브라우저)의 추가 조치 필요

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

리다이렉션 이해

• 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동하는 것(리다이렉트)

리다이렉션 종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

  • 예) /event -> /new-event

• 일시 리다이렉션 - 일시적인 변경

  • 주문 완료 후 주문 내역 화면으로 잠시 이동
  • PRG 패턴 : Post/Redirect/Get

• 특수 리다이렉션

  • 결과 대신 캐시를 사용

영구 리다이렉션 - 301, 308

• 리소스의 URI가 영구적으로 이동했을때 사용

• 검색 엔진에서 검색을 했는데 응답으로 영구적으로 이동했다는 표시가 오면 이동해야할 URL로 변경을 한다.

• 301 Moved Permanently

• 308 Permanent Redirect

둘이 기능은 같지만, 차이가 있다.

영구 리다이렉션 - 301

301의 경우는 응답을 받고나서 다시 새로운 URL로 보낼 때,
처음 POST에 있던 메시지가 없어지고 GET 메서드로 바꿔진다. (아마도)
그래서 다시 GET으로 보낼때 입력을 받는 폼이 새로 나오게 한다던지 따로 이것에 대한 처리가 필요하다.

영구 리다이렉션 - 308

308의 경우는 응답을 받고나서 다시 새로운 URL로 보낼 때,
이전의 POST형식, 메시지 바디 둘다 유지가 되어 그대로 보내게 된다.

(어... 강사님이 스펙이 있기 때문에(?) 이렇게 설명을 하지만 실무에서는 거의 이렇게 사용하지 않는다.)
이런 경우에는 웬만하면 GET으로 다시 돌리는게 맞다.

일시적인 리다이렉션 - 302, 307, 303

실무에서는 이 일시적인 리다이렉션을 많이 사용한다.
302, 307, 303 전부 기능은 똑같으나 차이가 있다.

302 Found

• 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(아마도). 이전에 나온 경우와 비슷한 특징이다. 그런데 바뀔수도 안바뀔수도 있다. 그렇기 때문에 확실히 하기 위해 307과 303이 나왔다.

307 Temporary Redirect

• 302와 기능이 같다.
• 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)

303 See Other

• 302와 기능은 같다.
• 리다이렉트시 요청 메서드가 GET으로

PRG: Post/Redirect/Get

일시적 리다이렉트가 꼭 필요함

• POST로 주문을 한 후에 웹 브라우저를 새로고침하면 다시 요청을 해서 중복 주문이 될 수 있다.

위를 어떻게 해결하느냐

POST로 입력을 받은 값들을 보내서 저장을 한 후에
주문 결과 화면을 GET 메서드로 리다이렉트를 하는 것이다.
그렇다면 새로고침을 해도 결과 화면이 계속 GET으로 조회가 될 것이다.

이것이 클라이언트에서 막는 것이다. 물론 서버에서도 막는 것이 좋다.

뭘 써야 할까

302 Found -> GET으로 변할 수 있음
307 Temporary Redirect -> 메서드가 변하면 안됨
303 See Other -> 메서드가 GET으로 변경

기타 리다이렉션 - 300, 304

300 Multiple Choices: 안씀
304 Nod Modified: 많이 씀

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

4xx (Client Error)

오류의 원인이 클라이언트에 있음

클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

400 Bad Request

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

• 요청 구문, 메시지 등등 오류
• 클라이언트는 요청 내용을 다시 검토하고, 보내야함
  예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

백엔드 개발자들은 이 부분을 최대한 잘 막아줘야한다. 클라이언트의 잘못이라는 것을 알려줘야 한다.

401 Unauthorized

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

• 인증되지 않음
• 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

인증: 본인이 누구인지 확인, 로그인
인가: 권한부여 (ADMIN 권한 처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

주로 인증 자격 증명은 있지만, 접근 권한이 없을때
ADMIN 권한이 없는 사람이 권한이 필요한 리소스에 접근할때 나옴

404 Not Found

요청 리소스를 찾을 수 없음

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

5xx (Server Error)

• 서버 문제로 오류 발생
• 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(서버가 복구되면)

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 500 오류

503 Service Unavailable

서비스 이용 불가

• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
• Retry-After 헤더 필드로 얼마뒤에 복구 되는지 보낼 수도 있음

하지만 이런 경우보단 대부분 500을 본다.

5xx 에러는 정말 서버의 심각한 문제가 있을 때 보내야 한다.