Am sure this has been discussed before, and I'm opening a can of worms but here goes (if nothing else would be nice to have this as an issue to be easily referenceable)...

The traditional accepted use case forGET is for information retreival andPOST is for uploading information to a server. This is reflected in the language of the definitions as linked in the previous sentences and does not seem to be materially changed in thenew versions currently in draft.

However the sections onDisclosure of Personal Information andDisclosure of Sensitive Information in URIs recognise the privacy and security implications of putting sensitive information in the URL as Query Params and state that "Such services ought to use POST-based form submission instead." Again this language seemsunchanged in the current drafts.

This seems out of sync with the definition of POST provided previously and leads to arguments as to whether information retrieval by sensitive params is an "acceptable" use of POST (particularly for those insisting on a rigiddefinition of REST). Note I'm not talking about authentication cookies here - but more other params which clarify the resouce required, rather than authenticate access to such a resource. For example "download document id 1234" is often an information retreival request, which is supplemented by cookies to confirm access to that document. In this case the document id may be considered sensitive (e.g. if it's a policy number, or a claim identifier) so should not be sent as a URL param which would rule out GET, unless you want to get into providing the params as HTTP Headers instead which just seems like a messy idea.

Of course you could use a GET with a body but the RFCexplicitly notes why this is a bad idea: "sending a payload body on a GET request might cause some existing implementations to reject the request." and this has beenstrengthened in the lastest draft to: "A client SHOULD NOT generate a body in a GET request" in#202

The POST definition doesn't explicitly forbid it's use for information retreival, but all the examples suggest data is being sent to the server for storage (perhaps not the first example, but certainly the others) and there aremany examples of this being debated.

While this has always been an issue, it is getting more and more important in this more privacy-aware world and with various legislation and security requiremnts and I feel the specs could be more explicit, and reflect what I imagine is a common use case for POST.

Therefore should text and/or the examples be added to clarify the position in regards to retreival via POST requests, and to resolve the apparent discrepency in regards to theDisclosure of Sensitive Information in URIs section?