This is a potentially hypothetical question since it has not been determined whether we will be required to do this but I figure it's a question that will come up more often.
When implementing RESTful services the standard approach is that the URI contains the information required to identify the resource in question. While I am not a restafarian there are a lot of advantages to this approach over that we wish to take advantage of.
We are subject to regulatory requirements around protecting certain types of information. Some of these protected elements will end up in resource paths if we follow the basic REST formula.
TLS will cover most of the concerns about because the URLs are encrypted. However, there are a few places where they may be stored in the clear. Notably they are often written to access logs (which is useful) by default and if people use browsers for this, they can be stored in the clear in their browsing history.
Assuming this is an issue and we want to use such an approach it seems there is one prime contender for the solution, which is to encrypt parts of the URI or all of it. Hashing does not seem to be an option since the data is highly predictable and calculating the entire set of values is easy. Encrypting the entire URI will limit a lot of the advantages of the approach. Symmetric encryption requires distributing a secret key widely and therefore defeats the purpose. The option that seems the best is to encrypt on the sensitive data with a public key.
As I understand it, your encrypted output needs to be at least as long as the modulus. So if we go with a 2048-bit key, each the data will need to be at least 256 bytes. This will result in some fairly long URIs but I think that should be OK for a while anyway and that limit may not really apply to our solution.
Does this approach seem valid and/or is there anything else I am missing? Would it be valid to use the same key-pair that would be used for TLS? There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?
NOTE: I should mention that for my specific problem, only authenticated parties would be able to call. This is not something that we mean to be expose on the public internet although mistakes can happen. All parties involved are legally-bound to protect the data. I think it's worth exploring more general usage of such an idea because of the growing popularity of RESTful services.