Filtrowanie zasobu - path parameters czy query parameters?

Załóżmy, ze mamy zasób pod tytułem zamówienie. Zamówienie ma jakiś atrybut. W tym wypadku jest to status, ale możemy to uogólnić do jakiegoś atrybutu, który ma skończona ilość mozliwych wartości, np. samochód ma markę, zamówienie status itd. (przeciwieństwem tej własności jest np. godzina rozpoczęcia, czyli data, czas trwania, przebieg i inne rzeczy, których może być pierdyliard).

Która ze ścieżek Waszym zdaniem jest lepsza:
/orders/new
/orders?status=new

Wiem, ze ewangeliści prawdopodobnie beda za opcja nr 2, ale widziałem już kilka API, gdzie preferowana była opcja 1. Jakie jest Wasze zdanie?

Pytanie dodatkowe:
Jeżeli statusy, marki samochodów itd. są w naszej aplikacji wyrażone za pomocą intów (klucze obce do tabeli słownikowej), to czy lepiej jest użyć w ścieżce do zasobu stringa, czy inta?

Edit
Pozwoliłem sobie zapytać o to społeczność stack'a, gdyby ktoś był ciekawy, to tu jest temat https://softwareengineering.stackexchange.com/questions/359884/query-parameters-numeric-vs-string/359886#359886

/orders?status=1
/orders?status=new

Wracając jeszcze na chwile do pierwszego pytania, jak widać jeżeli decydujemy się na int to pierwsza możliwość odpada, bo gdyby zastąpić /orders/new id, to dostaniemy ścieżkę do konkretnego zamówienia, np. /orders/1

Nie jestem ewangelistą, ale opcja 1 po prostu wydaje mi się zupełnie bez sensu. "Query string" ma taką nazwę nie bez powodu - służy do tworzenia zapytań. Co jeśli zapytanie będzie musiało mieć więcej niż jeden parametr? Niby można się bawić w zagnieżdżone ścieżki, ale co będzie łatwiejsze i bardziej intuicyjne?
Widzisz jakiś zysk z użycia path zamiast query string?

/orders?status=1
/orders?status=new

Nie mam jakiejś mocnej opinii w tym temacie, ja bym chyba wolał dać stringa, bo ładniej wygląda.