HTTP 상태코드

네트워크

HTTP 상태코드

ssung 2022. 3. 14. 22:51

HTTP는 응답 결과에 따라서 상태코드를 반한환다.

1XX (Informational) : 요청이 수신되어 처리중
2XX (Successful) : 요청 정상 처리
3XX (Redirection) : 요청을 완료하려면 추가 행동이 필요
4XX (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
5XX (ServerError) : 서버 오류, 서버가 정상요청을 처리하지 못함

모든 상태코드를 다루기에는 양이 너무 많기 때문에 주로 사용하는 상태코드 위주로 알아보자.

1xx는 실무에서는 거의 사용되지 않는 상태코드 이므로 2xx부터 알아보도록 하자.

2XX

클라이언트의 요청이 성공됐을 때 반환되는 코드이다. 뒤에 나오는 숫자에 따라서 특징이 조금 다를 뿐 성공에 대한 코드라는 것은 동일하다.

실제로 개발을 할 때 세부적으로 코드의 종류를 나눠서 사용하는 경우도 있겠지만 대부분 200으로 처리하는 경우가 많다. 이 부분은 개발하는 입장에서 내부적으로 결정된 사항에 따라서 사용하면 된다.

200 OK
201 Created
202 Accepted
204 No Content

200 OK

요청이 성공적으로 이루어졌을 때 나타난다.

201 Created

요청에 성공해서 새로운 리소스가 생성되었음을 나타낸다.

POST등의 요청으로 게시글을 생성했을 때 응답메세지에 새로 생성된 리소스의 URI를 넣어서 보내줄 수 있다.

202 Accepted

요청이 접수는 되었으나 아직 처리가 되지 않았음을 나타낸다.

들어온 요청이 당장 처리되는 것이 아니라 1시간 뒤에 배치가 돌아야 실행되고 처리되는 경우에 202를 사용한다.

204 No Content

응답시에 body에 내용이 없을 때 보내는 코드이다.

3XX

300번대의 응답코드는 리다이렉션 코드이다. 요청을 완료하기 위해서 추가작인 작업이 필요하다는 의미의 코드이다.

리다이렉션은 서버에서 받은 URI가 더이상 사용하지 않는 URI일 때 다른 URI로 다시 보내는 작업을 의미한다.

예를 들어, 특정 페이지가 있는데 이제 이 페이지를 사용하지 않고 다른 페이지를 새로 만들어서 사용하고있다고 해보자. 그런데 사용자 중에서 이미 이 페이지를 즐겨찾기나 북마크로 지정해놓았을 수도 있다. 이런 상황에서 사용자가 사용하지 않는 페이지로 접근했을 경우 서버에서 응답메세지에 Location에 바뀐 URI를 보내주어 클라이언트에서 바뀐 URI로 다시 요청을 하는 상황을 리다이렉션 이라고 한다.

리다이렉션은 크게 3가지로 나누어 볼 수 있다.

영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
일시 리다이렉션 : 일시적인 변경
특수 리다이렉션 : 결과 대신 캐시를 사용

영구 리다이렉션

위에 이야기한 예시와 같은 상황을 영구 리다이렉션이라고 할 수 있다. 기존의 URI를 사용하지 않고 완전히 새로운 URI를 사용하는 경우이다.

영구 리다이렉션의 상태코드로는 301과 308을 사용한다. 이 둘은 거의 비슷하지만 약간의 차이가 있다.

두 상태코드는 요청한 URI가 없을 경우 리다이렉션으로 Location을 받아서 변경된 URI로 다시 요청을 보내는 것이다.

여기서 차이점은 변경된 URI로 다시 요청을 보냈을 때이다.

301은 다시 요청을 보낼 때 HTTP메소드를 GET으로 고정하고 message body에 있었던 내용들도 전부 제거할 수 있다. 한 마디로 순수하게 다시 GET요청을 보내는 것이다. 하지만 308은 처음 보낸 HTTP메소드와 데이터를 그대로 유지한 채 다시 요청하게 된다.

예를 들어, form태그에 title과 content를 json으로 데이터를 담아서 POST로 요청했다고 해보자.

{
	"title" : 제목,
	"content" : 내용
}

이런 형식의 데이터 일것이다. 이때 301을 받은 클라이언트는 변경된 URI로 다시 요청할 때 처음에 보낸 json의 데이터를 없애고 HTTP메소드도 GET으로 바꾼 후 순수하게 페이지 요청을 다시하게된다. 이렇게 된다면 바뀐 URI는 아무 데이터도 유지하지 못한 채 view를 호출 할 것이다.

308의 경우는 POST메소드와 json데이터를 전부 유지한 채 바뀐 URI를 호출하게 된다. 이렇게 되면 기존의 데이터를 유지한채 URI를 호출하는 것이기 떄문에 데이터를 유지한채 view를 호출 할 수 있다.

이렇게 보면 308이 더 좋다라고 느껴질 수 있지만 사실 308은 잘 사용되지 않는다. URI가 바뀌었다는 것은 설계적으로 많은 것이 바뀌었고 즉 넘어가는 데이터의 종류가 바뀌었을 수가 있다. 그렇기 때문에 그냥 페이지를 호출하고 다시 데이터를 입력하게 하는 것이 더 좋을 수 있다.

일시 리다이렉션

영구 리다이렉션과 거의 비슷하다. 사용되는 상태코드는 302, 303, 307이 있다.

302 : 바뀐 URI로 요청할 때 HTTP메소드를 GET으로 바꾸고, 본문의 내용을 제거하고 보낸다. 위에서 설명한 301상태코드와 같다고 보면된다.
303 : 302와 기능은 같으나 반드시 HTTP메소드를 GET으로 해야한다.
307 : 302와 기능은 같으나 리다이렉트 요청 시 요청메소드와 본문을 반드시 유지해야한다.

언뜻보면 차이점이 없는 것 같지만 302는 GET으로 할 수도 있고, 본문의 내용을 제거할 수도 있는 것이다. 대부분은 GET으로하고 본문의 내용을 제거하지만 그렇지 않을 수도 있다는 것이다. 하지만 303과 307은 반드시 그렇게 지정한대로 해야한다는 차이점이 있다.

기타 리다이렉션

300과 304가 있다.

300 : 거의 사용하지 않는 상태코드이다.
304 : 캐시 수정의 여부에 대한 응답이다.

304의 경우 정말 많이 사용하는 상태코드인데 클라이언트가 캐시가 만료되어 서버에게 데이터를 요청할 때 서버에서 데이터의 변경이 없으므로 기존 캐시를 그대로 사용해도 된다 라는 의미로 사용한다.

기존에 캐시를 그대로 사용하는 것이기 때문에 message body에 데이터가 들어가지 않는다.

GET과 HEAD메소드에서 사용한다.

4XX

클라이언트의 잘못된 요청으로 인한 에러

클라이언트가 잘못된 요청을 보낸 경우이기 때문에 아무리 재 요청을 하더라도 바른 응답을 받을 수 없다.

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found

400 Bad Request

요청 구문, 메세지 등등의 오류이다.

요청 파라미터가 잘못되었거나 숫자를 문자로 보내는 등의 API 스펙이 맞지 않을 때 나타난다.

401 Unauthorized

401에러는 인증이 되지 않은 경우에 나타난다. 인증(Authentication)과 인가(Authorization)는 분명히 다르다.

403 Forbidden

개발시에 가장 많이 접할 수 있는 에러일 것이다.

클라이언트가 요청한 리소스가 서버에 없을 때 나타난다.

클라이언트가 권한이 부족한 리소스에 접근시에 페이지를 숨기기 위해서 서버에서 임의로 이 에러를 나타내도록 할 수도 있다.

5XX

서버 문제로 발생

서버가 문제인 경우이므로 재 요청시에 서버에서의 문제가 해결된 상태라면 응답을 받을 수 있을수도 있다.

500 Internal Server Error
503 Service Unavailable

500 Internal Server Error

가장 많이 나오는 경우이며, 말 그대로 서버 내부에 문제가 발생한 경우이다.

애매한 경우에는 이 에러를 보낸다.

503 Service Unavailable

서버가 일시적인 과부화 또는 예정된 작업으로 인해 잠시 요청을 처리할 수 없는 경우이다.

Retry-After 헤더로 얼마 후에 복구되는지 보낼 수 있지만 현실적으로 작업시간을 예측하는 것은 힘들기 때문에 거의 보기힘든 에러이다.

저작자표시