Status 

Obsługa klucza idempotentności jest dzisiaj częściowa. Wybrane wewnętrzne mutacje ponawiania — na przykład przepływy ponowienia rozliczeń zamówień i ponowienia rozliczeń zwrotu — już akceptują klucz idempotentności i używają go do deduplikacji podrzędnych wywołań procesora płatności. Nie ma jeszcze wystandaryzowanego argumentu idempotencyKey we wszystkich mutacjach tworzenia skierowanych do klientów na Zonos Graph; to jest zaplanowane. Dopóki nie zostanie wdrożone, użyj poniższych wzorców, aby zachować bezpieczność mutacji do ponowienia.

Mutacje domyślnie bezpieczne 

Niektóre mutacje są naturalnie idempotentne, ponieważ wykonują upsert za pomocą stabilnego identyfikatora, który dostarczasz. Gdy wywołasz te operacje z tym samym wejściem, wynik jest taki sam — nie ma ryzyka tworzenia duplikatów.

• Mutacje, które pobierają unikalny identyfikator dostarczony przez sprzedawcę (na przykład externalId zamówienia), zwrócą istniejący rekord przy powtórzonym wywołaniu zamiast tworzenia nowego.
• Operacje tylko do odczytu (zapytania) są zawsze bezpieczne do ponowienia.

Jeśli możesz dołączyć własny stabilny identyfikator do zasobu, który tworzysz, wybierz tę ścieżkę.

Wzorce dla mutacji, które nie są naturalnie idempotentne 

W przypadku mutacji, które tworzą zasoby bez klucza dostarczonego przez sprzedawcę, traktuj je jako co najwyżej raz z Twojej strony:

1. Utrwal żądanie przed wysłaniem. Zapisz wiersz w swojej bazie danych (status pending) przed wywołaniem sieciowym.
2. Wyślij mutację. Po powodzeniu zapisz zwrócony identyfikator zasobu w stosunku do Twojego wiersza oczekującego (status committed).
3. W przypadku błędu sieciowego nie ponawiaj ślepo. Zapytaj Zonos Graph, aby określić, czy zasób został utworzony (na przykład poprzez wylistowanie zasobów utworzonych w ciągu ostatnich kilku minut dla Twojego konta lub poprzez zapytanie o powiązany zasób, który możesz skorelować). Ponawiaj tylko jeśli możesz potwierdzić, że zasób nie jest obecny.
4. Użyj unikatowego ograniczenia w swojej bazie danych na jakimkolwiek kluczu biznesowym reprezentującym żądanie, aby duplikat ponowienia z Twojej własnej aplikacji nie mógł podwójnie wysłać żądania.

Dostarczanie webhooków jest co najmniej raz 

Podczas korzystania z webhooków Zonos projektuj programy obsługi tak, aby były idempotentne — to samo zdarzenie może być dostarczone więcej niż raz. Deduplikuj po identyfikatorze zdarzenia. Aby znaleźć pole identyfikatora zdarzenia, zobacz Webhooks.

Dokąd zmierza platforma 

Podstawowa platforma już uruchamia przepływy kluczy idempotentności w produkcji dla ponowień rozliczeń: klucz ogranicza próbę ponowienia i uniemożliwia duplikatowe wywołania procesora płatności. Pracujemy nad ujawnieniem tego samego wzorca jako opcjonalnego argumentu idempotencyKey w mutacjach tworzenia skierowanych do klientów. Po dostarczeniu, Graph zwróci oryginalną odpowiedź dla każdego kolejnego wywołania z tym samym kluczem w oknie przechowywania. Ta strona zostanie zaktualizowana, gdy powierzchnia będzie ogólnie dostępna.

Jeśli wystandaryzowane klucze idempotentności w mutacjach skierowanych do klientów blokują Twoją integrację, skontaktuj się z wsparciem.