HTTP 상태코드
상태코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알라주는 기능
→ Request 이후 응답이 올때 처리가 잘 됐는지, 문제가 있는지를 알려주는 기능
1xx (Informational) : 요청이 수신되어 처리중 → 거의 사용 되지 않는다.
2xx (Successful) : 요청 정상 처리 → 200, 201등 200번대 코드가 많다.
3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
🤔모르는 상태 코드가 나타나면 어떻게 하나요?
클라이언트가 인식할 수 없는 상태코드나 정의 되지 않은 상태 코드가 반환되면 클라이언트는 사우이 코드로 해석해서 처리한다.
ex) 404 → 4xx(Client Error)로 해석!
미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
→ 물론 상태 코드를 잘 이해하고 더 좋은 문제를 해결할 수 있게 나중에 패치 되어도 좋다.
1xx (Informational) - 요청이 수신되어 처리중
거의 사용되지 않으므로 다음에 알아보자 (넘어가기)
2xx (Successful) - 클라이언트의 요청을 성공적으로 처리
200 OK : 요청 성공
클라이언트 요청을 성공했다는 뜻으로 대표적이다
201 Created : 요청 성공해서 새로운 리소스가 생성됨
클라이언트는 POST를 통해 서버에 요청을 하면 서버는 요청한 리소스의 처리를 하고 응답 메시지에 Location헤더를 추가하여 URI 정보를 담은 뒤 클라이언트에 보낸다. → 이때 201 Created라고 보낸다.
✏️ 복습
POST는 서버에서 자원을 생성한다
자원에 대한 URI도 서버에서 관리한다.
이러한 방식을 컬렉션이라고 한다
202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
배치 처리 같은 곳에서 사용한다고 한다
→ 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리한다고 할때 사용 (202는 잘 사용하진 않음)
204 NO Content : 웹 문서 SAVE 누를 시 해당
→ 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없을때 활용한다.
요청을 하면 서버는 응답 값을 보내는데 이때 응답 메시지 바디에 데이터가 있다. 그런데 성공적으로 응답을 할때 응답 페이로드 본문(메시지 본문)에 보낼 데이터가 없을떄 204 No Content라고 보낸다.
예를들어 웹 문서 편집기에서 SAVE 버튼을 누를때는 아무 내용이 없어도 된다.
→ 대신 실패했을떈 실패했다고 알려줘야한다.
즉 결과 내용이 없어도 수행한 엑션에 대해 204만으로 성공을 인식할 수 있다.
🤔상태 코드를 다 사용하면 좋나요?
그렇지 않다! 실제로 거의 200을 사용하거나 201까지만 사용한다. 개발할 때는 팀끼리 어느 정도 범위까지 잡고 개발할지를 정하고 개발하는 것이 좋다.
3xx (Redirection) - 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
)
서버거 요청을 완료 하려면 뭔가 추가적인 작업이 필요해 라고 클라이언트(웹 브라우저)한테 다시 보낸다.
300 (Multiple Choices)
301 (Moved Permanently)
302 (Found)
303 (See Other)
304 (Not Modified)
307 (Temporary Redirect)
308 (Permanent Redirect)
🤔리다이렉션이 무엇인가요?
그림처럼 옛날 이벤트 페이지를 요청했지만 사용자 입장에서 보면 바로 브라우져 URL에 “/new event”로 바뀌면서 새로운 페이지가 나타난다.
이처럼 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 데이터 위치로 자동으로 이동합니다. 이런 흐름을 리다이렉션이라고 합니다.
리다이렉션의 종류
-
영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동한 경우를 리다이렉션이라고 한다.
멤버 리소스 → 유저 리소스로 변경 -
일시 리다이렉션 - 일시자으로 변경한 경우 (잠깐 이동시킬때)
주분 완료 후 주문 내역 화면으로 이동하거나 PRG(Post/Redirect/Get) 등 사용할때 -
특수 리다이렉션
클라이언트에 있는 캐시의 기간 만료 여부 확인시에 사용한다.
영구 리다이렉션 (301, 308)
리소스의 URI가 영구적으로 이동하거나 원래의 URL을 사용하지 않을때 301, 308 상태코드를 사용한다.
→ 301과 308은 리소스 경로가 완전히 바꼈다는걸 알려준다.
- 301 (Moved Permanently)
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음 (아닐 수도 있음)
하지만 거의 이렇게 동작한다 (본문이 제거 된다는거에 초점을 맞출것)
- 308 (Permanent Redirect)
301과 기능은 같다.
리다이렉트시 요청 메서드와 본문을 유지한다(처음 POST를 보내면 리 다이렉트도 POST를 유지한다.)
→ 바디 데이터가 유지된다!
근데 실무에선 거의 안쓴다 리소스가 바뀌면 형식이 거의 바뀌기 때문!
일시적인 리다이렉션 - 302, 307, 303
리소스의 URI가 일시적으로 바뀔때 사용된다. (실무에서 많이 사용!)
따라서 검색 엔진 등에서 URL을 변경하면 안된다!
- 302 Found
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. → 301과 비슷함 - 307 Temporary Redirect
302와 기능은 같다.
하지만 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다! 절대!) - 303See Other
302와 기능은 같다.
리다이렉트시 요청메서드가 GET으로 바뀐다. → 반드시 GET 바뀐다
→ 대부분 프레임 워크에서 302를 리다이렉션 기능에서 디폴트로 사용한다. 또한 302를 기준으로 307과 303의 차이를 확인해보자
PRG (Post/Redirect/Get) - 일시적인 리다이렉션
만약 주문하기 버튼을 누르고 F5 를 눌러 새로고침을 하면 중복 주문이 될까?
POST로 주문후에 새로 고침으로 인한 중복 주문을 클라이언트에서 방지하는게 사용자 사용성에서도 훨씬 좋다.
→물론 서버에서도 막아야 된다. (이런 경우 “이미 사용된 주문번호입니다”라고 서버에서 잘 막아 놓는다.)
POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트하게 되면 클라이언트에서는 새로고침을 해도 중복 주문 대신 결과 화면을 GET으로 다시 요청하게 된다.
PRG 이후 URL이 이미 POST에서 GET으로 리다이렉트 되므로 새로고침을 해도 GET으로 결과 하면만 조회된다. → 이렇게 하면 사용성이 좋다. 또한 서버 입장에서 오류가 줄어든다. 그리고 결제 도중에 새로고침 생각보다 많이한다.
정리 -302, 307, 303
307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다.
자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제는 없다.
기타 리다이렉션 - 300, 304
- 300 Multiple Choices → 안쓴다. (생략!)
- 304 Not Modified
캐시를 목적으로 사용 → 네트워크 다운로드 용량이 줄어들게 된다.
****304 응답은 응답에 메시지 바디를 포함하면 안된다.(로콜 캐시를 사용해야 하므로!)
또한 조건부 GET, HEAD요청시에 사용된다.
4xx (Client Error) - 클라이언트 오류
클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없다. → 오류 원인이 클라이언트에 있다!
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패한다
400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
요청 구문, 메시지 등이 리소스 스페겡 맞지 않을때 주로 오류가 난다. 결국 클라이언트는 요청 내용을 다시 검토하고 보내야 한다.
예시) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을때 발생한다.
문자로 보내야 되는데 숫자로 보낼때 백엔드에서는 철저하게 막아야한다. 그리고 500번때로 보내면 안되고 400번떄로 보내야 된다. 그래야 클라이언트 개발자도 필요한 벨리데이션을 만들 수 있다.
401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
- 쉽게말해 인증이 안된다는 뜻이다.
- 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
🤔 인증과 인가의 차이가 무엇인가요?
인증(Authentication): 본인이 누구인지 확인 하는 행위 (로그인)
인가(Authoriztion): 권한부여(Admin 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있다. →레벨관련 문제임)
오류 메시지가 Unathoried 이지만 인가 관련 오류가 아닌 인증 관련 오류다.(이름이 넌센스임)
403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
→ 쉽게 말해 로그인은 되지만 접근 권한이 없다는 뜻이다.
예) 어드민 등급이 아닌 사용자가 로그인은 햇지만, 어드민 등급의 리소스에 접근하는 경우 403 오류를 낸다!
404 Not Found : 요청 리소스를 찾을 수 없음
요청 리소스가 서버에 없거나 페이지가 없는 경우 해당 오류를 낸다.
또는 클라이언트가 권한이 부족한 리소스에 접근할 경우에 해당 리소스를 숨기고 싶을때 오류를 보낸다.
5xx (Server Error) - 서버 오류
서버 문제로 오류가 발생했을 때 해당 오류를 보낸다.
서버에 문제가 있기 때문에 클라이언트가 나중에 똑같은 요청을 보내도 성공할 가능성이 있다.
500 Internal Server Error : 서버 문제로 오류 발생
서버 내부 문제로 생긴 오류일때 해당 오류 메시지를 보낸다. → 백엔드에서 발생한 애매한 오류는 500으로 내면된다!
503 Service Unavailable : 서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업(서버 다운 등)으로 잠시 요청을 처리할 수 없을때 해당 오류를 보낸다.
- Retry-After 헤더 필드로 얼마뒤에 복귀되는지 보낼 수 있다.
- 하지만 예측불가 오류여서 503을 보는 경우는 드물다.
정리
-
500대 에러는 서버에서는 웬만하면 만들면 안된다. 서버가 진짜 문제가 터졌을때 에러를 만들어야 한다. 그래서 500이 발생하면 서버에 심각한 문제가 있다고 모니터링을 한다.
-
예를들어 클라이언트의 주문 정보가 다 맞지만 잔고 부족인 경우 500을 보내면 안된다.
→ 클라이언트에서 보내준 스펙들이 다 맞고 서버쪽 로직도 맞으면 정상이다! 그리고 잔고 이런건 예외처리다! -
나머진 400이나 200으로 해결 가능하다.
