In a comment, Marc de Graauw points to a blog entry where he writes:

[W]hen do the advantages of REST (caching, linking and bookmarking to name some) matter less? For one of my customers I design part of the Dutch national healthcare exchange, which is used to exchange patient data between care providers. Nearly all messages involved include the patient id: therefore most messages are pretty unique, and tied to a particular care context: say a patient visits his GP, or collect medication from his apothecary. In such exchanges, caching doesn’t matter at all. It is possible some data (a patients medication history) is retrieved twice when the patient visits two doctors after another, but in general in such an infrastructure it’s better to simple turn off caching, GET the data twice in the outlier cases and not be bothered by the overhead involved in caching.

Without any particularly evolved knowledge about the domain, I would still argue that there is probably a whole bunch of possible resource where caching would make a lot of sense in this case — a pharmacy, a doctor, a regulation, an insurance company … and even for those cases tied to a particular patient, the fact that he can bookmark his personal information record, his history, and other personal information would be very useful. In other words: I’m reasonably confident that Marc’s design could benefit from being converted to a REST approach — the fact that the patient ID is part of the message does not seem related to the problem domain, but rather to the solution domain.