HTTP 상태코드
HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려준다.
1xx : 조건부 응답
2xx : 성공
3xx : 리다이렉션 완료
4xx : 클라이언트 오류
5xx : 서버 오류
1xx (Informational)
HTTPhttp 상태코드가 "1"로 시작하는 경우 서버는 클라리언트의 요청을 받았으며, 클라이언트는 작업을 계속 진행하라는 의미이다.
- 100 Continue
진행중임을 나타내는 응답코드로, 현재까지는 문제가 없으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.
- 101 Switching Protocol
클라이언트가 보낸 업그레이드 요청 해더에 대한 응답이며, 서버에서 프로토콜을 변경할 것임을 알려준다.
- 102 Processing
서버가 요청을 받았으나 이를 처리하는 중이고, 아직 제대로 된 응답을 줄 수 없음을 알려준다.
2xx (Successful)
HTTP 상태코드가 "2"로 시작하는 경우 클라이언트의 요청을 수신하고 성공적으로 처리했음을 의미한다.
- 200 OK
요청이 성공적으로 되었으며, 요청에 대한 응답 정보를 HTTP 메시지에 포함시켜 전송한다.
- 201 Created
요청이 성공적이었으며, 그 결과로 새로운 리소스가 생성되었음을 알리고 일반적으로 POST나 PUT 요청 이후에 따라온다.
- 202 Accepted
요청은 성공적으로 수신하였으나 그에 응하여 행동할 수 없음을 뜻한다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않는다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌다.
ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리한다.
- 204 No Content
요청은 성공적으로 수신하였으나, 요청에 대한 컨텐츠가 없어 메시지 바디에는 데이터가 없지만 메시지 헤더는 의미있을 수 있다.
ex) 게시판 수정시, save 버튼 ➝ 클라이언트는 편집한 내용을 응답 데이터로 볼 필요가 없으며 save 버튼을 눌러도 화면 변화가 없다.
3xx (Redirection)
클라이언트는 요청을 마치기 위하여 추가적인 동작을 취해야 한다는 것을 의미한다.
- 300 Mulitple Choices
요청에 대한 하나 이상의 응답이 가능함을 의미하며, 클라이언트는 그 중에 하나를 반드시 선택해야 한다. 이때 선택하는 방법에 대한 표준화 된 방법은 없다.
- 301 Moved Permanently
요청한 리소스의 URI가 변경되었음을 의미한다. 따라서 요청한 페이지를 새 URI로 영구적으로 이동한다.
➝ 리다이렉트시 요청 메서드가 GET으로 변하고, 경우에 따라 본문이 제거될 수 있다.
- 302 Found
요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 따라서 이후 요청은 원래 URI 위치를 계속 사용해야 한다.
➝ 리다이렉트시 요청 메서드가 GET으로 변하고, 경우에 따라 본문이 제거될 수 있다. (MAY)
- 303 See Other
(302와 같은 기능) 요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 따라서 이후 요청은 원래 URI 위치를 계속 사용해야 한다
➝ 리다이렉트시 요청 메서드가 GET으로 변경된다. (MUST)
- 304 Not Modified
캐시를 목적으로 사용한다. 클라이언트에게 응답 리소스가 수정되지 않았음을 알려주며, 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
➝ 304 응답은 로컬 캐시를 사용해야하므로 응답에 메시지 바디를 포함해서는 안된다.
➝ GET, HEAD 요청시 사용한다.
- 307 Temporary Redirect
(302와 같은 기능) 요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 따라서 이후 요청은 원래 URI 위치를 계속 사용해야 한다
➝ 리다이렉트시 요청 메서드와 본문을 유지해야 한다. (요청 메서드를 변경해서는 안된다. MUST NOT)
- 308 Permanent Redirect
(301과 같은 기능) 요청한 리소스의 URI가 변경되었음을 의미한다. 따라서 요청한 페이지를 새 URI로 영구적으로 이동한다.
➝ 리다이렉트시 요청 메서드와 본문을 유지해야 한다.
PRG : Post / Redirect / Get (일시적인 리다이렉션)
Post로 주문후에 웹 브라우저를 새로고침 한다면 ?
PRF를 사용하지 않으면, 새로고침은 다시 요청 처리를 의미하므로 중복 주문이 될 수 있다.
➝ PRG를 통해 POST로 주문후에 새로 고침으로 인한 중복 주문을 방지할 수 있다.
➝ POST로 주문후에 주문 결과 화면를 GET 메서드로 리다이렉트한다.
만약 새로고침를 한다해도 결과 화면을 GET으로 하여 중복 주문을 방지한다.4xx (Client Error)
클라이언트의 요청에 잘못된 문법 등으로 서버가 응답을 할 수 없음을 의미한다. 클라이언트가 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 요청을 재시도하더라도 실패한다.
- 400 Bad Request
클라이언트 요청의 오류로 인해 서버가 요청을 처리할 수 없음을 의미한다.
ex) 요청 파라미타가 잘못되거나, API 스펙이 맞지 않았을 때
- 401 Unauthorized
클라이언트는 요청에 대한 응답을 받기 위해서 반드시 스스로 인증을 해야함을 의미한다.
➝ 401 오류시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
- 403 Forbidden
클라이언트의 요청을 서버가 이해했으나 클라이언트가 접근할 권리를 가지고 있지 않아 승인을 거부하는 것을 의미한다.
➝ 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있다는 점이다.
ex) 어드민 등급이 아닌 사용자가 로그인 했지만, 어드민 등급의 리소스에 접근하는 경우
- 404 Not Found
클라이언트가 요청한 리소스를 서버에서 찾을 수 없을 때 발생하는 상태코드이다.
➝ 서버들은 인증받지 않은 클라이언트로 부터 해당 리소스를 숨기고 싶을 때 403대신 404를 사용할 수 있다.
HTTP API 스펙을 만족했을 경우, 4xx 응답 코드를 반환해서는 안된다.
이런 경우 4xx를 반환시 클라이언트 개발자는 서버와 클라이언트가 서로 약속한 API 스펙을 다 지켰는데,
클라이언트 측 잘못이라고 이야기하는 것과 같기 때문이다.5xx (Server Error)
서버 문제로 인해 오류가 발생하는 경우 사용된다. 서버 문제가 복구되거나 해결되면 똑같은 요청을 재시도하면 성공할 수 있다.
- 500 Internal Server Error
서버에 문제로 인해 발생하여 요청을 수행할 수 없음을 의미한다.
- 503 Service Unavailable
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음을 나타낸다.
➝ Retry-After 헤더를 통해 얼마뒤에 복구되어 사용할 수 있는지 보낼 수 있다.
5xx 상태코드는 정말 서버의 장애나 에러가 났을 때만 발생시켜야 한다.
비즈니스 로직이나 프로세스 상 논리적인 문제가 발생시에는 사용해서는 안된다.
해결 방안)
만약 요청이 서버와 클라이언트가 약속한 HTTP API 스펙을
만족한다면 2xx 상태 코드, 불만족한다면 4xx 상태 코드를 발생시킨다.
요청이 서버와 클라이언트가 약속한 HTTP API 스펙에 만족하지만,
비즈니스 로직이나 프로세스 상 논리적인 문제가 발생한 경우 2xx로 응답하면서
결과에 내부 비즈니스 응답 코드를 정의하여 함께 전달한다. (2xx + 비즈니스 코드)
➝ 이를 봉투 패턴이라고 한다.
봉투가 포함된 응답 예시
{
"code": "success" ("success", "fail", "hold", "deny" ...)
"data": {memberId: ... 결과 데이터}...
}참고 자료
https://www.inflearn.com/course/http-웹-네트워크
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
https://ko.wikipedia.org/wiki/HTTP_상태_코드
