HTTP 웹 기본 지식 - HTTP 상태코드

상태 코드

클라이언트가 요청을 보내면 응답을 하는데, 거기서 응답 코드에 따라 어떤 상태인지 나타내는 상태 코드라는 것이 있다.

1xx, 2xx, 3xx, 4xx, 5xx가 있는데 각각의 상태 코드는 뜻하는 바가 다르다.

그래서 해당 상태 코드를 보고 어떠한 점이 잘못된지 알고 수정하면 된다.

 

1xx

처리 중이라는 뜻으로 거의 사용하지 않는다고한다.

 

2xx

요청을 성공적으로 처리했다라는 뜻을 가진다. 

 

get을 이용해 멤버를 조회했을 때 응답 메시지에 200 OK를 볼 수 있다.

 

post를 이용해 멤버를 등록하면 201 Created를 볼 수 있다. 

여기서 생성된 리소스의 위치는 응답 메시지의 Location을 보면 알 수 있다.

 

202 Accepted는 요청이 접수됬는데 처리가 완료되지 않았다는 뜻이다.

잘 사용하지 않는다고 한다.

 

204 No Content는 서버가 성공적으로 요청을 수행하고 응답보낼 데이터가 없을 때 볼 수 있다.

언제 이런 경우가 나올까?

우리가 웹 브라우저에서 웹 문서 편집기를 이용할 때, 텍스트를 입력하고 저장을 한다고 생각해보자

저장을 누르면 데이터가 서버에 넘어가고, 서버에서 저장을 하고 난뒤 응답을 내려줘야한다.

여기서 응답에 내려줄게 있을까? 없을까? 당연히 없겠지? 그래서 204를 보낸다.

 

그래서 주로 200, 201정도까지만 범위를 잡고 사용하는 것이 좋다고 한다.

 

---

3xx

리다이렉션이 좀 복잡하다고 한다. 

요청이 들어오면 서버가 *유저에이전트에게 요청을 받아들이려면 뭔가 추가적인게 필요해 라고 말하는 것이라고 한다.

그리고 클라이언트에게 다시 보낸다.

 

유저 에이전트 : 클라이언트 프로그램 주로 웹 브라우저

 

301 ~ 308이 중요하다고 한다.

 

영구 리다이렉션

영구 리다이렉션은 301, 308로 리소스의 URI가 영구적으로 이동한다는 뜻이다.

예로 처음 이벤트를 진행했을 때 /event를 사용했다고 하자.

다음 이벤트 때는 /new-event를 사용한다. 그렇다면 전의 사용자들은 처음 이벤트 진행했던 곳을 북마크를 해놓았을 때,

또 다시 /event를 들어가게 된다. 그러면 요청을 할 때, 서버의 입장에서는 /event를 쓰지 않는데 하면서 이 경로를 안쓰고 다른 경로로 바꼈어라고 말해줌.

301 Moved Permanently로 영원히 이동했다 이걸 메시지로 보내면 웹 브라우저가 301코드에 location 헤더 필드가 있네? 라고 인식을 하고, location을 URL창으로 바꾸고 이동한다.

즉, /event를 /new-event로 웹 브라우저가  URL창에 검색하고 이동시킨다는 것이다.

그래서 서버에 다시 해당 경로를 요청하고 서버는 200 OK를 보내지 않을까

 

301 과 308은 기능은 경로가 완전히 바뀌었다로 같지만, 한 가지 중요한 차이점이 있다.

 

301은 /event에 post로 이벤트에 참여하는 사람을 등록한다고 가정해보자.

그러면 당연히 301이 나와서 Location : /new-event로 뜰 것이다. 

그렇다면 바뀐 URI로 요청을 보낼텐데., 이 때 POST를 그대로 사용하지 않고 http 메서드가 get으로 바뀌게 된다.

예로 우리가 /event에 이벤트를 등록하려고 회원 정보를 작성하고 요청을 했는데, /new-event로 바뀌면서 새로운 이벤트 화면으로 넘어가게 되고, 메시지 바디 부분이 다 사라져서 작성했던 것을 처음부터 다시 작성해야한다.

 

308은 POST로 /event에 요청을 하고 308이 와서, 다시 요청하게 되면 그대로 POST를 재요청한다.

 

 

일시적인 리다이렉션

 영구적인 리다이렉션과 다르게 다음에 URI가 또 어떻게 바뀔지 모르기 때문에 요청해주는 대로 나가야함.

실무에서는 일시적 리다이렉션을 많이 사용한다고 한다.

302, 307, 303이 있는데

302는 301과 비슷하다. 메시지 바디 부분이 제거될수도, 안될수도 있다. 대부분 변한다고는 한다.

여기서 명확하지 않는 점을 보완(?)하기 위해 무조건 get으로 보내고 싶어 303이 생겼다.

 

그래서 307은 유지, 303은 명확하게 get으로 변경, 302는 대부분 get으로 바꾸지만 명확하지 않다라고 한다.

 

일시적 리다이렉션에서 PRG라는 것이 있다.

예로 우리가 post로 주문을 한 뒤에 새로고침을 하게 되면 ( = 재요청) 중복 주문이 될 수 있다. 결제가 두 번 된다는 말이다.

그래서 이러한 것을 방지하기 위해 post로 주문을 한 뒤, 새로 고침을 해도, 주문한 것을 get으로 조회하는 것이다!

그래서 POST - Redirect - Get으로 PRG라고 한다.

그렇다면 당연히 get이기 때문에 중복 주문이 되지 않고, 단지 주문 데이터를 조회하는 것 뿐이다.

이 때 302 Found를 사용하게 된다.

 

기타 리다이렉션

기타 리다이렉션에는 300, 304가 있는데 300은 거의 안쓴다고 한다.

304가 중요하다

304 Not Modified는 예로 어떤 이미지가 있다고 생각해보자.

그래서 클라이언트가 이미지를 다운받으려고 하는데, 캐시에 있는지 없는지 모른다. 그리고 아마 캐시가 만료된 것 같아 서버에게 이미지를 요청하게 되면, 서버가 캐시에 있는거 써 데이터 안 줄거야라고 한다.

이러면 네트워크 다운 용량이 많이 줄어들게 된다. 그래서 캐시로 리다이렉트한다라고 생각하면 된다.

서버가 클라이언트에게 캐시에 있는 데이터 써라고 말하는 것과 똑같다. 

그래서 로컬 캐시를 사용하므로 메시지 바디를 포함하면 안된다.

 

---

 

4xx

4xx의 원인은 클라이언트에게 있다.

당연히 여러번 재요청해도 실패한다.

그러나 5xx는 예로 서버 db에 오류가 났다고 하자. 그러면 db는 복구가 되고나서, 클라이언트가 재요청을 하게 되면 성공할 가능성이 있다. 이게 4xx와 5xx의 큰 차이라고 한다.

4xx 오류는 복구 불가능하다. 즉, 클라 자체가 틀리기 때문에 클라를 수정해야한다.

5xx 오류는 클라이언트를 수정하지 않아도 서버의 오류를 고치고 재요청하면 성공할 수 있다.

 

---

 

5xx

5xx를 하면서 조심할 것이 있다고 한다.

웬만하면 서버에서는 5xx를 만들면 안된다. 정말 서버에서 문제가 터졌을 때 5xx를 보내야한다고 한다.

예로 고객의 잔고가 부족한데,  이 부분은 예외케이스이므로 이런 경우에는 5xx를 내면 안된다 

 

---

 

 

출처 : 인프런 모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 강사님)