Ono je to naprosto vporadku i z hlediska uzivatelsky privetivosti. Predevsim proto, ze jde o zcela jednoznacny identifikator, narozdil ud ruznych "uzasne seo friendly" nazvu, kam se pak stejne musi jeste prigenerovat nejakej balast, a ktery si nikdo pamatovat nebude, v pripade pouziti ID nemuze dojit k mylce a odkazu na jiny clanek se stejnym/podobnym nazvem.
Pokud clanek ma adresu /clanek/xyz/ a xyz neexistuje, server vrati 404 (to je v poradku).
Ale pokud se na clanek odkazujete jako /clanek/?id=xyz a xyz neexistuje, pak je nespravne vratit odpoved 404. Chybne parametry v GETu lze ignorovat nebo vratit 400 a to uz neni uzivatelsky ani SEO friendly.
Pokud uz tu tedy zminujete RFC 2396, tak to rika: "The query component is a string of information to be interpreted by the resource."
Jinak receno, resource uz je znam (tim je path) a tomu predame query. Takze query neidentifikuje resource, pouze je resourcem interpretovan. Takze vracet 404 na zaklade chybneho query je spatne.
path a query su sucastou URI, a 404 oznacuje nenajdenu URI, nie nenajdenu path :) (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)