测验：异步 API

202 Accepted 응답에 반드시 함께 있어야 하는 것은?

• 결과 본문
• ETag
• 결과를 확인할 위치(Location)와 작업 식별자
• Content-Length

진행 중 응답에 Retry-After 를 주는 이유는?

• HTTP 규격이 202 응답에 이 헤더를 요구해서
• 폴링 주기를 숨겨 상태 조회를 보호하려고
• 중간 캐시가 응답을 그만큼 보관하게 하려고
• 상태 API 가 폴링으로 새 병목이 되는 것을 막으려고

작업 제출을 멱등하게 만들어야 하는 이유는?

• 작업 생성 경로가 짧아져 성능이 좋아지기 때문
• 같은 작업 로그가 한 줄로 모이기 때문
• 비동기 API 규격이 멱등성을 요구하기 때문
• 접수 응답이 유실돼 재시도하면 같은 작업이 두 개 만들어지기 때문

job id 로 결과 리소스의 ID 를 그대로 쓰면 생기는 문제는?

• 결과 ID 가 접두어를 달고 길어진다
• 작업이 실패했을 때 그 ID 가 영원히 존재하지 않는 유령 참조가 된다
• 동시에 만든 작업끼리 ID 가 충돌한다
• 결과 ID 가 노출돼 남의 결과를 조회할 수 있다

웹훅이 폴링보다 나은 점과 그 대가를 옳게 짝지은 것은?

• 구현이 쉬움 / 전송 구간의 보안이 약해짐
• 지연 없음 / 클라이언트가 공개 엔드포인트를 갖고 서버가 재시도·서명을 갖춰야 함
• 표준이라 붙이기 쉬움 / 폴링보다 전달이 느림
• 서버가 무상태로 남음 / 이벤트 순서가 깨짐

완료된 작업 상태 조회가 TTL 만료된 뒤 410 Gone 을 주면 좋은 이유는?

• '그런 작업은 없었다'와 '있었지만 기록이 지났다'를 구별할 수 있어서
• 중간 캐시가 결과를 오래 보관할 수 있어서
• 본문 없이 돌려줘 응답이 빨라져서
• 지난 작업의 존재를 숨겨 보안에 유리해서