LabHub

큐와 비동기 API · 비동기 API 설계(202 Accepted·폴링·웹훅) · 퀴즈

퀴즈: 비동기 API

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 결과 본문
    2. ETag
    3. 결과를 확인할 위치(Location)와 작업 식별자
    4. Content-Length
  2. 진행 중 응답에 `Retry-After` 를 주는 이유는?

    1. HTTP 규격이 202 응답에 이 헤더를 요구해서
    2. 폴링 주기를 숨겨 상태 조회를 보호하려고
    3. 중간 캐시가 응답을 그만큼 보관하게 하려고
    4. 상태 API 가 폴링으로 새 병목이 되는 것을 막으려고
  3. 작업 제출을 멱등하게 만들어야 하는 이유는?

    1. 작업 생성 경로가 짧아져 성능이 좋아지기 때문
    2. 같은 작업 로그가 한 줄로 모이기 때문
    3. 비동기 API 규격이 멱등성을 요구하기 때문
    4. 접수 응답이 유실돼 재시도하면 같은 작업이 두 개 만들어지기 때문
  4. job id 로 결과 리소스의 ID 를 그대로 쓰면 생기는 문제는?

    1. 결과 ID 가 접두어를 달고 길어진다
    2. 작업이 실패했을 때 그 ID 가 영원히 존재하지 않는 유령 참조가 된다
    3. 동시에 만든 작업끼리 ID 가 충돌한다
    4. 결과 ID 가 노출돼 남의 결과를 조회할 수 있다
  5. 웹훅이 폴링보다 나은 점과 그 대가를 옳게 짝지은 것은?

    1. 구현이 쉬움 / 전송 구간의 보안이 약해짐
    2. 지연 없음 / 클라이언트가 공개 엔드포인트를 갖고 서버가 재시도·서명을 갖춰야 함
    3. 표준이라 붙이기 쉬움 / 폴링보다 전달이 느림
    4. 서버가 무상태로 남음 / 이벤트 순서가 깨짐
  6. 완료된 작업 상태 조회가 TTL 만료된 뒤 410 Gone 을 주면 좋은 이유는?

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