The idea that links to foreign keys (IDs) should be in the format of a URL is an interesting idea. In practice, I don't think it's a good idea since it makes assumptions about what API consumers want to do with the data -- it assumes they want to fetch it, when there could be several other actions they could take.
Including the link URL as a template in a separate field is a potential possibility, but (a) it will add a ton of duplicated data to collections results, (b) it relies on your consumer parsing and inserting the field into their call every time, which if they care about the efficiency of their own code they're probably not going to do, so you don't get any added flexibility.
It was my understanding that representing foreign keys as URLs is a basic principle of REST. The URL is the canonical representation of the object in question. The URL is needed for all actions upon it, not just fetching.
If you're being strict about REST, you're absolutely right. But I have spent a lot of my career building REST APIs for people and from that I've learned that what most people mean when they say "RESTful" is "easy to use, and easy to read". Arguably including the foreign keys as URLs makes it easier to use, but I'm arguing that it's not :-)
However, not providing the URL of a resource makes assumptions that the consumer knows how to manipulate the data you are providing into a usable URL. If you want your resources to be discoverable and easily consumed by programs which have no knowledge of your specific application, then it can be a good way of doing it.
The point of using URLs is that URLs have a reasonably strong assurance of (global) uniqueness and are somewhat self-documenting -- the same reason XML namespaces are URLs.
Including the link URL as a template in a separate field is a potential possibility, but (a) it will add a ton of duplicated data to collections results, (b) it relies on your consumer parsing and inserting the field into their call every time, which if they care about the efficiency of their own code they're probably not going to do, so you don't get any added flexibility.