I am not sure what you try to achieve. You said that you still have just one collection under /queries and /users. What should be the result of sending new collection?

1. New collection overwrites currently existing collection

   In this case new collection effectively substitutes an existing one. In that case I would say that PUT request to /queries and /users with new collection as a payload is the way to go.

2. Elements from new collection are appended to existing entries

   In that case you can provide new endpoint for that, e.g. POST /queries/bulk with collection of queries to append.

If your concern is that underlying collection might not exist when POSTing new (single) element – that should not bother API user at all. GET /queries should be considered an empty list, whether or not something physically exists there. Similarily, POST /queries should always work, and it's API implementation job to create underlying physical collection if one doesn't exist.

I am not sure what you try to achieve. You said that you still have just one collection under /queries and /users. What should be the result of sending new collection?

1. New collection overwrites currently existing collection

   In this case new collection effectively substitutes an existing one. In that case I would say that PUT request to /queries and /users with new collection as a payload is the way to go.

2. Elements from new collection are appended to existing entries

   In that case you can provide new endpoint for that, e.g. POST /queries/bulk with collection of queries to append.

If your concern is that underlying collection might not exist when POSTing new (single) element – that should not bother API user at all. GET /queries should be considered a list (maybe empty one), whether or not something physically exists there. Similarily, POST /queries should always work, and it's API implementation job to create underlying physical collection if one doesn't exist.