Jak prawidłowo zaprojektować spokojny interfejs API, aby unieważnić pamięć podręczną?

Question

Mam aplikację, która wymaga danych z Service2, która zwróci tę samą odpowiedź dla danego żądania, na zawsze, chyba że jego baza danych zostanie zaktualizowana. Baza danych jest aktualizowana bardzo rzadko, powiedzmy dwa razy w roku.

Chciałbym zaprojektować rozwiązanie tak, aby aplikacja buforowała odpowiedzi z Service2, ale aby zewnętrznie zapewnić funkcję, która unieważnia pamięć podręczną aplikacji. Myślałem o eksponowaniu usługi RESTful web z Aplikacji, ale nie mam pojęcia, jak zaprojektować ją poprawnie.

/application/cache/invalidate to adres URL, który nie jest RESTOWN - myślałem o tym, że /application/cache/ będzie wywoływane za pomocą HTTP POST. Jednak wygląda na to, że dla prawidłowego projektu RESTful, gdy do aktualizowania zasobu wykorzystywany jest test POST, treść do aktualizacji powinna być zawarta w treści żądania.

Jaki jest właściwy sposób na zaprojektowanie cichego serwisu "InvalidateCache"?

Answer 1

Rozważ użycie DELETE zamiast POST i adresu URL:

/application/cache/ 

W REST, zarówno PUT i DELETE są uważane za działania indempotent. Oznacza to, że mogą one być powtarzane wiele razy z tym samym stanem zasobów wynikowych. W tym przypadku pamięć podręczna jest zasobem, a wiele plików DELETE spowoduje ten sam stan, czyli wyczyszczoną pamięć podręczną.

Można rozważyć dodanie deskryptora do adresu URL, aby wyjaśnić, że wyczyścisz zawartość pamięci podręcznej i nie usuniesz samego obiektu pamięci podręcznej. Może jest coś podobnego do tej, ale to zależy od ciebie. Przejście na tę trasę może również potencjalnie pozwolić Ci na selektywne usunięcie z pamięci podręcznej, jeśli to konieczne.

Answer 2

To może nie odpowiedzieć bezpośrednio na twoje pytanie, ale możesz również zajrzeć do HTTP ETags, które są dobrze przystosowane do buforowania w projektach RESTful.

Pomysł polegałby na tym, że aplikacja pozyska zasoby z Service2, które zwrócą zasoby wraz z nagłówkiem ETag (może to być ostatni zmodyfikowany znacznik czasu lub skrót). Aplikacja będzie następnie buforować ten zasób razem z ETag.

Gdy aplikacja musi ponownie pracować z zasobem, może wysłać HTTP GET do Service2 z nagłówkiem ETag, który ma w pamięci podręcznej.

• Jeśli Usługa2 stwierdzi, że zasób nie został zmieniony, ponieważ został zwrócony do aplikacji po raz pierwszy, to zwraca pustą odpowiedź ze stanu HTTP 304 (nie zmieniła), wskazujący, że aplikacja może użyć danych w pamięci podręcznej.
• Jeśli dane zostały zaktualizowane, Service2 zwraca nowy zasób z nowym nagłówkiem ETag (i stanem HTTP 200).

To podejście sprawdza się dobrze, jeśli nie masz nic przeciwko HTTP GET, aby sprawdzić, czy zasób się zmienił i czy usługa jest łatwa w obsłudze2, może określić, czy zasób się zmienił (bez konieczności wczytywania go).

Zaletą jest to, że Service2 nie musi unieważniać pamięci podręcznej klientów (Application), co może nie być bardzo dobrą praktyką (i może być trudne, jeśli masz wielu klientów).