Czy istnieje standard dla kodów błędów/błędów?

Question

Obecnie piszę API/niektórych klientów do gier szachowych.

Twórcy powinni uzyskać dostęp do interfejsu API za pomocą jednego skryptu (xhrframework.php) i przesłać akcje za pośrednictwem GET. Możliwe, że popełniają błędy podczas przesyłania akcji (Nie wysłano PHPSESSID, brak prawidłowego PHPSESSID, ruch był nieważny, to nie jest ich kolej, ...).

Więc pomyślałem o możliwościach wyświetlania błędów. Wpadłem na kilka pomysłów, jak informują programator, że popełnił błąd:

1. za pomocą komunikatu o błędzie w jasny angielski
   • +: Jest oczywiste, co błąd powinno oznaczać
   • + : informacje, jak naprawić ten błąd może być dodany
   • -: komunikat może się zmienić jak mój angielski nie jest zbyt dobry
   • -: długość wiadomości różni się całkiem sporo - może to być ważne dla programistów C
2. poprzez ab komunikat o błędzie stałej po angielsku - coś podobnego WRONG_PHPSESSID, MISSING_PHPSESSID, INVALID_MOVE, NOT_YOUR_TURN ...
   • +: To zrozumiałe dla człowieka
   • 0: To prawie pewny, że wiadomość nie robi „t zmienić
   • -: długość wiadomości może się różnić nieco
3. poprzez kod błędu z jednej tabeli w dokumentacji, w którym programista może znaleźć znaczenia kodu błędu
   • +: Kod błędu byłby stały
   • +: długościach każdego kodu błędu może być taka sama
   • -: To tajemnicze

I thoguht trzecie rozwiązanie może być dobrym pomysłem, ponieważ xhrframework.php powinien być dostępny tylko przez programistę, który całkiem nieźle już zapoznał się z dokumentacją API.

Teraz chciałbym wiedzieć, czy istnieje standard dla komunikatów o błędach Web-API. W jaki sposób inni (np. Google Maps API) to rozwiązali? Czy powinienem wypisać po prostu pustą stronę z treścią "BŁĄD: 004" lub bez dopełnienia "BŁĄD: 4"?

Które błędy powinny otrzymać liczby? Czy ma sens grupowanie błędów według ich numerów, np. wszystkie błędy zaczynające się od 1 to błędy uwierzytelnienia, wszystkie błędy z dwoma błędami logiki gry? Czy lepiej zacząć od błędu 1 i użyć każdego numeru?

Google Maps API

Jeśli zrobię wrong call do Google Maps API JS, zwraca Java-Script z komunikatem w wyraźnym niemieckim (jak ja mieszkam w Niemczech, chyba).

Google Static Maps API zwraca komunikat w postaci tekstu w przejrzystym języku angielskim, jeśli utworzę wrong call.

Answer 1

Większość usług API naśladować system HTTP kod błędu RFC2817 z zakresów kodów błędów dla różnych rodzajów błędów:

1xx: Informational - Request received, continuing process 
2xx: Success - The action was successfully received, understood, and accepted 
3xx: Redirection - Further action must be taken in order to complete the request 
4xx: Client Error - The request contains bad syntax or cannot be fulfilled 
5xx: Server Error - The server failed to fulfil an apparently valid request 

w kontekście API byś najczęściej używane wartości 4xx do określenia warunków błędów do roboty sprawdzanie poprawności wniosków. 49x są zazwyczaj używane w warunkach błędu bezpieczeństwa.

Answer 2

Nie ma standardu i dlaczego powinno być? Programiści korzystający z interfejsu już muszą się tego nauczyć, co jest prawdopodobnie czymś niestandardowym, więc potrzeba napisania niestandardowego kodu obsługi błędów jest tylko częścią pakietu.

Sugerowałbym, aby nadać sensownego formatu, z którym będziesz się trzymał. Można iść z najlepszym z każdego świata i obejmują wiele różnych informacji, w jaki wrócisz, może wzdłuż tych linii:

[one of "ERROR" or "WARNING" or "MESSAGE"] 
[error code with no spaces, eg "BAD_MOVE"] 
[optional human readable string] 

ten sposób, jeśli nowy rodzaj błędu wymyślił, że starzy klienci nie rozumieją, wciąż mogą rozpoznać, że powrót zaczyna się od "ERROR" i wiemy, że coś poszło nie tak; parsując kod błędu (nie używaj liczb całkowitych, to marnowanie czasu wszystkich), mogą podjąć odpowiednie działania, jeśli błąd jest uwzględniony przez programistę. Wreszcie, jeśli umieścisz przyjazny ciąg dla wybranych błędów, ułatwi to zaprezentowanie użytkownikowi czegoś przyjemnego lub ułatwi debugowanie.