[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (Redirection), 4xx (Client Error), 5xx (Server Error))
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 (HTTP API를 간단하게 작성해보기 - 문제 파악하기, HTTP
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 (HTTP API를 간단하게 작성해보기 - 문제 파악하기, HTTP 메서드 종류) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한..
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API 설계 예시) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HT.
vansoft1215.tistory.com
1. HTTP 상태코드란?
클라이언트가 서버로 요청을 보낼 때, 그 요청이 잘 처리되었는지 상태를, 응답(response)으로 알려주는 기능이다.
- 1xx (Informational) : 요청이 수신되어 처리중이다.
- 2xx (Successful) : 요청이 정상 처리되었다.
- 3xx (Redirection) : 요청을 완료하려면, 추가 행동이 필요하다.
- 4xx (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
- 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못한다.
2. HTTP 상태코드 - 1xx (Informational)
- 요청이 수신되어 처리중이라는 것을 나타낸다.
- 이는 실무에서 거의 사용되지 않는다.
3. HTTP 상태코드 - 2xx (Successful)
클라이언트가 보낸 요청이 성공적으로 처리되었다는 상태코드
1) 200OK
- 클라이언트가 보낸 요청을 잘 처리한, 대표적인 성공 안내 상태코드
- GET 요청의 경우 주로 응답하는 코드
2) 201 Created
- 클라이언트가 보낸 요청을 처리하는 과정에서, 서버가 새로운 리소스를 생성한 경우, 나타내는 성공 안내 상태코드
ex. 클라이언트가 POST를 통해 신규 자원을 등록해달라고 보내면, 서버에서 자원을 생성하고 uri에 대한 관리를 진행하게 된다. 이 때 응답하는 것이 201 Created이다.
- 생성된 리소스는 응답의 Location 헤더 필드로 식별한다.
3) 202 Accepted
- 클라이언트가 보낸 요청이 접수되었으나, 처리가 완료되지 않은 경우 사용한다.
ex. 클라이언트가 요청 접수 후, 1시간 뒤 배치 프로세스가(서버) 요청을 처리하는 경우.
- 클라이언트에게 '요청이 접수되었습니다'와 같은 알림이 간다.
4) 204 No Content
- 클라이언트가 보낸 요청을, 서버가 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우에 사용한다.
ex. 웹 브라우저 웹 문서 편집기 - 저장(save)버튼
: POST로 클라이언트에서 서버로 해당 변경사항이 넘어가지만, 이와 관련해서 서버가 응답을 보내줄 필요가 없음. 즉, save버튼을 눌러도 클라이언트는 같은 화면을 유지하게 됨.
: 이 경우 결과 내용이 없어도, 204 메시지(2xx)만으로 성공을 인식할 수 있음.
=> 이 외에도 다양한 상태코드들을 사용할 수 있음.
=> 그러나, 회사마다 내부적으로 정해서 쓰는 범위가 다르다.
=> 또한 클라이언트 코드를 모두 사용하고자 하는 것은 비효율적이다.
4. HTTP 상태코드 - 3xx (Redirection)
- 클라이언트의 요청을 완료하기 위해, 유저 에이전트의 추가 조치가 필요한 경우 나타나는 상태 코드이다.
[ 리다이렉션 이해 ]
- 웹 브라우저는 3xx응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동된다. 이를 리다이렉트라고 한다.
[ 리다이렉션 종류 ]
1) 영구 리다이렉션 : 301 Moved Permanently / 308 Permanent Redirect
- 특정 리소스의 URI가 영구적으로 이동한다.
- 즉, 원래의 URL은 사용되지 않으며, 검색 엔진 등에서도 해당 변경을 인지한다.
ex. /event -> /new-event
(1) 301 Moved Permanently
- 리다이렉트시, 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (거의 제거됨)
(2) 308 Permanent Redirect
- 301과 기능은 같지만, 리다이렉트시 요청 메서드와 본문을 유지한다는 점에서 차이가 존재한다. (처음 POST를 보내면, 리다이렉트도 POST를 유지한다.)
* 그러나 실무에서는 308방법을 자주 사용하지는 않는다. 왜냐하면 /event가 /new-event로 바뀌면 내부적으로 전달해야하는 데이터 자체가 변경되어버리기 때문이다.
* 따라서 해당 경우 POST가 오더라도 GET으로 대부분 바뀌어도 괜찮다는 것이다.
2) 일시 리다이렉션 : 302 Found / 307 Temporary Redirect / 303 See Other
- 일시적으로 리소스의 URI가 변경된다. 따라서 검색 엔진 등에서 URL이 변경되면 안된다.
* 이후에 지속적으로 URI가 변경될지, 해당 페이지를 유지할지 알지 못한다는 가정 하에, 구성되어야 한다.
(1) 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
* 301과 기능은 유사함.
(2) 307 Temporary Redriect
- 302와 기능은 같지만, 리다이렉트시 요청 메서드와 본문을 유지한다. 즉, 요청 메서드는 변경하면 안된다.
(3) 303 See Other
- 302와 기능은 같지만, 리다이렉트시 요청 메서드가 GET으로 변경된다.
* 실제로 303은 많이 쓰이지 않음, 왜냐하면 대부분 302의 경우 리다이렉트시 GET으로 변경되기 때문에, 302로 사용하는 경우가 많음.
- 일시적 리다이렉션은 언제 사용되는가? : PRG(Post / Redirect / Get)
ex. 쇼핑몰 주문
- 주문 페이지 폼에서 자료 입력 후, 주문하기를 누르면 Post로 데이터가 넘어간다.
- 이후 웹 브라우저를 새로고침하게 되면, Post가 한번 더 실행되어 요청했던 것이 중복 주문이 들어갈 수 있다.
=> 이를 해결하기 위해, 일시적 리더이렉트를 사용한다. (클라이언트에서 사용할 수 있는 방안)
- POST로 주문 후, HTTP 상태코드 302, 303 등을 사용하여, 리다이렉트를 통한 GET으로 주문 결과 화면을 요청하게 한다. (물론 서버측에서도 이에 대한 안전장치를 마련하는 것이 중요함)
- 이후에는 이미 POST->GET으로 리다이렉트 되었기 때문에, 새로고침을 하더라도 GET으로 결과조회만 가능하다.
3) 특수 리다이렉션 : 300 Multiple Choices / 304 Not Modified
(1) 300 Multiple Choices
- 거의 사용 X
(2) 304 Not Modified
- 클라이언트에게 리소스가 수정되지 않았음을 알려서, 클라이언트가 자신의 로컬 PC에 저장된 캐시를 재사용하도록 돕는다. (즉, 캐시로 리다이렉트하도록 돕는다.)
- 따라서, 304 응답은 응답에 메시지 바디를 포함하면 안된다.
ex. 조건부 GET / HEAD 요청 시 사용한다.
5. HTTP 상태코드 - 4xx (Client Error)
- 클라이언트 요청에 잘못된 문법 등으로, 서버가 요청을 수행할 수 없는 경우, 나타나는 상태코드이다.
- 오류의 원인이 클라이언트에 있기 때문에, 똑같은 재시도를 하더라도 계속 실패하게 된다.
1) 400 Bad Request
- 클라이언트가 잘못된 요청 구문 및 메시지를 전송해서, 서버가 요청을 처리할 수 없는 경우.
* 클라이언트가 요청 내용을 정확하게 적을 수 있도록, 백엔드 개발자들은 잘 구성해야한다.
ex. 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 발생
2) 401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증(Authentication)이 필요한 경우.
- 401 오류 발생시, 응답에 www-Authenticate 헤더와 함께, 인증 방법을 설명한다.
cf )
- 인증 (Authentication) : 본인이 누구인지 확인하는 것 (로그인 할 수 있는지 없는지)
- 인가 (Authorization) : 권한부여 (ADMIN 권한처럼 ,특정 리소스에 접근할 수 있는 권한.) => 인증이 있어야 인가가 있다.
3) 403 Forbidden
- 서버가 요청을 이해는 했지만, 승인을 거부한 경우
- 주로, 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 발생한다.
ex. 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우
4) 404 Not Found
- 요청 리소스를 찾을 수 없는 경우.
- 요청 리소스가 서버에 없거나, 클라이언트가 권한이 부족한 리소스에 접근할 때(해당 리소스를 감추었을 때) 발생한다.
6. HTTP 상태코드 - 5xx (Server Error)
- 서버 문제로 오류가 발생했을 때 발생한다.
- 서버에 문제가 있기 때문에, 웹 브라우저에서 재시도 하면 성공이 될 수도 있다.
ex. DB접근 불가와 같은 백엔드 문제
1) 500 Internal Server Error
- 서버 내부 문제로 발생하는 오류.
- 예측 불가인 오류, 애매한 오류인 경우 500으로 처리
2) 503 Service Unavailable
- 서버가 일시적인 과부하 및 예정된 작업으로, 잠시 요청을 처리할 수 없는 경우.
- Retry-After 헤더 필드를 통해, 얼마 뒤에 복구되는지를 사용자에게 알려줄 수 있다.
* 대부분의 서비스 이용 불가는 예측 불가능할 때 나오기 때문에, 그 경우는 거의 500 에러로 나타난다.
=> 가능한 500대 에러(서버 오류)는 만들어내면 안된다.
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
