큐와 비동기 API · 비동기 API 설계(202 Accepted·폴링·웹훅) · 퀴즈
퀴즈: 비동기 API
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
202 Accepted 응답에 반드시 함께 있어야 하는 것은?
- 결과 본문
- ETag
- 결과를 확인할 위치(Location)와 작업 식별자
- Content-Length
진행 중 응답에 `Retry-After` 를 주는 이유는?
- HTTP 규격이 202 응답에 이 헤더를 요구해서
- 폴링 주기를 숨겨 상태 조회를 보호하려고
- 중간 캐시가 응답을 그만큼 보관하게 하려고
- 상태 API 가 폴링으로 새 병목이 되는 것을 막으려고
작업 제출을 멱등하게 만들어야 하는 이유는?
- 작업 생성 경로가 짧아져 성능이 좋아지기 때문
- 같은 작업 로그가 한 줄로 모이기 때문
- 비동기 API 규격이 멱등성을 요구하기 때문
- 접수 응답이 유실돼 재시도하면 같은 작업이 두 개 만들어지기 때문
job id 로 결과 리소스의 ID 를 그대로 쓰면 생기는 문제는?
- 결과 ID 가 접두어를 달고 길어진다
- 작업이 실패했을 때 그 ID 가 영원히 존재하지 않는 유령 참조가 된다
- 동시에 만든 작업끼리 ID 가 충돌한다
- 결과 ID 가 노출돼 남의 결과를 조회할 수 있다
웹훅이 폴링보다 나은 점과 그 대가를 옳게 짝지은 것은?
- 구현이 쉬움 / 전송 구간의 보안이 약해짐
- 지연 없음 / 클라이언트가 공개 엔드포인트를 갖고 서버가 재시도·서명을 갖춰야 함
- 표준이라 붙이기 쉬움 / 폴링보다 전달이 느림
- 서버가 무상태로 남음 / 이벤트 순서가 깨짐
완료된 작업 상태 조회가 TTL 만료된 뒤 410 Gone 을 주면 좋은 이유는?
- '그런 작업은 없었다'와 '있었지만 기록이 지났다'를 구별할 수 있어서
- 중간 캐시가 결과를 오래 보관할 수 있어서
- 본문 없이 돌려줘 응답이 빨라져서
- 지난 작업의 존재를 숨겨 보안에 유리해서