Egyrészt nem azt mondom, hogy jó, hanem hogy ezt szülte a gyakorlat, és jobb elfogadni, mint az elméletet erőltetni.
Másrészt azt mondom, hogy nem by definition. Eleve van egy félreértés.
Létezik tiszta REST, amikor nincs semmi egyedi logika (és így semmi egyedi hibakód sincs). Hogy nézne ki egy CRUD API, ahol egy adatbázisból entitásokat kérsz le, hozol létre, módosítasz? GET-tel lekéred, ha nincs olyan, 404. PUT-tal hozod létre, stb. Itt a HTTP maga a logika, a HTTP fölött már csak entitások vannak, nem a kérésre szóló egyedileg összerakott üzenetek.
És létezik RPC over HTTP. Mint írtam, itt az lenne a tiszta, ha minden egyes RPC kérésre 200-as kód jönne vissza hiba esetén, és a HTTP válasz tartalmazná XML vagy bármilyen formában, hogy hiba történt-e vagy sem. Ha nem található a HTTP végpont, akihez beszélünk (pl. nincs /GetFooBar mert át lett nevezve /GetFoo-ra), 404 jön vissza, de ha nem található egy erőforrás, amiről az RPC szól (pl. /GetFoo végpont van, de az 5-ös azonosítójú Foo már törölve lett), akkor 200-as kód illik hozzá.
Külön-külön ezeket teljesen tisztán meg lehetne csinálni. Tehát ezért nem fucked by design.
A gyakorlat viszont az, hogy ez a kettő keveredni szokott, mert egyszerű CRUD hívásokra egyszerűbb az előbbi, és az élet sosem egyszerű, mindig kelleni fog valami egyedi RPC hívás (bonyolultabb POST vagy akár több entitást magába foglaló GET), akkor meg jobb az utóbbi.
Végső soron az számít, hogy dokumentálva van-e, kliens oldalról könnyen használható-e, működik-e.