Teraz dla niektórych jest jasne, że taki błąd jest z danej klasy i oznacza konkretną akcję bo to kiedyś ustandaryzowano. W momencie zastąpienia kodów tekstem trzeba by albo odwzorować stary standard, co nie ma raczej sensu, albo tworzyć nowy. I nie mówimy tu o tak naprawdę prostej sprawie. Bo jak określimy chociażby statusy typu 301? Obsługa ze strony przeglądarek, bibliotek i tego wszystkiego co już jest musiałby być przepisana.
@jurek1980: generalnie piszę o projektowaniu nowego API, nie ma sensu zmieniać coś co działa. W moich przykładach podawałem kody HTTP bo są popularne. Język faktycznie może być problemem (o czym wspomniałem w pierwszy poście). Co do bajtów: marnujemy tyle prądu na parsowaniu tekstowych formatów, lekkie zwiększenie rozmiaru dla błędów to praktycznie nic, jeśli mówimy o typowym backendowym API
No mi właśnie o to chodziło, o prostotę frontu. Jak sam wspomniałeś (uwierz lub nie) regex nie należy do najwydajniejszych.
@woolfik chodziło mi o regex w dokumentacji, tak samo na froncie nikt nie sprawdza, czy liczba to \d+
, choć tu akurat wychodzi zaleta liczb jaką jest osobny typ w JSONie.
W przypadku kodu błędu sytuacja jest jasna bo 1 to 1 i wystarczy w słowniku/dokumentacji sprawdzić co oznacza 1 :)
@woolfik zgodzę się, że potencjał na zepsucie jest większy. Z drugiej strony nie potrafię sobie wyobrazić takiej sytuacji. Dodając nowy kod (niezależnie od formatu) i tak musisz zajrzeć do pliku z definicją, zobaczyć czy już nie mamy czegoś podobnego i ewentualnie dodać nowy kod.
Inna sprawa, że samo opisujące się kody mogą sprawić, że ludzie będą je wymyślać ad-hoc bez sprawdzania w słowniku, co faktycznie jest wadą.