Today I Learned_220919

HTTP

인프런 HTTP 강의 수강

HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태를 서버의 응답으로 알려주는 기능

요청이 잘 처리가 되었는지? 문제가 되었는지? - request가 아니라 response로 알려주는 기능

현존하는 상태코드가 아니라 미래에 새로운 상태코드가 생겨서 모르는 상태코드를 서버가 반환한다면?
-> 클라이언트는 상위 상태코드로 해석해서 처리. 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨

ex) 299 - 없는 상태코드이지만, 2xx이므로 Successful 처리를 한다.

1xx(Informational) : 요청이 수신되어 처리중 -> 잘 사용되지 않음

2xx - 성공

Successful, 요청 정상 처리

클라이언트의 요청을 성공적으로 처리했다

200 OK

클라이언트의 요청을 성공적으로 처리. 가장 많이 보는 케이스이다.

요청

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

클라이언트가 요청을 한 것 가지고 서버에 리소스 생성. 주로 POST로 등록했을 때 준다

요청

POST /members HTTP/1.1
Content-Type: application/json
{
"username": "young",
"age": 20
}

요청에 생성할 리소스를 담아서 보냄 (POST -> 서버에서 자원을 생성)

응답

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100
{
"username": "young",
"age": 20
}

생성된 리소스는 응답의 Location 헤더 필드로 식별

202 Accepted

요청이 접수되었으나 처리가 완료되지 않음

배치 처리 같은 곳에서 사용

예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

잘 사용하지는 않음

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

예) 웹 문서 편집기에서 save 버튼. 데이터가 POST로 서버에 넘어가지만 응답을 내려줄 게 없다
save 버튼의 결과로 아무 내용이 없어도 되며, 버튼을 눌러도 같은 화면을 유지해야 하는 경우 사용
결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있다.

3xx - 리다이렉션

Redirection, 요청을 완료하려면 추가 행동이 필요. 주로 리다이렉트로 사용

요청을 완료하기 위해 유저 에이전트(클라이언트 프로그램, 주로 웹 브라우저)의 추가 조치 필요

웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동한다. (사용자 입장에서는 빨라서 사용자는 인식을 잘 하지 못한다)

Status 코드

• 300 Multiple Choices (잘 사용하지 않음)
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

리다이렉션의 종류

• 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
  • 주소가 아예 바뀜 (구 주소 -> 신 주소)
• 일시 리다이렉션 : 일시적인 변경
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG : POST/Redirect/GET
• 특수 리다이렉션 : 결과 대신 캐시를 사용

영구 리다이렉션

301, 308

• 리소스의 URI가 영구적으로 이동
• 원래의 URL을 더 이상 사용하면 안 된다
• 검색 엔진들도 변경을 인지할 수 있다 (A주소를 불렀는데 B주소가 나온다? B주소로 인지를 한다)

301과 308 모두 기능은 비슷하다 -> 경로가 완전히 바뀌었다는 것을 알려줌

• 301 Moved Permanently
  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다 (거의 이렇게 된다)
  • 원래는 요청 메서드로 유지하는 것이 스펙이었지만, 대부분 위와 같이 구현되어 있기 때문에 위와 같은 스펙으로 변경
• 308 Permanent Redirect
  • 301과 기능은 같다
  • 리다이렉트 시 요청 메서드와 본문이 유지된다

사실상 URL이 변한다면 파라미터도 변하는 경우가 많으므로.. 일반적인 경우에는 301을 더 잘 활용한다.

일시적인 리다이렉션

302, 307, 303

• 리소스의 URI가 일시적으로 변경(나중에 바뀌지 않을 수 있다)
  • 처음엔 A 들어왔다가 나중에 B 들어갈 수도 있음
• 영구적으로 변경되는 것이 아니기에, 검색 엔진 등에서 URL을 변경하면 안 된다.
• 아래 3개는 기능 자체는 같다
• 302 Found
  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다 (301이랑 같음!!)
  • 메서드라 변할 수 있고, 본문이 제거될 수 있지만 그러지 않을 수도 있다.
  • 301과 같이 원래 의도는 메소드를 유지하는 것이었으나.. 어느새 위와 같은 스펙으로 변경되었다
• 307 Temporary Redirect
  • 302와 기능은 같음
  • 리다이렉트 시 요청 메서드와 본문 유지
  • 요청 메서드를 변경하면 안 된다
• 303 See Other
  • 302와 기능은 같음
  • 리다이렉트 시 요청 메서드가 GET으로 변경
  • 무조건 GET으로 변경(명확하게 명시)

실무에서는 대부분 302를 많이 사용한다.

PRG : Post/Redirect/Get

PRG 패턴

일시적인 리다이렉션을 사용하는 예시

• POST로 주문 후에 웹 브라우저를 새로고침하면? -> 다시 요청이 갈 수 있음 -> 중복 주문이 될 수 있다.
• 아래와 같이 클라이언트 차원에서 방어가 가능 (물론 서버쪽에서도 막아야 한다)
• POST로 주문 후에 주문 결과 화면을 GET메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청
• PRG 이후 리다이렉트
  • URL이 이미 POST -> GET으로 리다이렉트됨
  • 새로고침해도 GET으로 결과 화면만 조회
• 이렇게 하면 사용성도 좋고, 서버 입장에서도 오류가 줄어든다.

정리

처음 302의 의도는 HTTP메서드를 유지하는 것이었지만, 웹 브라우저들이 대부분 GET로 바꾸어버렸다

302의 스펙 자체가 모호해지자, 명확한 스펙인 307, 303이 등장했다.

302 : GET으로 변할 수 있음

307 : 메서드가 변하면 안 됨

303 : 메서드가 GET으로 변경

명확한 스펙인 307, 303을 권장하지만 현실적으로 많은 애플리케이션이 302 사용중

자동 리다이렉션 시 GET으로 변해도 되면 302를 사용해도 큰 문제가 없다.

기타 리다이렉션

300, 304

• 300 Multiple Choices : 안 쓴다.
• 304 Not Modified : 정말 많이 쓴다
  • 캐시, 조건부 요청 관련
  • 캐시를 목적으로 사용
  • 클라이언트에게 리소스가 수정되지 않았다는 것을 알려준다
  • 클라이언트 : 캐시가 만료된 것 같은데 다시 줘
  • 서버 : 캐시 써도 되니까 써
  • 캐시로 리다이렉트한다
  • 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안 된다
  • 조건부 GET, HEAD 요청시 사용

4xx - 클라이언트 오류

Client Error, 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음

클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 재시도 할 경우 실패할 수 밖에 없다. -> 400대 오류와 500대 오류의 큰 차이점!

• 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  • 요청 구문, 메시지 등등 오류
  • 클라이언트는 요청 내용을 다시 검토하고 보내야 함
  • 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때, 숫자를 보내야 하는데 문자를 보냈을 때
  • 서버 개발자는 이것을 잘 판단해야 한다! (500 오류로 판단하지 않게끔 잘 막아야 함)
• 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
  • 인증되지 않음
  • 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
  • 인증(Authentication) : 본인이 누구인지 확인하는 것, 로그인
  • 인가(Authorization) : 권한부여. 특정 리소스에 접근할 수 있는 권한. 인증이 선행되어야 인가가 있을 수 있다.
  • 오류 메시지는 인가에 관한 내용이지만 오류는 인증의 문제
• 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
  • 주로 접근 권한이 불충분한 경우
• 404 Not Found : 요청 리소스를 찾을 수 없음
  • 서버 입장에서는 이런 리소스가 없는데 찾으려고 한다
  • 요청 리소스가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때 사용(403 조차 내기 싫다)

5xx - 서버 오류

Server Error, 서버 오류, 서버가 정상 요청을 처리하지 못함 (데이터베이스 중단 등)

서버에 문제가 있기 때문에 재시도 하면 서버가 복구되어서 성공할 수 있음

비즈니스 상 오류랑 서버 오류를 잘 구분해야 한다! 비즈니스 오류가 아니라 진짜 서버 오류일 때 500 에러를 내야 한다.

나머지는 400 혹은 200으로 해결하도록 하자.

• 500 Internal Server Error
  • 서버 문제로 오류 발생
  • 애매하면 500 오류
• 503 Service Unavailable
  • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
  • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있음
  • 근데 언제 복구될지 아무로 모르므로..보통 500을 자주 보내준다.