일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 프로그래머스
- 깊게 생각해보기
- 카카오
- prg 패턴
- docker
- jwt 표준
- 구현
- 숫자 블록
- 검색어 추천
- 알람 시스템
- BFS
- piplining
- 디버깅
- 좋은 코드 나쁜 코드
- branch 전략
- AWS
- 완전탐색
- gRPC
- 트랜잭샨
- 쿠키
- 이분탐색
- spring event
- 레디스 동시성
- 코드 계약
- 수신자 대상 다르게
- 결제서비스
- 셀러리
- 누적합
- 객체지향패러다임
- 백준
- Today
- Total
코딩관계론
새로고침으로 발생하는 중복 데이터 전송 방지하기 본문
개요
HTML form 데이터를 이용해서 게시판 글쓰기나 주문 전송을 하기 위해선 post 메소드를 이용해야 한다. 이런 post 메소드 요청을 수행한 후 브라우저를 새로고침 하면 해당 요청이 계속적으로 실행되어 서버에 중복으로 정보가 저장되는 경우가 발생하게 된다,
오류 해결 시도
먼저 이 오류가 발생하는 원인은 새로고침에 의해서 발생한다.인터넷 브라우저를 새로고침 하면 일반적으로 브라우저는 현재 페이지를 다시 로드하고, 이전에 사용자가 마지막으로 했던 행동을 다시 수행하게 됩니다. 따라서 이전에 보냈던 POST 요청을 다시 수행하게 됨으로 서버에는 중복된 데이터가 남아있게 된다.
이를 해결하기 위해서 PRG(Post -> Redirect -> Get)이란 패턴이 있다.
POST요청 후 응답을 301로 하면서 브라우저가 다시 Get 요청을 보낼 수 있도록 유도하는 것이다.
코드로 보면 기존의 중복 전송 코드는 아래와 같다 Response에 200을 주면서 저장완료만 주는 것이다.
@PostMapping("/articles/create")
public ResponseEntity<String> createArticle(ArticleForm form) {
Article entity = form.toEntity();
Article saved = this.articleRepository.save(entity);
return ResponseEntity.ok().body("Article created with ID: " + saved.getId());
}
하지만 PRG패턴을 적용하면 응답을 2xx가 아닌 3xx로 주면서 broswer가 redirect하도록 유도하고 마지막 사용자 요청은 Get이 된다.
@PostMapping("/articles/create")
public String createArticle(ArticleForm form) {
Article entity = form.toEntity();
Article saved = this.articleRepository.save(entity);
return "redirect:/articles/" + saved.getId();
}
즉 요청은 아래 그림과 같이 변하게 된고, 중복 POST 요청은 더이상 일어나지 않는다.
참고로 이 상황은 HTML을 이용해서 POST를 요청할 때만 발생하는 현상이고 API통신인 경우에는 발생하지 않는다. 그 이유는 API 통신에서는 브라우저의 동작과는 무관하게 JavaScript 등을 사용하여 명시적으로 API 호출을 수행하므로, 새로고침과 같은 브라우저 동작이 API 호출에 영향을 미치지 않기 때문이다.
'TroubleShooting' 카테고리의 다른 글
In-memory- database를 사용해 TPS를 높이자 (2) | 2024.07.24 |
---|---|
발급 가능한 쿠폰의 개수보다 사용자에게 전달한 쿠폰의 개수가 더 많다.... (0) | 2024.07.23 |
파이썬 크롤링 작업 시간 단축하기 (0) | 2023.08.13 |
telegram.error.NetworkErrorAsyncIO Event Loop Closed 오류 (0) | 2023.08.12 |
Email attachment received as 'noname' 해결하기 (0) | 2023.05.09 |