La prima cosa da notare è che la sintassi della "risorsa" raccomandata per gli URI REST è una convenzione che non è sempre facile da applicare ai casi d'uso reali. Quindi, nonostante una linea guida ragionevole, è solo una linea guida.
Detto questo, in genere si utilizzano gli URI con solo elementi di percorso (cioè senza stringa di query) per identificare gli oggetti in base ai rispettivi ID. Quindi, supponendo che i tuoi ordini abbiano ID univoci, sarebbe comune accedervi tramite URI del modulo /restws/orders/1234 . Se un ordine è identificato in modo univoco da un ID ordine e un ID prodotto perché gli ID ordine sono univoci all'interno di un determinato prodotto ma non a livello globale, un URI come /restws/products/1234/orders/567 sarebbe ragionevole.
Tuttavia, se gli ID ordine sono univoci a livello globale e si desidera trovare solo ordini che soddisfano determinati criteri, ad esempio l'abbinamento di un ID prodotto, il tipo e, eventualmente, la data dell'ordine futuro, il prezzo e così via, un formato stringa di query sarebbe più appropriato: /restws/orders?productId=1234&date=2018-08-21 ecc. Quindi il tuo chocie di API dipende in realtà da cosa sono gli ID univoci ("chiavi primarie") dei tuoi ordini e quali sono solo criteri di ricerca che potrebbero corrispondere a zero o più ordini.
Nella maggior parte dei casi è anche una buona idea evitare la ridondanza - ad esempio, mi aspetto che il prodotto con ID specificato sia di un tipo specifico, quindi obbligare l'utente a immettere sia l'ID che il tipo nel percorso URL sarebbe una cattiva API. Ma se gli ID sono unici solo all'interno di un tipo specifico, ovviamente l'utente deve passare entrambi per identificare la risorsa.