모든 개발자를 위한 HTTP 웹 - 6. HTTP 상태코드

-> 201은 리소스를 새로 저장하고 저장된 경로를 Location에 포함해서 반환하며 '응답 메세지'에 본문을 첨부해도 된다.
-> 204는 No content. '응답 메세지'에 본문을 첨부하면 안된다. 저장이 성공했고 결과 데이터를 반환할 일이 없을 때 사용하면 된다. 화면은 계속 유지해야 하기 때문에

<200, 201, 204 사용 정리>

-> 200: 새롭게 업데이트한 페이지를 보여줘야 할 때 : GET, PATCH
-> 201 : 리소스를 신규로 생성했을 때 : POST
-> 204 : 사용자에게 보여지는 페이지를 바꾸지 않고 리소스를 업데이트 할 때 : PUT

<302, 303, 307 정리>

1. 302 - 메서드가 GET으로 변할 수 있음
2. 307 - 메서드가 변하면 안됨
3. 303 - 메서드가 GET으로 변경됨

-> 현실적으로 307, 303을 권장하지만 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다. 자동 리다이렉션 시에 GET으로 변해도 되면 302를 사용해도 큰 문제가 없다.

<질문 정리>

Q. 서버측에서 '동일 주문 중복 방지'를 하기위해 어떻게 구현하는가?

-> 보통 주문 화면에 들어가는 시점에 서버에서 '임시 주문 번호'를 발급해두는데, 주문 번호는 다음과 같이 만들 수 있다.
1. DB가 제공하는 중복없이 순서대로 값이 증가하는 '시퀀스 값'을 사용
2. UUID 사용

Q. 영구 리다이렉트와 일시 리다이렉트의 차이점은 무엇인가요?

-> 단순 웹 브라우저 입장에서는 영구 리다이렉트와 일시 리다이렉트는 같다. 다만 '검색엔진'처럼 사용자가 아닌 시스템이 크롤링을 하는 경우를 생각해보면 도움이 된다.
1. 영구 리다이렉트는 검색엔진이 URL 자체를 변경해도 된다.
2. 일시 리다이렉트는 검색엔진이 URL을 변경하면 안된다. URL이 일시적으로 변경된 것으로 향후 다르게 변경될 수 있기 때문에 검색엔진은 URL을 redirect URL로 변경하면 안된다.

Q. 브라우저에서 POST 요청을 서버에 하고 클라이언트는 아직 302응답을 받지 못한 상황에서 새로고침을 하는 경우, 중복주문을 막을 수 없는것인가?

-> 맞다. 302만으로는 '중복 요청'을 완전히 막을 수 없고, 서버에서도 중복 요청시 해결방안을 마련해야 한다. 
즉, 클라이언트 차원의 중복 요청 방지(PRG) and 서버 차원의 중복 요청 방지(중복된 주문 번호 체크) 모두 필요하다.

Q. 주문을 POST로 서버에 요청했을 때 200번대 와 함께 '주문 완료'를 정적페이지로 응답하는 방법, 300번대와 함께 PRG 패턴을 적용해 리다이렉트 해주는 방법중 실무에서 사용하는 응답 방법은 어떤 응답 방식인가? 

-> 결론은 '리다이렉션'을 사용하는 것이 더 나은 선택이다.