First thing to note is that the recommended "resource" syntax for REST URIs is a convention which is not always easy to apply to actual use cases. So, while a reasonable guideline, it is just a guideline.
That being said, usually you use URIs with only path elements (i.e. no query string) to identify objects by their IDs. So, assuming your orders have unique IDs, it would be common to access them via URIs of the form
/restws/orders/1234. If an order is uniquely identified by an order ID and a product ID because order IDs are unique within a given product but not globally, a URI such as
/restws/products/1234/orders/567 would be reasonable.
However, if order IDs are unique globally and you want to just find orders which match certain criteria, such as matching a product ID, type, and perhaps in the future order date, price, and so on, a query string format would be more appropriate:
/restws/orders?productId=1234&date=2018-08-21 etc. So your chocie of API actually depends on what the unique IDs ("primary keys") of your orders are and what are just search criteria which may match zero or more orders.
In most cases it is also a good idea to avoid redundancy - for example I would expect product with given ID to be of one specific type, so forcing the user to enter both the ID and the type in the path URL would be a bad API. But if the IDs are unique only within a specific type, then of course the user must pass both in order to identify the resource.