Indeks
Status
(komunikat)
Stan
Typ Status
definiuje model błędu logicznego, który jest odpowiedni dla różnych środowisk programowania, w tym interfejsów API REST i interfejsów API RPC. Jest używany przez gRPC. Oto model błędu:
- Proste w obsłudze i zrozumiałe dla większości użytkowników
- Elastyczność, która zaspokaja nieoczekiwane potrzeby
Opis
Komunikat Status
zawiera 3 rodzaje danych: kod błędu, komunikat o błędzie i szczegóły błędu. Kod błędu powinien być wartością wyliczeniową google.rpc.Code
, ale w razie potrzeby może akceptować dodatkowe kody błędów. Komunikat o błędzie powinien być przeznaczony dla programistów w języku angielskim i ułatwiać im understand i understand błędu. Jeśli potrzebny jest zlokalizowany komunikat o błędzie, który wyświetla się użytkownikowi, umieść go w szczegółach błędu lub zlokalizuj go w kliencie. Opcjonalne szczegóły błędu mogą zawierać dowolne informacje o błędzie. W pakiecie google.rpc
istnieje wstępnie zdefiniowany zestaw typów szczegółów błędów, których można używać w przypadku typowych błędów.
Mapowanie języka
Komunikat Status
jest logiczną reprezentacją modelu błędu, ale niekoniecznie jest to rzeczywisty format przewodu. Gdy komunikat Status
jest ujawniany w różnych bibliotekach klienta i różnych protokołach przewodów, można go zmapować na różne sposoby. Na przykład prawdopodobnie zostanie ona zmapowana na pewne wyjątki w Javie, ale prawdopodobnie będzie zmapowana na pewne kody błędów w języku C.
Inne zastosowania
Modelu błędu i komunikatu Status
można używać w różnych środowiskach – z interfejsami API lub bez nich, aby zapewnić spójne wrażenia programistyczne w różnych środowiskach.
Przykładowe zastosowania tego modelu błędów:
Błędy częściowe. Jeśli usługa musi zwracać klientowi częściowe błędy, może umieścić element
Status
w normalnej odpowiedzi, aby wskazać te błędy.Błędy przepływu pracy. Typowy przepływ pracy ma wiele etapów. W każdym kroku może pojawić się komunikat
Status
służący do zgłaszania błędów.Operacje wsadowe. Jeśli klient korzysta z żądania zbiorczego i odpowiedzi zbiorczej, komunikat
Status
powinien zostać użyty bezpośrednio w odpowiedzi zbiorczej – po jednym dla każdego błędu podrzędnego.Operacje asynchroniczne. Jeśli wywołanie interfejsu API powoduje umieszczenie asynchronicznej operacji w wyniku uzyskania odpowiedzi, stan tych operacji powinien być reprezentowany bezpośrednio za pomocą komunikatu
Status
.Logowanie. Jeśli niektóre błędy interfejsu API są przechowywane w dziennikach, komunikat
Status
może zostać użyty bezpośrednio po usunięciu niektórych błędów ze względów bezpieczeństwa lub prywatności.
Pola | |
---|---|
code |
Kod stanu, który powinien być wartością wyliczeniową |
message |
Komunikat o błędzie widoczny dla dewelopera w języku angielskim. Każdy komunikat o błędzie widoczny dla użytkownika powinien być zlokalizowany i wysyłany w polu |
details[] |
Lista komunikatów zawierających szczegółowe informacje o błędzie. Istnieje wspólny zestaw typów wiadomości używanych przez interfejsy API. |