You are essentially asking if it is safe to pass secret parameters in a GET request. This is actually classified as a vulnerability. It is not feasible to brute force a sufficiently long pseudorandom string, assuming the server simply returns a static 404 response whenever an invalid path is specified, but there are numerous other security issues in practice that make this a dangerous technique:
Logging software often logs GET requests in plaintext, but not POST.
Using GET makes CSRF trivial* when processing active content.
Referer headers may leak secret values to other websites.
Browser history will retain secrets passed in GET requests.
Your second example has
/admin/ in it. This implies to me that knowledge of this path alone would be sufficient to authenticate to the server in an administrator context. This is very insecure and should not be done anymore than
/?password=hunter2, a major web security faux pas.
Instead, secrets should be sent in a POST request. If this is not possible to do or if your threat model is exclusively to prevent brute force of the URL (for example, password reset links which are promptly invalidated after they are used), then it should be safe if done carefully. I am not aware of any side-channel attacks that would provide a method to obtain the string faster than brute force.
* Avoiding parameterized GET requests does not prevent CSRF attacks, which is a common misconception as there are various ways to similarly abuse POST (fake forms, etc), but passing secrets in GET does make CSRF easier.