모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., 웹 기술을 사용하는 개발자라면 누구나 OK!꼭 필요한 HTTP의 핵심을 알려드립니다. 📣 확인해주세요!본 강의는 자바 스
www.inflearn.com
강의를 들으며 생각 정리
HTTP 상태코드 소개
상태 코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 1xx (Informational): 요청이 수신되어 처리중 -> 거의 사용하지 않는다.
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
만약 모르는 상태 코드가 나타나면?
클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? -> 클라이언트는 상위 상태코드로 해석해서 처리한다.
이는 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다는 것을 의미한다.
ex)
• 299 ??? -> 2xx (Successful)
• 451 ??? -> 4xx (Client Error)
• 599 ??? -> 5xx (Server Error)
2xx - 성공
2xx (Successful) : 클라이언트의 요청을 성공적으로 처리
• 200 OK
• 201 Created
• 202 Accepted
• 204 No Content
200 OK
요청 성공
ex)
요청
GET /members/100 HTTP/1.1
Host: localhost:8080
응답
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34
{ "username": "young", "age": 20 }
201 Created
요청 성공해서 새로운 리소스가 생성됨
ex)
요청
POST /members HTTP/1.1
Content-Type: application/json
{ "username": "young", "age": 20 }
응답
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100
{ "username": "young", "age": 20 }
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
배치 처리 같은 곳에서 사용한다.
ex)
요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
ex)
웹 문서 편집기에서 save 버튼 -> save 버튼의 결과로 아무 내용이 없어도 된다. save 버튼을 눌러도 같은 화면을 유지해야 한다.
3xx - 리다이렉션
3xx (Redirection) : 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
• 300 Multiple Choices -> 거의 사용하지 않는다.
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect
: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다. (리다이렉션)
리다이렉션
영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동, 원래의 URL을 사용하지 않고 변경된다.
• 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
ex)
1. 요청
POST /event HTTP/1.1 -> POST 사용
Host: localhost:8080
name=hello&age=20
2. 응답
HTTP/1.1 301 Moved Permanently
Location: /new-event
3. 자동 리다이렉트
URL:/event -> URL:/new-event
4. 요청
GET /new-event HTTP/1.1 -> GET으로 변경
Host: localhost:8080
5. 응답
HTTP/1.1 200 OK
• 308 Permanent Redirect : 301과 기능은 같으나 리다이렉트 요청메서드와 본문 유지가 된다.
ex)
1. 요청
POST /event HTTP/1.1 -> POST 사용
Host: localhost:8080
name=hello&age=20
2. 응답
HTTP/1.1 308 Permanent Redirect
Location: /new-event
3. 자동 리다이렉트
URL:/event -> URL:/new-event
4. 요청
POST /event HTTP/1.1 -> POST 유지
Host: localhost:8080
name=hello&age=20 -> 본문 메시지 유지
5. 응답
HTTP/1.1 200 OK
+) 일반적으로 301을 많이 사용한다. event와 new-event에서 필요한 데이터가 다를 수 있기 때문에 클라이언트에서 서버로 재요청을 요구하는 경우가 많다.
일시적인 리다이렉션 : 리소스의 URI가 일시적으로 변경
• 302 Found : 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.(MAY)
• 307 Temporary Redirect : 302와 기능은 같으나 리다이렉트 요청 메서드와 본문을 유지한다.(MUST)
• 303 See Other : 302와 긴으은 같으나 리다이렉트시 요청 메서드가 GET으로 변경한다.(MUST)
-> 302가 GET으로 변하지 않을 가능성이 있기 때문에 303이 나왔다고 보면 된다.
일시적인 리다이렉션의 대표적인 예로 PRG(Post/Redirect/Get)이 있다.
ex)
POST로 주문 후에 웹 브라우저를 새로고침하면? -> 새로고침은 다시 요청 -> 중복 주문이 될 수 있다.
<PRG: 사용 전>
1. 요청
POST /order HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1
2. 주문데이터 저장 in DB - mouse 1개
3. 응답
HTTP/1.1 200 OK
<html>주문완료</html>
4. 결과 화면에서 새로고침
URL: /order -> URL: /order
5. 요청
POST /order HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1
6. 주문데이터 저장 in DB - mouse 1개
7. 응답
HTTP/1.1 200 OK
<html>주문완료</html>
-> 중복 주문이 발생한다.
<PRG: 사용>
POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 -> 새로 고침해도 결과 화면만 GET으로 조회
1. 요청
POST /order HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1
2. 주문데이터 저장 in DB - mouse 1개
3. 응답
HTTP/1.1 302 Found
Location: /order-result/19
4. 자동 리다이렉트
URL: /order -> URL: /order-result/19
5. 요청
GET /order HTTP/1.1 -> GET 사용
Host: localhost:8080
6. 주문데이터 조회 in DB : 19번 주문
7. 응답
HTTP/1.1 200 OK
<html>주문완료</html>
8. 결과 화면에서 새로 고침
GET /order-result/19 -> 결과 화면만 다시 요청(5번으로 이동)
+) 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었다. 그런데 많은 웹 브라우저들이 대부분 GET으로 바꾸어 버린다. 그래서 모호한 302를 대신해 명확한 307, 303이 등장했다.
그래서 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하기 때문에 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없다.
기타 리다이렉션
• 300 Multiple Choices: 안쓴다.
• 304 Not Modified : 캐시를 목적으로 사용한다. 클라이언트에게 리소스가 수정되지 않았음을 알려주고 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. 또한 304 응답은 응답에 메시지 바디를 포함하면 안된다.
-> 조건부 GET 요청 시 사용 (자세한 내용은 이후 포스팅에서 다루겠다)
4xx - 클라이언트 오류, 5xx - 서버 오류
4xx - 클라이언트 오류
클라이언트의 요청에 잘못된 문법 등을 서버가 요청을 수행할 수 없다. 즉, 오류의 원인이 클라이언트에 있다.
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도가 실패한다.
(반대로 5xx는 이후 서버가 안정화 되면 재시도가 성공할 수 있다)
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음. 클라이언트는 요청 내용을 다시 검토하고, 보내야 함
ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요함
401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
참고)
인증(Authentication) : 본인이 누구인지 확인(로그인)
인가(Authorization) : 권한 부여(ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
403 Forbidden
서버가 요청을 이해했지만 승인을 거부함. 주로 인증은 되었지만, 접근 권한이 불충분한 경우
ex) ADMIN 등급이 아닌 사용자가 로그인 하고 ADMIN 등급의 리소스에 접근하는 경우
404 Not Found
요청 리소스를 찾을 수 없음. 혹은 해당 리소스를 숨기고 싶을 때.
5xx - 서버 오류
서버 문제로 오류 발생. 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있다.(복구 되는 등)
500 Internal Server Error
서버 문제로 오류 발생, 애매하면 500 오류
503 Service Unavailable
서비스 이용 불가. 서버가 일시적인 과부화 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.
Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있다.
+) 500 에러는 내부에서 시스템 예외나 NullPointerException 등 비즈니스와 관계 없는 시스템 예외가 발생했을 때만 사용한다.
일반적으로 정해진 HTTP API 스펙을 만족하면 -> 200, 만족하지 않으면 -> 400을 사용한다.
그러나 200의 경우 비즈니스 로직이 정상 수행 되지만, 20세 미만 승인 거절 등의 다른 결과가 존재한다면 200 + 내부 비즈니스 응답 코드를 정의해서 함께 전달한다.
'http' 카테고리의 다른 글
| HTTP 헤더2 - 캐시와 조건부 요청 (0) | 2021.04.16 |
|---|---|
| HTTP 헤더 1 - 일반 헤더 (0) | 2021.04.14 |
| HTTP 메서드 활용 (0) | 2021.04.12 |
| HTTP 메서드 (0) | 2021.04.12 |
| HTTP 기본 (0) | 2021.04.07 |