HTTP #7 상태코드 (200,300,400,500)

# HTTP의 상태코드

HTTP 응답 메시지 첫 줄(Start-Line) 헤더에는 상태코드가 포함되어 있다.

HTTP 코드를 추가해서 사용하더라도 앞자리 (2XX, 4XX)는 바뀌지 않으므로, 만약 클라이언트에서 응답코드를 정확하게 모르더라도 추가적인 행동이 필요한건지 확인할 수 있다.

다만 1XX를 서버에서 직접 구현하는 경우는 없다.

다만 모든 HTTP 상태코드를 사용하는 건 아니다. 무작정 코드를 많이 사용해봐야 클라이언트에서 처리하기도 힘들고 굳이 그렇게 할 이유도 없기 때문이다.

 

✔ 실제 서비스에서 사용할만한 코드만 빠르게 알아보도록 하자. 없는 번호는 안쓴다고 생각하면 된다.

---

# 성공 2XX

성공은 현업에서 200만 사용하는 경우도 많다. 그 외에는 201, 204 정도만 자주 사용하는 편이다.

• [200 OK] 성공을 의미한다. 응답을 반환받으면 된다.
• [201 Created] 요청을 성공해서 새로운 리소스가 생성되었음을 알려준다.
  ➡ 200과 다른점은, Location 헤더를 사용해서 생성된 리소스의 URI를 제공해준다.

 

• [202 Accepted] 요청을 접수는 성공했고, 처리를 나중에 하는 경우. 다만 거의 사용하지는 않는 코드이다.

• [204 No Content] 서버가 요청을 성공했지만, 응답 본문에 보낼 데이터가 없는 경우 사용한다.

---

# 리다이렉트 3XX

요청을 성공적으로 처리했고, 완료하기 위해 클라이언트의 추가적인 조치(리다이렉트)가 필요한 경우 사용한다.

➡ 웹 브라우저는 3xx 응답 결과에 [Location 헤더]가 있다면 Location에 있는 URI 위치로 리다이렉트 시킨다.

 

참고로 리다이렉션에는 3가지 종류가 있다.

• 영구 리다이렉션 - URI가 영구적으로 변경된 경우 사용한다. 검색 엔진에서도 변경을 인지한다.
• 일시 리다이렉션 - 회원가입후 화면 이동이 필요할 때처럼 단순한 리다이렉션을 의미한다.
• 특수 리다이렉션 - 결과 대신 캐시를 사용하도록 리다이렉트 한다. (서버 응답 결과가 같은데 또 요청한 경우)

 

 

@ 영구 리다이렉션 - [301 Moved Permanently], [308 Permanent Redirect]

• 둘 다 영구 리다이렉션으로, 변경되기 전 URI를 호출했을 때 사용하는 응답코드이다.
• 재밌는 점은 기존의 HTTP 스펙은 308만 있었으나, 대부분의 웹 브라우저가 301처럼 동작해서 스펙이 추가되었다.
  ➡ 그래서 필요하다면 301을 사용하지, 308을 사용하는 경우는 없다. 이유는 HTTP의 안전성, 멱등성을 생각해보자.

 

📌 [301 Moved Permanently]은 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.

📌 [308 Permanent Redirect]은 기존의 요청 메서드와 본문을 그대로 유지한 상태로 리다이렉트 시킨다.

'본문이 제거 될 수 있다'라고 표현한 것은, 브라우저에 따라 그냥 308처럼 동작하는 경우도 있기 때문이다.

 

 

@ 일시 리다이렉션 - [302 Found], [307 Temporary Redirect], [303 See Other]

• 회원가입 후 화면전환처럼, 평범한 리다이렉션을 의미한다.
• 기존에는 302만 존재했으나 웹 브라우저에서 303, 307처럼 사용해서 스펙을 추가하였다.
  ➡ 영구 리다이렉션은 301만 사용하지만, 일시 리다이렉션은 그냥 302를 쓰는 경우도 있다.
  참고로 브라우저 회사들이 양아치인게 아니라, HTTP 스펙을 상세하게 적지 않았기 때문에 일어난 문제이다.

📌 [302 Found] 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (거의 대부분 303처럼 동작한다.)

📌 [303 See Other] 리다이렉트시 요청 메서드가 GET으로 변경된다. 본문도 없어진다. 

📌 [307 Temporary Redirect] 리다이렉트시 요청 메서드와 본문이 유지된다.

 

303, 307만 사용하는걸 권장하지만, 현실적으로 웹서비스에서 302가 많이 쓰이고 있기에 사용해도 큰 상관은 없다. 

• 새로고침을 눌렀을 때 POST 요청이 중복 발생하지 않도록 PRG( Post->Redirect->Get )를 많이 사용한다.
  ➡ [POST를 보내는 주문입력]에서 [GET을 보내는 주문입력완료]로 리다이렉트 시켜버리는 것이다.

다만 PRG와 함께 서버에서 이러한 일이 발생하지 않게 막아주는 로직을 짜는게 맞다.

 

 

@ 특수 리다이렉션 - [304 Not Modified]

• 캐시를 목적으로 사용한다. 조건부 GET, HEAD를 구현할 수 있다.
• 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 서버에 요청을 보내면 로컬PC의 캐시로 리다이렉트 한다.
• 그래서 304 Not Modified는 응답에 메시지 바디를 포함하면 안된다.

 

---

# 클라이언트 오류 4XX

클라이언트의 요청이 잘못되어 서버가 처리할 수 없음을 의미한다.

오류의 원인이 클라이언트에 있다. 즉 요청을 한번 더 보낸다고 한들 오류 복구가 불가능하다. 계속 거부한다.

 

• [400 Bad Request] 클라이언트가 잘못된 요청을 한 경우. 파라미터나 메시지의 값이 이상한 경우
  ➡ 서버에서는 이런 경우 5XX에러가 아닌 4XX에러가 나오도록 명확하게 예외처리를 해줘야한다.
  
  
• [401 Unauthorized] 클라이언트가 인증되지 않아 처리가 불가능한 경우 발생한다.
  ➡ 이름은 인가로 적혀있지만, 사실 401은 인증(Authentication)에 사용된다. 로그인이 안된 경우

인증은 본인이 맞는지 확인(=로그인이 안된 경우), 인가는 API의 권한 LEVEL을 의미한다. (=접근 권한이 없는 경우)

 

• [403 Forbidden] 서버가 요청을 처리할 수 있지만, 권한이 없어 처리를 거부하는 경우
  ➡ 이 메서드를 인가(Authorization)으로 사용하면 된다. 본인확인은 되었지만 권한 없음
  
• [404 Not Found] 설명이 필요한가? 서버는 멀쩡하지만 클라이언트가 요청한 리소스가 없는 경우 발생한다.
  ➡ 또는 보안을 위해 [403 Forbidden]를 클라이언트에게 보여주고 싶지 않은경우, 404로 대체하기도 한다.

 

---

# 서버 오류 5XX

서버 자체가 응답이 없거나, 서버에서 처리 도중 오류(Exception등)이 발생한 경우 반환하는 코드이다.

서버에서 문제가 발생하면 전부 500을 반환하는 데, 클라이언트 오류인 경우 예외처리를 하여 400으로 바꿔주어야한다.

 

• [500 Internal Server Error] 서버에서 오류가 발생. 백엔드 오류가 발생하면 500 오류로 처리하면 된다.
• [503 Service Unavailable] 서버다운, 서버에 오류가 난 것이 아니라 일부로 서버를 꺼두는경우 사용한다.
  ➡ 예정된 작업이 있어 서버를 끈 경우 Retry-After 헤더 필드로 복구시간을 보내주기도 한다.

✔ 서버 오류는 정말 서버가 동작하지 않는 경우를 의미한다. 서비스의 예외 케이스가 아니다.

예) 잔액이 0원이라 출금이 불가능한 경우, 400으로 해결해야한다. 이는 오류가 아니라 비즈니스 로직의 일부이다.

예) 로그인이 안되어 접근불가능하다면 401로, 로그인은 되었지만 접근 권한이 없다면 403, 404로 처리한다.