I'm working on a RESTful API in the healthcare insurance industry. As a regulatory measure, we need to keep sensitive member information hidden as much as possible.One of the issues we've identified is HTTP logs, which tend to log URLs, so a GET using a member's identifiers (which are covered under this regulation) aren't usable.
We've been able to come up with a resource identifier that doesn't contain any sensitive information. However, for a client application to find that resource identifier, they would need some method that takes in the sensitive information and returns the "safe" resource identifier.
CWE suggests using POSTs (https://cwe.mitre.org/data/definitions/598.html) to keep information out of the URI, but faking a GET via a POST doesn't feel very RESTful.
My gut thought is to have a PUT endpoint which takes in the sensitive keys in the request body and returns the safe URI (Maybe with a 303 redirect? That might be going wide).
I know there are similar questions elsewhere in SO about this topic, but the answers tend to be more "Are you sure your data is sensitive?" (Yes, I'm sure) and "Why don't you just use HTTPS?" (I am, but I want to avoid HTTP logs, and someone else changing the architecture and accidentally capturing them somewhere unsafe.)
How would you design this interaction RESTfully?