Komunikaty błędów w architekturze REST'owej

Ostatnio zacząłem się zastanawiać jak powinno wyglądać przerabianie komunikatów dla końcowego użytkownika. Sprawdzając kilka większych serwisów (takie jak Google, Facebook, Spotify itd) widzę, że przekazują jakiś komunikat błędu który da się łatwo zrozumieć (message, text, nazwa pola nieważna). Jednakże zacząłem się zastanawiać, dla kogo tak naprawdę są przeznaczone te komunikaty błędu - dla developera, który korzysta z API czy są one bezpośrednio przekazywane końcowemu użytkownikowi? Podobną sytuację widzę podczas tworzenia systemów gdzie REST przesyła frontendowi przygotowany komunikat błędu który jest bezpośrednio wyświetlany użytkownikowi. Czy nie powinno być tak, że backend wysyła jakąś odpowiedź w której są zawarte kody błędu oraz krótki opis błędu (plus np. wartość którą dostał, a wartość którą oczekiwał), natomiast sam komunikat błędu tworzy już sobie frontend na podstawie np. customowego kodu błędu (400 jest zbyt ogólny, nie mówi w którym miejscu dokładnie jest błąd, poza tym można zwrócić tylko jeden Http status)? Czy to co leci od RESTa, nie powinno być informacją dla developera? Rozumiem wtedy komunikat błędu jako swego rodzaju dokumentację, że nie trzeba się uczyć na pamięć customowych kodów błędu.

Edit: Nie chciałem tego wątku umieszczać w jakimkolwiek z działów z Programowania, ponieważ problem nie jest związany z żadnym językiem programowania a z REST'em.

Nie ma przyjętej jednej konwencji. Jeśli twierdzisz, że komunikat błędu nie powinien być bezpośrednio pokazywany userowi bo to rest to tak samo można by powiedzieć o danych pobieranych z resta no ale to przecież było by bez sensu :) Po prostu w konkretnym projekcie jest przyjęta konkretna konwencja czasem to jest jakiś specyficzny kod, który trafia do translacja a czasem pełna odpowiedź (szczególnie wtedy gdy się przyjmuje od razu, że serwis zawsze będzie w danym języku i nie dostanie translacji). Musisz podejść do tego, że 2xx niczym się nie różni od 4xx czy 5xx, front wie co chce dostać i tak to przetwarza i tyle. A co jest w danych to jest ustalone już przez zespół :)

Zwykle (w różnych językach i zastosowaniach) developer złapie 2-4 najczęstsze wyjątki, ale zawsze jest problem co, gdy z poza tej listy.
Na frontendzie najgorsze co może być, to pozamiatanie pod dywan tego przypadku. Któryś portal po ewidentnych błędach wyświetla: "operacja zakończona pomyślnie". Dobry string z opisem błędu od backendu można wykorzystać, osłodzić "pracujemy nad tym" ...

@AnyKtokolwiek: nie no błąd musi być błędem, nie o to w tym chodziło. Ja dla nieobsługiwanych wyjątków wyświetlam coś w stylu "Nastąpił nieoczekiwany błąd, spróbuj za chwilę. Jeśli błąd się powtarza skontaktuj się z supportem."

Zwracaj zawsze HTTP 200, a w response:

{
    "httpErrorCode": 404,
    "httpErrorMessage": "not found"
}

Wtedy frontend się nie posypie, a jest pełna informacja o błędzie. Podejście zatwierdzone przez najlepszych architektów™.

PS. Ten post jest ironiczny, a pomysł debilny. Dlatego mogli wpaść na niego tylko najlepszy architekci™. Jest to całkowicie złe, ale takie rzeczy się też spotyka.

Ja rozumiem, że konwencja przyjęta przez zespół (niejednokrotnie łamiąca dobre praktyki poprzez np nie używanie czystego angielskiego a Polglishu) jest rzeczą ważniejszą ale jednak znając dobre zasady jakich powinno się przestrzegać i świadome nieprzestrzeganie ich oznacza, że jest się świadomym plusów i minusów korzystania z "dobrych praktyk". Uważam też, że skoro powstało coś takiego jak "dobre praktyki", które są potwierdzone przez środowisko to można założyć, że w większości nowych projektów można się do nich zastosować i warto je rozważyć (w kontekście za i przeciw). Podchodzę też do tego (od strony frontendu), że 2xx oznacza Sukces a 4xx, 5xx oznacza że coś poszło nie tak (zwłaszcza gdy serwer mógłby zwrócić dla jednego endpointu np. 400 - bo np, wiek jest ujemny, lub 409 - bo np email jest już zajęty), oczywiście mając na uwadze że trzeba odpowiedni komunikat błędu wyświetlić użytkownikowi.
Dzięki za odpowiedzi, chyba już znalazłem odpowiedź :)

Ja kiedyś budowałem API, które w responsie zwracało taką strukturę:

• UUID błędu (do analizowania logów)
• kolekcja błędów:

1. unikalny kod błędu w formacie: 3 litery oznaczające typ błędu (SECurity, VALidation, BUSiness, itp.), trzy cyfry oznaczające feature i trzy oznaczające konkretny błąd.
2. prosty komunikat błędu dla programisty frontendu.

Idea była taka, że frontendowiec dzięki unikalnemu kodowi może u siebie wyświetlić piękny i jasny komunikat dla użytkownika w najnowszym frameworku. Niestety dla frontendowców proste rozwiązania są za mało hipsterskie i efekt był taki, że komunikaty musieliśmy zmieniać na backendzie. Najwyraźniej nie ma jeszcze wystarczająco hipsterskich frameworków pozwalających na budowanie map kod => komunikat.

Tak więc, zanim dobrze zaprojektujesz API, upewnij się, że nie pracujesz z ludźmi, którzy je zgwałcą.