[HTTP] 6. HTTP 상태 코드

안녕하세요!

오늘도 공부하고 왔어용

벌써 섹션6 까지 왔네요!!!!

아자아자 화이팅!!!

 

그럼 고고!!

---

1. 상태 코드

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

 

• 1xx: 요청이 수신되어 처리 중 (거의 사용X)
• 2xx: 요청 정상 처리
• 3xx: 요청을 완료하려면 추가 행동이 필요 (리다이렉트)
• 4xx: 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 5xx: 서버 오류, 서버가 정상 요청을 처리하지 못함

---

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

모르는 상태 코드가 나타나도 걱정할 필요가 없습니다.

예를 들어, 299라는 상태 코드로 응답을 받았습니다.

근데 우린 이걸 모르죠? 근데 200번대가 클라이언트가 요청을 성공했다라는 것은 압니다.

따라서, 우린 그냥 "아~ 클라이언트가 요청을 성공했구나~" 라고 파악하면 됩니다.

---

3. 상태 코드 1xx (Informational)

요청이 수신되어 처리 중

상태 코드 100번대는 거의 사용하지 않기 때문에 넘어가도록 하겠습니다.

---

4. 상태 코드 2xx (Successful, 성공)

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

 

상태 코드 200번대는 총 4개가 있습니다.

• 200: OK
• 201: Created (POST 등록)
• 202: Accepted
• 204: No Content

사실상 성공은 거의 200을 사용하고 가끔 201을 사용하는 정도입니다.

자세한 설명은 밑에서 그림과 함께 하도록 하겠습니다.

4-1. 200 OK

요청 성공

클라이언트가 서버한테 요청을 보내면 서버는 결과를 잘 출력하여 응답을 합니다.

출력에 성공하면 가장 많이 보는 케이스 입니다.

 

4-2. 201 Created

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

클라이언트가 서버한테 리소스를 POST 등록해달라고 보냅니다.

서버는 클라이언트가 보낸 것을 보고서 요청 성공해서 새로운 리소스가 생성되었다는 뜻인 201 상태 코드를 보냅니다.

클라이언트는 서버로부터 201 상태 코드를 받고, "아~ 200 시리즈니까 요청 성공했구나!"라고 인식을 합니다.

그리고,  201이니까 리소스가 생성이 되었고, Location 헤더가 있을 수 있다고 판단합니다.

4-3. 202 Accepted

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

 

배치 처리 같은 곳에서 사용합니다.

예를 들어, 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리합니다. 이러면 접수만 된거고 처리가 완료되지 않은 케이스 입니다.

어찌되었든 요청은 되었기 때문에 성공으로 들어가서 200번대 상태 코드 입니다.

잘 사용하지는 않습니다.

 

4-4. 204 No Content 

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

 

예를 들어, 웹 문서 편집기에서 save 버튼이 있습니다.

save 버튼의 결과로 아무 내용이 없어도 되고, save 버튼을 눌러도 같은 화면을 유지해야 합니다.

서버에서는 저장하고 나서 보낼 것이 없죠?

결과 내용은 없지만 204 메시지 만으로 성공을 인식할 수 있습니다.

---

5. 상태 코드 3xx (Redirection, 리다이렉션)

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

 

여기 설명에 나와있는 유저 에이전트란 클라이언트 프로그램을 뜻합니다. 즉, 주로 웹 브라우저를 뜻합니다.

종류는 총 7가지가 있습니다.

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

여기에서 300번은 거의 쓰지 않습니다.

301번부터 308번까지는 중요하므로 밑에서 자세히 설명하도록 하겠습니다.

 

5-1. 리다이렉션 이해

300번대를 시작하기 전에 먼저 리다이렉션이랑 리다이렉트의 뜻을 알고 가야 합니다.

리다이렉션

클라이언트가 요청하고픈 것을 서버한테 요청합니다.
서버가 요청을 완료하려면 추가적인 작업이 필요하다고 클라이언트한테 다시 전송합니다.
이 작업을 리다이렉션이라고 합니다.

 

그리고, 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동을 합니다.

이것을 리다이렉트라고 합니다.

 

그럼 자동 이동을 한다는 게 뭘까요?

요건 자동 리다이렉트 흐름을 알아야 합니다.

먼저, 클라이언트가 예전에 쓰던 이벤트 페이지 /event를 GET 메서드로 요청합니다.

하지만, 우리는 페이지가 바뀌어서 이젠 /new-event라는 경로를 사용합니다.

그래서, 서버 입장에서는 "/event 더 이상 안 쓰는데..? 이젠 경로 /new-event를 써." 라고 클라이언트한테 응답을 보냅니다.

그러면, 자동 리다이렉트가 되어서 클라이언트는 새로운 경로로 다시 서버한테 GET 메서드로 요청합니다.

마지막으로, 서버는 요청 성공했다고 200 OK를 클라이언트한테 응답을 보냅니다.

그러고 나서 사용자는 새 이벤트 페이지로 들어가는 거죠.

 

리다이렉션은 총 3가지 경우가 있습니다.

• 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동
  • 완전히 경로가 바뀌어서 옛날 경로를 더 이상 쓰면 안 됩니다.
  • ex) /members -> /users
  • ex) /event -> /new-event
• 일시 리다이렉션: 일시적인 변경
  • ex) 주문 완료 후 주문 내역 화면으로 이동
  • PRG: 자주 쓰는 패턴으로, Post/Redirect/Get을 뜻함. 밑에서 더 설명할 예정.
• 특수 리다이렉션: 결과 대신 캐시를 사용

 

그럼 본격적으로 밑에서 자세히 설명하도록 하겠습니다.

5-2. 영구 리다이렉션

301, 308

• 리소스의 URI가 영구적으로 이동합니다.
• 원래의 URL를 사용하면 안 되고, 검색 엔진 등에서도 변경을 인지해야 합니다.
  • 만약에 경로가 /event에서 /new-event로 바뀌면 검색엔진에서도 바뀐 것을 알고 /new-event를 써야합니다.
• 301 Moved Permanently
  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있습니다.
  • POST로 요청을 해도 GET으로 변합니다.
• 308 Permanent Redirect
  • 301과 기능은 같습니다.
  • 리다이렉트 시 요청 메서드와 본문을 유지해야 합니다. (처음 POST를 보내면 리다이렉트도 POST 유지)
• 301과 308 둘 다 기능은 경로가 영구적으로 바뀌었다는거 알려준다는 점!!

5-2(1). 영구 리다이렉션 - 301

클라이언트에서 이벤트 페이지에 등록을 원해서 /event에 POST 메서드로 메시지를 입력해서 요청합니다.

그러면 서버에서는 경로가 영구적으로 바뀌었다고 클라이언트한테 301 응답 코드를 보냅니다.

클라이언트에서는 경로가 영구적으로 바뀌었다는 사실을 확인하고 새로운 경로로 변경한 뒤 서버한테 GET으로 한 번 더 요청합니다.

서버는 클라이언트한테 새 이벤트 페이지를 보냅니다. 이 때, 기존에 POST로 보냈던 메시지는 사라졌습니다.

클라이언트는 "아.. 다시 메시지 보내야하네.." 하고 서버한테 다시 메시지를 보냅니다.

 

이런 점을 해결하기 위해 308로 해결을 하였습니다.

5-2(2). 영구 리다이렉션 - 308

클라이언트에서 아까처럼 이벤트 페이지에 등록을 원해서 /event에 POST 메서드로 메시지를 입력해서 요청합니다.

이번에는 서버에서는 경로가 영구적으로 바뀌었다고 클라이언트한테 308 응답 코드를 보냅니다.

클라이언트에서는 경로가 영구적으로 바뀌었다는 사실을 확인하고 새로운 경로로 변경한 뒤에 POST 메서드를 유지해서 메시지를 보냅니다.

그러면 서버에서는 이벤트 참여 완료되었다고 클라이언트한테 성공 응답코드 200번을 보냅니다.

 

실무에서는 페이지가 바뀌면 완전히 바뀌는 경우가 많아서 308번보다는 301번을 씁니다.

근데.. 사실 영구 리다이렉션은 많이 쓰지는 않고 밑에서 설명할 일시적인 리다이렉션을 많이 씁니다.

5-3. 일시적인 리다이렉션

302, 307, 303

• 리소스의 URI가 일시적으로 변경됩니다. (나중에는 안 바뀔 수도..?)
  
  • 검색 엔진 등에서 URL을 변경하면 안 됩니다. (요것이 영구적인 리다이렉션과의 차이점)
• 302 Found
  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있습니다. (301이랑 상황 같음, 명확하지 않은 GET 변경..)
  • GET으로 변할 수 있다고 했는데 사실 대부분 변하고 제거됩니다.
• 307 Temporary Redirect
  • 302와 기능은 같습니다.
  • 리다이렉트 시 요청 메서드와 본문을 유지합니다. (요청 메서드를 변경하면 절대 안 돼요!!)
  • POST로 보내면 POST를 유지해야 합니다.
• 303 See Other
  • 302와 기능은 같습니다.
  • 리다이렉트 시 요청 메서드가 GET으로 변경됩니다. (302보다 명확히 GET으로 변경)
  • 근데 원래 걍 GET으로 변경해도 되는거면 302를 써도 됩니다.

 

5-3(1). PRG: Post/Redirect/Get (일시적인 리다이렉션 - 예시)

PRG 요걸 과연 언제 쓸까요?

밑에서 설명을 해보겠습니다.

 

<PRG 사용 전>

만약에 상품을 주문하려고 주문 페이지에 메시지를 등록했습니다. (POST 메서드 이용)

그러고 상품 주문하기 버튼을 눌렀습니다.

그러면 POST로 내 메시지가 넘어갑니다.

그렇게 주문이 완료되어 결과가 남아있는 상태고, 실수로 웹 브라우저를 새로고침 해버렸습니다.

경고창은 뜨지만 YES까지 눌러버리면 POST 정보 다시 들어가서 중복 주문이 되어버릴 수 있습니다.

 

<PRG 사용 전 과정>

클라이언트가 서버한테 /order 페이지에 POST로 메시지 등록을 요청합니다. (주문)

서버가 요청을 받아서 확인해보니 상품 주문이 들어왔네요? 하고 주문 데이터에 상품을 저장합니다.

서버가 클라이언트에게 200 OK 상태 코드와 함께 주문 완료가 되었다고 보냅니다.

 

이렇게 되면 지금 현재 POST 요청이 마지막 요청이 됩니다.

엇 근데 또 왜 이러실까요? 실수로 새로고침 하셨네요..;;

새로 고침 하지 말랬지.

 

이러면 클라이언트가 POST 마지막 요청을 서버한테 다시 보냅니다.

그럼 또 앞선 과정을 다시 반복하게 됩니다. (주문데이터가 1건 더 들어오게 됩니다.)

결국 또 주문 완료.. 재주문이 되어버렸습니다~~

놀리지마. 빵빵아.

 

 

<PRG 사용 후 - 해결>

• POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
• POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로 고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청 -> 결과 화면만 계속 나옴

 

<PRG 사용 후 과정>

클라이언트가 /order 페이지에 POST 메서드를 이용해서 서버한테 상품 주문 메시지 등록을 요청합니다.

요청이 들어가면 서버가 DB에 주문 상품 데이터를 저장합니다.

서버가 응답을 200 OK가 아닌 302 Found(303 보내도 됨)를 보냅니다. 그러고 Location 정보를 줍니다. (ex. 19번 주문)

클라이언트가 "오! 302번 상태 코드가 왔네?" 하고 자동 리다이렉트 합니다.

그러고 클라이언트가 GET으로 바뀝니다.

서버는 19번 주문 데이터를 조회해서 html 화면(결과 화면)을 만들고 200 OK를 보냅니다.

 

이렇게 되면 실수로 새로 고침해도 GET 요청(5번)으로 다시 이동을 합니다.

해결 완료!

 

<PRG 이후 리다이렉트>

• URL이 이미 POST -> GET으로 리다이렉트가 되었습니다.
• 새로 고침해도 GET으로 결과 화면만 조회가 됩니다.
  • 사용자 입장👧🏻: 사용성이 좋아집니다. (경고창도 없고! 실수로 새로 고침해도 문제가 없고!)
  • 서버 입장💻: 오류가 줄어서 좋아집니다. (같은 주문 번호면 재주문이 되지 않게 막습니다.)

 

5-3(2). 그래서 뭘 써야 할까?

302, 307, 303

• 정리!!
  • 302 Found: GET으로 변할 수 있습니다. (거의 GET으로 변함)
  • 307 Temporary Redirect: 메서드가 변하면 안 됩니다.
  • 303 See Other: 메서드가 GET으로 변경되어야 합니다.
• 역사
  • 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었습니다.
  • 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버렸습니다. (일부는 다르게 동작)
  • 그래서 모호한 302를 대신하는 명확한 307, 303이 등장했습니다. (301 대용으로 308도 등장)
• 현실
  • 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용합니다.
  • 자동 리다이렉션 시에 GET으로 변해도 괜찮은 거면 그냥 302를 사용해도 큰 문제는 없습니다.

 

5-4. 기타(특수) 리다이렉션

300, 304

• 300 Multiple Choices: 안 씁니다.
• 304 Not Modified: 많이 쓰는데, 더 자세한 내용은 뒷 섹션에서 더 설명할 예정.

304에 관해서 조금 더 설명을 하자면...

결과 대신에 캐시를 사용합니다.

그리고, 클라이언트한테 리소스가 수정되지 않았음을 알려줍니다.

따라서, 클라이언트는 로컬 PC에 저장된 캐시를 재사용합니다. (캐시로 리다이렉트 함)

또한, 304 응답은 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안 됩니다.

마지막으로, 조건부 GET, HEAD 요청 시 사용합니다.

 

과정을 설명하자면, 클라이언트한테 캐시가 있는데 기간이 만료된 것 같아서 서버한테 캐시 기간 만료된 거 맞냐고 생성 일자 등의 정보를 넘기고서 물어봅니다.

그러면 서버가 보고서 클라이언트한테 캐시 그냥 계속 써도 될 것 같다고 캐시해서 다시 조회하라고 응답을 보냅니다.

 

---

6. 상태 코드 4xx (Client Error, 클라이언트 오류)

클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음

오류의 원인이 클라이언트한테 있습니다.

또한, 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도는 실패합니다!!!! 중요!!!

 

500번대와 차이점은 400번대는 똑같은 재시도가 실패하지만...

500번대 오류는 DB 복구되면 똑같은 재시도가 성공할 수도..?

 

6-1. 400 Bad Request

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

요청 구문, 메시지 등등의 오류가 났을 때 뜨는 상태 코드 입니다.

클라이언트는 요청 내용을 다시 검토하고 보내야 합니다.

 

예를 들면, 요청 파라미터가 잘못되었거나 API 스펙이 맞지 않을 떄..?

더 쉬운 예시를 들자면, 숫자를 보내야하는데 문자를 보냈을 때

 

6-2. 401 Unauthorized

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

인증(Authentication)이 되지 않았을 때 뜨는 상태 코드 입니다.

401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명합니다.

 

<참고해야 할 용어 - 헷갈릴 수 이쒀요>

• 인증(Authentication): 본인이 누구인지 확인 (로그인, 로그인이 일단 안 되면 인증이 안 됩니다.)
• 인가(Authorization): 권한 부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있습니다.)

6-3. 403 Forbidden

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

주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우에 나타나는 상태 코드 입니다.

예를 들어, ADMIN 등급이 아닌 사용자가 로그인은 했지만, ADMIN 등급의 리소스에 접근하는 경우..?

들어오면 짱구 대신 오수가 반겨줌

오수가 누구냐고?

얘.

6-4. 404 Not Found

요청 리소스를 찾을 수 없음

이 상태 코드는 많이 봤을 것입니다. 그래서 중요한데요.

요청 리소스가 서버에 없을 때 혹은 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 있을 때 나타나는 상태 코드 입니다.

 

- 서버: 클라이언트야! 난 이 리소스 너한테 제공해줄 수 없어!

- 클라이언트: 😭

---

7. 상태 코드 5xx (Server Error, 서버 오류)

서버 문제로 오류 발생

서버에 문제가 있어서 발생한 오류이기 때문에 재시도 하면 성공할 수도 있습니다. (복구가 되거나 등등)

 

7-1. 500 Internal Server Error

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

서버 내부 문제로 오류가 발생하면 나타나는 상태 코드 입니다.

애매하면 500 오류래요.

 

7-2. 503 Service Unavailable

서비스 이용 불가

서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때 나타나는 상태 코드 입니다.

Retry-After 헤더 필드로 얼마 뒤에 복구가 되는지 보낼 수도 있습니다.

 

근데 요걸 보는 경우는 거의 없고 본다면 500 위주로 보겠죠.

왜냐하면, 왠만하면 서버에서는 500번대 오류를 만들면 안 되기 때문입니다.

진짜 서버에 문제가 터졌을 때 500번대 오류를 만듭니다.

서버 문제 생기지 마랏

---

그럼 끄읕

이번에만 짤 많이 쓴거고 짤 쓰기 귀찮아서 다음 섹션부터는 거의 안 쓸 예정.