반응형
본 내용은 인프런, 김영한님의 모든 개발자를 위한 HTTP 강의를 듣고 작성한 문서입니다.
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx : 요청이 수신되어 처리중 (거의 사용안함)
- 2xx : 요청 정상 처리
- 3xx : 요청을 완료하려면 추가행동 필요 (리다이렉트)
- 4xx : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청 수행할 수 없음
- 5xx : 서버 오류, DB 문제 등으로 서버가 정상 요청을 처리하지 못함
만약, 모르는 상태코드가 나타난다면?
클라이언트는 상위 상태 코드로 해석해서 처리 -> 299로 온다면 대충 2xx.. 성공이구나.. 이렇게..
1XX 상태코드
HTTP 상태 코드 | Value | 설명 |
---|---|---|
100 | Informational | 요청이 수신되어 처리중 거의 사용되지 않음 |
2XX 상태코드
성공
HTTP 상태 코드 | Value | 설명 |
---|---|---|
200 | OK | 요청이 성공적으로 들어왔다. (조회 시?) |
201 | Created | 요청 성공해서 새로운 리소스가 생성 되었다. Http 헤더에 Location: /members/100 이런식으로 생성된 애의 정보를 보내줌. |
202 | Accepted | 요청이 접수되었으나 처리가 완료되지 않음 ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리 잘 사용하지 않는다 |
204 | No Content | 서버가 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없는 경우 ex) save 를 눌러도 같은 화면을 유지해야 하는 경우.. 굳이 받을 데이터가 없을 때.. 결과 내용이 없어도 204 메세지 만으로 성공을 인식 할 수 있다 (실패하면 다른 메세지 보내줘야함) |
3XX 상태코드
요청을 완료하기 위해 유저에이전트 (주로 웹 브라우저)의 추가 조치 필요
리다이렉션?
웹브라이저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동이동한다 -> 리다이렉트
리다이렉션 | 설명 | 예시 | 관련 HTTP 상태 코드 |
---|---|---|---|
영구 리다이렉션 | 특정 리소스의 URI가 영구적으로 이동 | /members -> /users 이런식으로 완전 바뀜, 거의 안씀 | 301, 308 |
일시 리다이렉션 | 리소스의 URI가 일시적으로 변경 검색 엔진 등에서 URL을 변경하면 안됨 |
주문 완료 후 주문 내역 화면으로 | 302, 307, 303 |
특수 리다이렉션 | 결과 대신 캐시를 사용 | 304 |
HTTP 상태코드 | Value | 설명 |
---|---|---|
300 | Multiple Choices | 안씀 |
301 | Moved Permanently | 리다이렉트 요청시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 |
302 | Found | 리다이렉트 요청시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 |
303 | See Other | 302와 기능은 같은데 리다이렉트시 요청메서드가 GET으로 변경 |
304 | Not Modified | 캐시를 목적으로 씀 (뒤에 다시 설명) 클라이언트에게 리소스가 수정되지 않았음을 알려줌 304응답은 메세지 바디를 포함하면 안된다. |
307 | Temporary Redirect | 302와 기능은 같은데 요청 메서드와 본문 유지 (POST->POST) |
308 | Permanent Redirect | 301과 기능은 같은데 요청 메서드와 본문 유지 (POST->POST, 객체도 유지) |
PRG : Post/Redirect/Get (3xx 상태에 관한 고찰)
만약 Post로 주문 후에 웹브라우저를 새로고침 한다면? -> 새로고침은 다시 재요청 -> 중복으로 주문이 들어갈 수 있다.
이를 막기 위해 일시적인 리다이렉션을 사용한다.
- 클라이언트가 POST로 아이템을 주문
서버는 302나 303을 이용하여 Location: /order-result/9 와 같이 헤더 정보를 보냄
- 위의 응답을 받은 웹브라우저는 Location 으로 화면을 다시 요청 (이때, GET으로 보내게 된다)
- 서버는 Location에 해당하는 응답을 보내줌
- 새로고침을 해도 GET 으로만 결과가 조회됨
4XX 상태코드
클라이언트의 오류, 오류의 원인이 클라이언트에 있음
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같이 요청하면 계속 실패만 하게 됨
HTTP 상태코드 | Value | 설명 |
---|---|---|
400 | Bad Request | 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 |
401 | Unauthorized | 클라이언트가 해당 리소스에 대한 인증이 필요함 |
403 | Fobidden | 서버가 요청을 이해했지만 승인을 거부함 주로 인증 자격은 있지만, 접근 원한이 불충분한 경우 ex) admin 권한인데 일반user가 접근 |
404 | Not Found | 요청 리소스를 찾을 수 없음 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 |
5XX 상태코드
서버 문제로 오류 발생 ex) DB... Null..
서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음 (서버나 디비가 복구되는 경우..)
서버에서는 500 에러를 거의 만들면 안됨 -> 진짜 서버에 문제가 있을 때만 500 에러 던지기.. 은행잔고 부족 이런건 서버 에러가 아님
HTTP 상태코드 | Value | 설명 |
---|---|---|
500 | Internal Server Error | 서버 문제로 오류 발생, 애매하면 그냥 500 에러.. |
503 | Service Unavailable | 서비스 이용 불가 서버가 일시적인 과부하, 또는 예정된 작업으로 잠시 요청을 처리할 수 없음 Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음 |
반응형
'강의정리 > 모든개발자를위한HTTP웹기본지식' 카테고리의 다른 글
HTTP 헤더 - 일반 헤더 (1) | 2022.08.11 |
---|---|
클라이언트에서 서버로 데이터 전송 (0) | 2022.08.11 |
HTTP API를 만들어 보자 (0) | 2022.08.11 |
HTTP (0) | 2022.08.11 |
URI (0) | 2022.08.10 |
댓글