I guess I'm asking if this is something I really should avoid doing

No, you don't need to avoid doing this -- a URI is an identifier; clients and intermediate components should not be trying to extract any semantic information from them (think "surrogate key" in a database).

Mark Seemann writes about avoiding hackable urls.

Pay attention to the replies, especially Dan Kubb's suggestion to use HMAC with a server side secret to distinguish server generated identifiers from others without sacrificing readability. It may be an easier fit for your use case than hashing/encrypting the entire target-uri.

There are also some edge cases you need to consider - like what you do with a URI template? Or (equivalently) a GET form in HTML?

That said, you might want to consider carefully whether opaque URI are really going to give you a competitive advantage in your domain? Is the time you are going to invest in bespoke request routing going to be paid back somewhere?

I guess I'm asking if this is something I really should avoid doing

No, you don't need to avoid doing this -- a URI is an identifier; clients and intermediate components should not be trying to extract any semantic information from them (think "surrogate key" in a database).

Mark Seemann writes about avoiding hackable urls.

Pay attention to the replies, especially Dan Kubb's suggestion to use HMAC with a server side secret to distinguish server generated identifiers from others without sacrificing readability. It may be an easier fit for your use case than hashing/encrypting the entire target-uri.

There are also some edge cases you need to consider - like what you do with a URI template? Or (equivalently) a GET form in HTML?

That said, you might want to consider carefully whether opaque URI are really going to give you a competitive advantage in your domain? Is the time you are going to invest in bespoke request routing going to be paid back somewhere?