In the UI we follow hal links to find the URL for a certain endpoint.
For example, the service that wants to use the endpoint to find the top level communities stores a path from the root of the rest api to the endpoint it needs: 'communities', 'search', 'top'.
This means: go to the root endpoint of the api which is found in the config. From there, follow the HAL link with the name communities, from there follow the link search and from there, the HAL link top will contain the URL of the endpoint you need.
The reason we do it like that is so that the server can change the URL of any endpoint (apart from the root) at any time, and the UI will still work.
As a consequence, if any endpoint in this chain of links doesn't make its own set of links public, then it doesn't matter if the end goal is public, we can't discover the URL and have to hardcode it.
I noticed this problem recently with the findByToken endpoint, needed to register a new EPerson. Its corresponding linkpath would be 'registrations', 'search' 'findByToken', but because the registrations endpoint returns a 405 we can't discover the URL to the search endpoint within it.
Another example are the resourcepolicy search endpoints
For caching purposes, the UI adds an ?endpointMap parameter to each request we make purely for the sake of getting those links. Perhaps the rest api can take that parameter in to account (or another similar one), and only return the links for those requests. That would probably be better for performance as well because we can let the api know in advance not to generate anything but the _links section.