6. HTTP 상태 코드

1. HTTP 상태 코드

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

• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청완료 위해 추가 행동 필요
• 4xx (Client Error): 클라이언트 오류
• 5xx (Server Error): 서버 오류

 

처리중,정상,추가행동,클라이언트,서버

예를 들어 모르는 상태코드가 생긴경우 알아보자.

 

299 가 나왔다면 → 2xx 이므로 Successful

599 가 나왔다면 → 5xx 이므로 Server Error

 

클라이언트는 인식할 수 없는 상태 코드를 서버로부터 받으면, 상위 상태 코드로 해석해서 처리한다.

ex) 299모르니까 2xx로 성공 코드라고 생각

 

따라서 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

 

1. 1xx (Informational)

요청이 수신되어 처리중인 상태로, 거의 사용하지 않는다.

 

2. 2xx (Successful)

200 OK

• 클라이언트가 리소스를 달라고 요청하면 서버가 결과를 정상적으로 처리해서 응답한다.

 

201 Created

• POST는 서버에서 자원을 생성하고 URI도 관리하는데, 생성된 리소스의 경로는 응답의 Location 헤더 필드로 담아 보낸다.
• 응답이 201이면 자원이 생성된 것이고, Location 헤더 필드가 있다고 예측 가능하다.

 

202 Accepted

• 요청이 접수는 됐지만 처리가 완료되지 않았을 때 쓰인다. 예를들어 클라이언트 요청은 성공했는데 서버는 1시간 뒤에 배치를 돌려 처리해야 할 경우 사용된다.

 

204 No Content

• 보통 요청에 성공하면 응답 바디에 데이터가 있는데 요청을 성공적으로 수행해도 보낼 데이터가 없을 때 쓰인다.
• ex) 웹 문서 편집기에서 저장 버튼을 누르면 서버에서 저장 처리를 한 뒤 결과로 본문을 줄 필요는 없다. 정상적으로 저장됐다는 것만 전달하면 된다. 이럴 경우 결과 내용 없이 204로 성공을 알릴 수 있다.

 

3. 3xx (Redirection)

서버가 요청 완료를 위해 유저 에이전트(주로, 웹 브라우저)의 추가 작업이 필요할 때 사용

 

리다이렉션 이해

리다이렉트: 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 그 위치로 자동 이동

경로를 바꿨는데, 기존 유저가 이전 경로로 요청(1 요청)을 하면, 서버는 Moved Permanently (2 응답)를 알려주고, Location: /new-event로 새로운 경로를 주면, 클라이언트는 300대이고, Location 헤더필드가 있네? 아 경로가 바뀌었구나. 라고 인식해서 URL 주소를 웹브라우저가 바꾸고(3 자동 리다이렉트), 바뀐 경로로 다시 요청(4 요청)해서 바뀐 경로(5 응답)로 이동한다.

• 영구 리다이렉션
• 일시 리다이렉션
• 특수 리다이렉션

 

1)영구 리다이렉션(301, 308)

 

리소스의 URI가 영구적으로 이동

• 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
• 301 Moved Permanently

리다이렉트 시 요청 메서드가 GET으로 변하고, 본문(메시지 바디)이 제거될 수 있고, 그러면 클라이언트는 다시 새로운 주소로 POST로 기존 메시지를 보내서 요청한다.

 

• 308 Permanent Redirect

301과 기능은 같다. 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

실무에서는 영구 리다이렉션은 적게 사용한다.

 

2) 일시적인 리다이렉션(302, 307, 303)

 

리소스의 URI가 일시적으로 변경

• 따라서 검색 엔진 등에서 URL을 변경하면 안된다.

 

• 302 Found

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.

 

• 307 Temporary Redirect

302와 기능은 같다.

리다이렉트시 요청 메서드와 본문 유지하기에 요청 메서드를 변경하면 안된다.

 

• 303 See Other

302와 기능은 같다.

리다이렉트시 요청 메서드가 GET으로 변경된다.

 

PRG(Post/Redirect/Get)

 

3) 특수 리다이렉션(300, 304)

 

• 300 Multiple Choices: 사용하지 않는다.
• 304 Not Modified

 

캐시를 목적으로 사용한다.

클라이언트가 캐시가 만료됐는지 서버에 확인하기 위해 캐시 정보를 넘기고, 서버는 사용해도 되면 캐시로 다시 조회하라고 응답을 보낸다.

클라이언트에게 리소스가 수정되지 않았음을 알려주면 클라이언트는 캐시로 리다이렉트 해서 로컬 PC에 저장된 캐시를 재사용 한다.

로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안된다.조건부 GET, HEAD 요청 시 사용한다.

 

4. 4xx (Client Error)

 

클라이언트가 잘못된 요청을 해서 서버가 수행할 수 없을 때 사용한다.

5xx 에러는 재시도 하면 성공 할 수 있으나 4xx는 이미 클라이언트가 잘못 요청한 것 이기에 똑같이 재시도 할 경우 실패한다.

 

• 400 Bad request

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

클라이언트가 요청 내용을 다시 검토 및 요청해야 한다.

서버 개발자는 validation을 해줘야한다.

 

• 401 Unauthorized

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

응답에 www-Authenticate 헤더와 함께 인증방법을 설명해줘야 한다.

 

• 403 Forbidden

서버가 요청을 이해했지만 승인은 거부한 상태

인증 자격 증명은 되지만 접근 권한이 없을경웨 해당하며, 예를 들어 관리자가 아닌 사람이 관리자 페이지에 접근한 경우

 

• 404 Not Found

요청 리소스를 찾을 수 없는 상태

 

#인증과 인가

 

인증과 인가에 대해 알아보자. 항상 헷갈리는 부분

• 인증(Authentication)

본인이 누구인지 확인하는 것으로 (로그인)

로그인 할 수 있냐 없냐

 

• 인가(Authorization)

권한을 부여하는 것으로 ADMIN처럼 특정 리소스에 접근할 수 있는 권한

로그인한 후 이 리소스에 대해서 접근할 권한이 있냐 없냐

위에서 말한 401은 오류 메시지가 Unauthorized이지만 인증에 해당된다.

 

5. 5xx (Server Error)

 

서버에 문제가 있어서 발생하는 오류로 서버가 복구되면 재시도 시 성공 가능하다.

• 500 Internal Server Error

서버 내부 문제로, 애매한 문제는 대부분 500 오류로 낸다.

 

• 503 Service Unavailable

서비스 이용 불가로, 서버가 일시적인 과부하에 걸리거나 예정된 작업으로 잠시 요청을 처리할 수 없는 상태

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

대부분의 오류의 경우 예측 불가능한 오류로 500이 발생하는데, 서버에 문제가 터졌을 때만 발생시켜야 한다.

API 스펙이 맞는데 비즈니스 로직 실패라고 500을 내면 안되다.

예를들어, 잔고가 없다거나 필요한 연령 제한을 못넘겼다거나 하는 문제는 비즈니스 로직 상 정상 예외 케이스이므로 2xx, 4xx로 해결하고 DB 에러나 NPE 등의 문제에 500을 내야 한다.