Buforowanie wywołań API Github API

Question

Mam ogólne pytanie dotyczące buforowania wywołań API, w tym przypadku wywołań interfejsu API Github.

Załóżmy, że mam stronę w mojej aplikacji, która pokazuje nazwy plików z repozytorium i treść README. Oznacza to, że będę musiał wykonać kilka wywołań API, aby je odzyskać.

Teraz, powiedzmy, że chcę dodać coś jak memcached pomiędzy, więc nie robię tych połączeń w kółko, jeśli nie trzeba.

Jak normalnie byś się tym zajmował? Jeśli nie włączam webhooka na Githubie, nie wiem, czy pamięć podręczna ma wygasnąć. Zawsze mogłem wykonać jedno połączenie, aby uzyskać bieżący sha HEAD, a jeśli to się nie zmieniło, skorzystaj z pamięci podręcznej. Ale to na poziomie repozytorium, a nie na poziomie pliku.

Mogę sobie wyobrazić, że mógłbym zrobić coś takiego z obiektami-sha, ale jeśli potrzebuję zadzwonić do API mimo to uzyskać to, to pokonuje cel buforowania.

Jak byś się tym zajmował? Wiem, że usługa taka jak prose.io nie ma obecnie buforowania, ale jeśli tak, to jakie byłoby podejście?

Dzięki

Answer 1

Czy korzystanie z buforowania HTTP byłoby wystarczająco dobre dla Twojego przypadku użycia? Celem buforowania HTTP jest nie tylko dostarczenie sposobu na nie wysyłanie żądań, jeśli już masz nową odpowiedź - pozwala to również szybko sprawdzić, czy odpowiedź, którą już masz w pamięci podręcznej, jest ważna (bez wysyłania przez serwer kompletnego odpowiedź ponownie, jeśli jest świeża).

Patrząc na odpowiedzi interfejsu API GitHub, widzę, że GitHub poprawnie ustawia odpowiednie nagłówki HTTP (ETag, Last-modified, Cache-control).

Po prostu wykonujesz GET, np. dla:

GET https://api.github.com/users/izuzak/repos 

i to zwraca:

200 OK 
... 
ETag:"df739f00c5053d12ef3c625ad6b0fd08" 
Last-Modified:Thu, 14 Feb 2013 22:31:14 GMT 
... 

Następnym razem - ty się dostać za ten sam zasób, ale również dostarczyć odpowiednie nagłówki buforowania HTTP tak, że w rzeczywistości jest to warunkowe GET:

GET https://api.github.com/users/izuzak/repos 
... 
If-Modified-Since:Thu, 14 Feb 2013 22:31:14 GMT 
If-None-Match:"df739f00c5053d12ef3c625ad6b0fd08" 
... 

i oto - serwer zwraca 304 Not zmodyfikowana odpowiedź i klient HTTP będzie ciągnąć odpowiedź z pamięci podręcznej:

304 Not Modified 

Tak więc interfejs API GitHub buforuje HTTP poprawnie i powinieneś go używać. Oczywiście, musisz również użyć klienta HTTP obsługującego buforowanie HTTP. Najlepszą rzeczą jest to, że jeśli otrzymasz 304 niezmodyfikowaną odpowiedź - GitHub nie zmniejsza twojego pozostałego limitu połączeń API. Zobacz: http://developer.github.com/v3/#conditional-requests

GitHub API ustawia również nagłówek Cache-Control: private, max-age=60, dzięki czemu masz 60 sekund świeżości - co oznacza, że ​​żądania dla tego samego zasobu wykonane w odstępie mniejszym niż 60 sekund nie będą nawet wysyłane na serwer.

Twoje uzasadnienie użycia pojedynczego warunkowego żądania GET do zasobu, który na pewno się zmieni, jeśli cokolwiek w repozynie zmieniło się (na przykład zasób pokazujący SHA HEAD) brzmi sensownie - ponieważ jeśli zasób się nie zmienił, wtedy nie musisz sprawdzać poszczególnych plików, ponieważ nie zostały one z pewnością zmienione.