Github API 페이징을 사용한 조건부 요청

Question

컨텍스트 : 사용자에게 주기적으로 (하루, 시간 또는 몇 분마다) 별표 된 저장소의 전체 목록을 검색하려고한다고 가정 해 봅시다.

그렇게 적어도 두 방법이 있습니다

1) https://api.github.com/users/evereq/starred에 도착하고 다음 페이지의 URL을 얻을 '링크'응답 헤더에 = '다음'(우리가 확인해해야와 URL을 사용하여 실행까지 우리는 응답으로 "다음"페이지를 얻지 못한다. 결국 우리는 끝까지 도달한다.) Github의 권장 접근법 인 것 같습니다.

2) 결과에서 0 개의 결과가 나타날 때까지 https://api.github.com/users/evereq/starred?page=XXX까지 GET을 사용하여 'page'매개 변수를 반복합니다 (1에서 무한대로). 결과가 0 인 경우 완료됩니다 (예 : 페이지 번호 대신 Github이 "해시"값으로 이동할 수 있기 때문에 권장하지 않습니다 .Github은 일부 API 작업을 위해 이미 수행했습니다.).

이제 우리는 API 사용 한도 (및 트래픽, 세계의 나무 등)를 저장하기 위해 조건부 요청 (http://developer.github.com/v3/#conditional-requests 참조)을 사용하고자합니다.

예를 들어 'If-None-Match'를 요청 헤더에 추가하고 응답 상태가 304 (수정되지 않음)인지 확인하십시오. 그렇다면 마지막 요청에서 변경된 사항이 없음을 의미합니다. 괜찮아.

그러나 위의 1)과 2)에서 우리가 멈추는 시간을 감지하는 방법과 관련된 문제는 조건부 요청을 사용할 때 더 이상 작동하지 않습니다.

e.e. 접근법 1)을 사용하면 조건부 요청을 사용할 때 링크 응답 헤더를 전혀 얻지 못합니다. 그래서 ETag가 이미있는 페이지보다 큰 페이지로 하나 이상의 요청을 실행해야합니다. 그러면 결과가 0이고 완료되었다는 것을 알 수 있습니다. 그렇게하면 기본적으로 Github API에 대한 하나의 요청을 "낭비"합니다 (조건부 요청 헤더가 누락되어).

접근 방식 2)과 동일하게, 기본적으로 상태 304의 요청마다 0 개의 응답이 있습니다. 다시 말하면, 완료되었음을 알기 위해서는 적어도 하나의 추가 요청을 만들어 0 개의 결과를 반환해야합니다.

그래서 문제는 Github API가 (적어도 304 페이지의 결과 ETag를 사용하는 쿼리를 통해) 링크 응답 헤더를 돌려 보내지 않는 조건부 요청을 할 때 어떻게 페이징을 중지해야 하는지를 알 수 있습니까? Github API 구현의 버그입니까, 아니면 뭔가 빠졌습니까?

최대 페이지 번호를 알 수 없으므로 언제 멈추려면 "폐기물"요청을 하나 더 실행하고 0 개의 결과가 다시 나오는지 확인하십시오!

또한 Github에서 별표 리포지토리의 총 개수를 쿼리하는 방법을 찾을 수 없습니다. (응답을 통해 반복해야하는 페이지 수를 계산할 수 있습니다.) 응답에 "X-Total-Count" 그래서 페이지 수에 대한 간단한 수학 사용을 중단해야 할 때를 압니다.

그 하나 ('끝') 요청을 저장하고 조건부 요청을 사용하는 방법에 대한 아이디어가 있으십니까?

하루에 하나의 요청을하면 그 낭비를 받아 들일 수 있지만 분당 요청하면 어떻게해야합니까? 모든 API 사용 제한을 빠르게 사용할 수 있습니다!

UPDATE

음, (수 그러나 어디에서나 문서에 그것을 발견, 그래서 그 규칙 아니면 그냥 가정의 경우 반드시 유의하지 않음) 몇 가지 더 테스트 후, 지금 "규칙"은 다음을 참조하십시오 : 사용자 별 경우 새로운 것, 요청 된 모든 페이지에 대한 결과는 이전과 비교 된 다른 ETag 값을 포함하며 더 이상 상태 304를 갖지 않습니다! 즉, 첫 번째 페이지를 요청하고 상태를 확인하는 것으로 충분합니다. 304가 수정되지 않은 경우 다음 페이지를 확인할 필요가 없습니다. 즉, 페이지에서 변경된 사항이 없으므로 완료됩니다. 올바른 접근인가 아니면 우연의 일치인가?

Answer 1

콘텐츠가 1으로 변경되면 Link 응답 헤더에서 실제로 페이지 매김 관계를 반환합니다. 해당 호출에 대해 since 매개 변수를 지원하지 않으므로 가장 최근 결과를 기준으로 정렬하고 마지막으로 알려진 ID 또는 타임 스탬프 (정렬 기준에 따라)에 대한 클라이언트 측 커서를 유지하고 표시 될 때 페이징을 중지해야합니다 페이지가 매겨진 결과에서 조건부 요청은 Page 1이 변경되었는지 여부를 알려줍니다.

우리의 리스팅 방법을 계산할 수있는 방법은 아직 정해지지 않았지만 실제로 로우 팁 솔루션은 페이지 크기를 1로 설정하고 rel=last 링크 관계를 잡고 page 매개 변수 값을 확인하십시오.

희망이 있습니다.