API 호출: 작업을 줄이고 재시도를 통제하기

핵심 요약

효율적인 API 사용은 데이터 최신성과 정확성을 유지하면서 불필요한 통신을 줄입니다. 호출 수, 전송량, 대기 시간은 별도로 측정해야 합니다.

사람 없는 보안 서버 및 네트워크 통로
이 글의 목차

같은 사용자 경로 비교

십진 킬로바이트를 사용한 가상 예입니다. 기존에는 100회 호출에 응답당 100 kB, 후보안은 20회에 50 kB입니다. 전송량은 10000에서 1000 kB로 90 % 줄지만, 지연 시간도 같은 비율로 줄었다고 볼 수는 없습니다.응답 본문만 계산하며 요청과 헤더는 제외합니다.

가상 지표기존후보
호출 수10020
응답당 크기100 kB50 kB
총 전송량10000 kB1000 kB
경로 소요 시간측정 필요측정 필요

병렬화 전에 작업 줄이기

  • 필요한 필드만 요청하고 문서의 페이지 이동 규칙을 따르세요. 일괄 처리에는 한도와 부분 성공 처리가 필요하며, 큰 페이지가 항상 빠르지는 않습니다.
  • 문맥과 최신성 조건이 허용하면 연결과 응답을 재사용하세요. 동시 실행을 제한하고 서버 작업과 대기열도 측정하세요.
  • 전체 마감 시간과 최대 시도 수를 정하세요. 일시 오류의 재시도에는 무작위 대기를 더하고 여러 계층의 중복 재시도를 확인하세요.

완료된 작업을 중복 실행하지 않기

클라이언트 시간 초과는 서버 취소를 증명하지 않습니다. 생성이나 결제를 반복하기 전에 상태와 공급자의 멱등성 장치를 확인하세요. 대표 부하에서 전체 시간, 오류, 데이터 정확성을 비교하세요.

1차 자료

하나의 API 응답 뒤에 숨겨진 작업을 검사합니다.

단일 GraphQL 쿼리는 여러 하위 서비스 호출을 트리거할 수 있습니다. 클라이언트에서 보이는 지연 시간은 리졸버, 목록 및 탐색된 관계의 비용을 숨길 수 있습니다.

  • 클라이언트에서 하위 서비스까지 작업 추적을 수행합니다.
  • 필드 비용과 실제로 유용한 볼륨을 비교합니다.
  • 캐싱 전 바인딩된 목록과 반복 쿼리를 처리합니다.

1차 자료: OWASP — GraphQL Cheat Sheet. 관련 방법: 실무 가이드 읽기.

Retry-After: 대기, 예산 및 재시도 결정

이 언어판의 상세 참고 설명은 영어로 제공됩니다.

Reducing API calls includes controlling repetition

An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.

  • Trace SDK and proxy retries under one logical identifier.
  • Avoid shortening server instructions merely to fit a budget.
  • Verify an uncertain write’s state before creating a new intention.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS