/v1 API는 서로 독립적인 두 가지 요청 한도를 적용합니다. 둘 중 하나라도
소진되면 요청이 거부됩니다.
API 키별 한도는 키가 사용되는 위치와 관계없이 해당 키를 따라갑니다. IP별 한도는
인증되지 않은 트래픽에 적용되는 유일한 한도이며, 인증된 트래픽에는 두 번째 상한으로
적용됩니다.
제한은 인증 이전에 적용되므로, 유효하지 않거나 누락된 자격 증명으로 보낸 요청도
요청 발신 측의 한도에 포함됩니다. 구체적인 한도 수치는 운영자가 설정하며 변경될 수 있습니다.
아래에 설명된 응답 규약이 안정적인 인터페이스이므로, 이를 기준으로 구현하시기 바랍니다.
apikey:secret 또는 secret:)을 참조하십시오.
BASE를 조직의 리전 호스트로 설정합니다. 자세한 내용은
리전을 참조하십시오.
429 응답
한도가 소진되면 API는429 Too Many Requests 응답과 함께 Retry-After 헤더(초 단위)
및 표준 problem-details 본문을 반환합니다.
429 Too Many Requests
429 응답을
동일하게 처리하십시오. 즉, 대기한 후 재시도하십시오.
429 처리
1
Retry-After 준수
재시도하기 전에
Retry-After 헤더에 명시된 시간(초) 이상 대기하십시오.
더 일찍 재시도하면 어차피 거부될 요청으로 한도만 다시 소모하게 됩니다.2
반복 시 지수 백오프 적용
재시도가 다시 거부되면 백오프 시간을 늘리고 무작위 지터(jitter)를 추가하여
병렬 작업자들이 동시에 재시도하지 않도록 하십시오. 로컬 상한에 맞추기 위해 서버가 지정한
Retry-After 값을 줄여서는 안 됩니다. 서버가
요청한 대기 시간이 재시도 허용 범위를 초과하는 경우에는 재시도를 중단하고
나중에 작업을 다시 예약하십시오.3
요청 속도 평탄화
요청이 몰리는 버스트보다는 일정한 요청 속도를 유지하십시오. 대량 조회 시에는
최대 페이지 크기(
limit=500)를 사용하여 더 적은 요청으로 컬렉션 전체를 조회하십시오.
자세한 내용은 페이지 매김을 참조하십시오. 여러 목록 순회를
병렬로 실행하는 경우(예: Power BI 테이블) 동시성은 적절한 수준으로 유지하고
Retry-After를 준수하여, 일시적인 429 응답으로 전체 새로 고침이 실패하지 않도록 하십시오.429 응답만 재시도하며, 최대 5회까지 시도하고
시도 간 대기 시간은 최대 60초입니다. 그 외의 오류가 발생하면 즉시 중단합니다.
네트워크 타임아웃은 호출자에게 전파됩니다. 타임아웃과 재시도 한도는 사용자의 워크로드에 맞게
구성하십시오. requests는 읽기 타임아웃을 전체 제한 시간이 아니라 데이터를 수신하는 동안의 최대 유휴 시간으로
해석합니다.
LIVING_SECURITY_API_KEY는 시크릿 관리자에서 불러오십시오. 이 예제를 실행하기 전에 requests를
설치하십시오. 사용하려면 get_with_retry("/organization")를 호출하십시오.
Python
권장 새로 고침 일정
키별 한도와 페이지 크기를 기준으로 새로 고침 주기를 정하십시오. 대규모 컬렉션의 전체 이력 로드는 한 번만 발생하는 비용입니다. 정상 상태의 새로 고침에는 증분 구간을 사용하여 각 실행이 한도를 충분히 밑돌도록 하십시오.limit=500는 항상 명시적으로
설정하십시오. 기본값인 25를 사용하면 요청 수가 크게 늘어납니다.
