[BE] API 요청 예외 상황에 대한 논의 필요(crossref api 요청시 timeout 설정 등)

[leesungbin]

이슈 내용

crossref api 요청시 무한정 기다릴 수 없다.

기대 결과

• 5초 정도의 적절한 timeout을 걸어놓는다.
• crossref가 backend 서버의 요청을 거절하거나, 요청이 매우 delay 되는 경우 어떻게 할까?
  1. 요청이 매우 delay 되면, client로 status 408(Request timeout)을 던져준다.
  • client에서는 api 서버로 제한된 횟수만큼의 retry를 시도한다.
  • 제한된 횟수만큼의 retry가 넘어가면, 사용자에게 준비된 에러 메시지를 보여준다.
  2. 요청이 거절당하면, api 서버에서 자동으로 retry를 시도한다.

정리: 예외 상황에 대한 논의 필요

• crossref 요청 자체에 문제가 생길경우, 그대로 뱉어줄 것인지, 다시 요청할 건지, 클라이언트에서는 어떻게 처리를 할지 등

[JunYupK]

• timeout 시간? => 테스트 후 평균 시간 측정 (텀을 길게 잡으면)
• crossref 요청에 문제가 생겼을 경우에는 BE <=> crossRef retry 5번으로 제한한다.
• retry 이후에도 요청이 정상적이지 않은 경우에는 BE => 클라이언트로 500대 에러를 리턴, 클라이언트는 해당 에러코드를 확인하고 대체 페이지 랜더링(ex. 서버에 접속하지 못하였습니다. , git error page)
  => 만약에 500대 에러가 너무 많이 발생한다면, 이후에 추가적으로 보완 필요

에러 페이지 문구

1. 잠시 후 다시 확인해주세요
2. 지금 이 서비스와 연결할 수 없습니다. 문제를 해결하기 위해 열심히 노력하고 있습니다. 잠시 후 다시 확인해주세요.
3. 서비스에 접속할 수 없습니다
4. 죄송합니다. 기술적인 문제로 일시적으로 데이터를 불러올 수 없습니다. 잠시 후 다시 이용 부탁드리며 이용에 불편을 드려 사과드립니다.(O)

• 네트워크 에러

• path 에러

• 자동 완성을 하다가 결과가 제대로 안오는 경우 => error 문구 X (ex. 자동 완성 결과가 없습니다.)

• 2번째 페이지로 이동 간 결과가 제대로 안오는 경우 => (error page)

• 3번째 페이지로 이동 간 결과가 제대로 안오는 경우 => (error page)

[leesungbin]

• 15-2 [FE] [에러 처리] 에러 상태코드 별 처리 (재요청, 에러페이지 등) #81
• 13-6 [BE] [논문 상세 - 논문 정보] Request batch 작업 #82