Status Code(상태 코드)

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 코드이며 HTTP 응답 메세지에 담겨있다. 100번대, 200번대 ... 500번대 코드까지 존재하며 제일 앞자리에 큰 의미가 부여된다.(성공, 리다이렉션, 클라이언트 에러, 서버 에러)

만약 모르는 상태 코드가 발생할 경우, 예로 299의 상태 코드가 응답 메세지에 담겨있을 경우 상세한 이슈는 몰라도 200번대이기 때문에 요청이 성공했다는 것은 알 수 있다.

1xx(Informational)

거의 사용하지 않음. - 생략

2xx(Successful)

200 OK

200 OK는 HTTP 응답의 성공적인 상태를 나타내며, 보통 요청이 제대로 처리되었고 클라이언트가 원하는 결과를 받았음을 의미한다. 클라이언트 측은 요청한 작업이 성공적으로 완료되었음을 인식한다.

201 Created

201 Created는 요청이 성공했고 새로운 리소스가 생성되었다는 것을 알린다. 생성된 리소스는 응답메세지 Header의 Location에 담겨서 반환된다. 요청과 함께 보낸 데이터로 새로운 리소스 생성이 이루어졌을 경우 활용할 수 있다.

202 Accepted

배치 처리 같은 곳에서 사용된다. 요청은 성공적으로 접수되었으나 처리는 완료되지 않았음을 뜻한다. 처리의 완료시점이 시간이 걸리므로 중간정도의 성공이라고 보아야할 것 같다. 하지만 실패는 아니므로(처리를 시도하지 않았음) 200번대인 듯 하다.

204 No Content

서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 보낼 데이터가 없는 상황임을 말한다. 예로 문서 편집기능에서 save버튼을 설계한다고 했을 때 아무 데이터 수정없이 save를 눌러도 요청은 성공적으로 수행되어야 한다. 하지만 변화한 부분이 없으므로 같은 화면을 유지할 것이다.

3xx(Redirection)

300번대는 요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요하다는 것이다. 웹 브라우저는 3xx 응답코드의 HTTP메세지 헤더에 Location이 존재한다면 Location 위치로 자동 이동(redirect)한다.

리다이렉션은 영구 리다이렉션과 일시 리다이렉션 및 특수 리다이렉션으로 나뉜다.

영구 리다이렉션

301 Moved Permanently

리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음(아닐 수도 있다는 것)

308 Permanent Redirect

301과 기능은 같지만 요청 메서드와 본문을 유지한다.

보통은 같은 본문으로 새로운 POST를 진행하는 것은 권장되지 않으므로 우선 새로운 URI로 GET후에 다시 진행한다.

일시적 리다이렉션(normal)

302(normal) Found

리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음(아닐 수도 있다는 것)

307 Temporary Redirect

302과 기능은 같지만 요청 메서드와 본문을 유지한다.

보통은 같은 본문으로 새로운 POST를 진행하는 것은 권장되지 않으므로 우선 새로운 URI로 GET후에 다시 진행한다.

303 See Other

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

300번대 이해하기

일단 영구 리다이렉션과 일시적 리다이렉션의 차이를 알아야한다. 영구 리다이렉션의 경우 URI가 영구적으로 변경되었음을 의미하며, 검색 엔진 등이 새로운 URI를 기억하고 인덱싱할 수 있도록 한다. 반면 일시적 리다이렉션은 다시 이전의 URI로 돌아갈 여지가 충분히 있다는 것이다.

만약 리다이렉션 이전의 URI로 다시 접근할 여지가 충분할 경우 302를 응답해야한다. 예로 주문완료 후 나타나는 주문상세정보의 경우 말 그대로 일시적으로 존재할 페이지이므로 302가 옳다.

영구 리다이렉션에 해당하는 것은 무엇이 있을까. 누군가 과거에 존재하던 URI로 접근할 경우 새롭게 현재 사용중인 URI로 사용을 옮겨주어야 할 것이다. 과거버전에서 사용은 현재 제한적이기 때문이다. 이때 리다이렉션을 해줄탠데 과거버전으로 돌아갈 일이 있을리 없다. 그러므로 이는 영구 리다이렉션에 해당한다.

생각해보면 영구 리다이렉션의 상황보다 302의 상황이 압도적으로 많을 것이라는 예상이 가능하다.

303은 뭔데

과거에는 302만 존재했다. 이는 POST를 위한 응답코드였는데 리다이렉션시 POST를 유지하는 것이 상당히 불편했다. 당연하게도 리다이렉션된 리소스에서 요청메세지의 바디 부분이 바뀌어야 하는 것이 많기에 그렇다. 그래서 프로그래머들은 이를 수정해서 죄다 GET 메서드로 바꾸어 리다이렉션했다.

표준측에서 이를 고려하여 만든 것이 303인데, 여전히 302 GET 리다이렉션을 많이 사용한다.(그렇게 계속 사용해도 문제없다 - 너무 굳어져서... 처음부터 잘 만들지)

PRG(Post/Redirect/Get)

성공적인 POST후 200번대로 바로 응답하는 것이 아니라 일시적으로 POST 성공에 대한 리소스로 리다이렉트 시킨다.

• Post /order
• 302 Found Location: /order-result/19
• 302에 의해 자동적으로 GET /order-result/19
• GET 성공시 200 OK

PRG 방식을 사용하지 않을 경우에는 다음의 예시가 가능하다.

• POST /order
• 200 OK

아래의 경우에서, /order 위치에 그대로 사용자가 머물 것이다. 만약 이 상태에서 새로고침(F5)를 시도할 경우 다시 POST요청이 갈 것이다.

보통 이러한 중복 요청에 대해서는 백엔드에서 POST처리 이전에 에러를 뱉어주겠지만(400번대 에러) 애초에 이러한 에러로그가 잡히지 않도록 사용자의 플레이를 유도할 수 있다. PRG방식으로 설계하면 이러한 문제에서 벗어날 수 있다.

304 Not Modified

캐시를 목적으로 사용한다. 클라이언트에게 리소스가 수정되지 않았음을 알려준다. GET에서 주로 사용되며, 반복적인 GET 요청시 이전에 받았던 응답이 캐시되어있을 경우 서버쪽에서 응답을 주지 않고 캐시를 사용하라고 할 때 304를 보낸다.

그러므로 304 응답에는 메시지 바디를 포함하면 안된다.

4xx(Client Error)

오류의 원인이 클라이언트에 있으며 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없는 경우에 발생한다.

클라이언트가 이미 잘못된 요청 데이터를 보내고있기 때문에 똑같은 재시도를 여러번 하더라도 실패한다.

400 Bad Request

요청 구문, 메시지 오류 -> 클라이언트는 요청 내용 재검토해서 보내야함. 현재 요청이 API스펙에 맞지 않거나 요청 파라미터가 잘못되었을 경우가 많다.

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요한 경우로 WWW-Authenticate 헤더와 함께 인증 방법을 설명하는 응답이 나간다.

Authentication(인증)과 Authorization(인가)는 다르다. 인증은 로그인이 되었냐에 대한 것일거고 인가는 로그인이 되었어도 권한에 대한 것이다. ADMIN처럼 특정 리소스에 접근가능한 권한, 즉 인증이 있어야 인가가 존재한다.

403 Forbidden

서버가 요청을 이해했지만 승인을 거부하는 경우이다. 주로 인증 자격 증명은 있지만 권한이 불충분한 경우에 발생할 수 있다.

404 Not Found

요청 리소스가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근 시 해당 리소스를 숨기고 싶을 때 사용한다.(403이랑 중복해서 사용할 수 있겠다.)

5xx(Server Error)

서버 자체의 문제이며, 서버에 문제가 있기에 재시도할 경우 성공할 수도 있다.(서버가 복구되거나 데이터베이스가 복구되거나 등등)

500 Internal Server Error

자주 사용되는 500번대 상태 코드이며 애매할 경우 이 상태 코드로 서버에러를 표현한다. 뭉뚱그려 서버 내부에 문제가 있다는 뜻이다.

503 Service Unavailable

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