Professionalism of implementing the HTTP "QUERY" method in an API

Question

Some years ago, the w3c documented a proposal for a method called QUERY, where query information may be passed in as the request body rather than on the request line in query parameters. You can see this here: https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Verb

My Question

I realize you can send any made up verb name along with your HTTP request, however I would like to hear your opinions on the professionalism of adopting a verb like QUERY before that method is accepted as an RFC. If not off-topic, I would welcome exemplary precedents and resources on implementing QUERY.

A Little More Background On QUERY

Just for clarification, my interest in justifying implementing QUERY has 3 primary reasons.

1) Privacy Many HTTP servers, proxies and even application implementations have a tendency to log the entire URI as part of its basic access logs. It is entirely possible that a system may need to be queried by certain attributes that affect regulatory compliance, especially in payment or health systems. Having those query parameters showing up in access logs may be unacceptable.

2) Size Also not mentioned in the w3c proposal is the size constraint of the request line by many HTTP implementations. While not necessarily specified, I have seen issues with some HTTP applications (client & server) failing to handle a request with a certain long length of that request line.

3) Query Complexity Complexity is already well justified in the w3c proposal.

Answer 1

Whether or not it's professional is up to you and your company's policy. It all comes down to risk and technical debt. If I had to communicate with your software as an external party, I would consider it bad practice, not necessarily unprofessional.

I would argue that adopting a standard before it's accepted can be risky. What will you do if the standard is dropped, or when changes happen before it's accepted? Will you continue to work with your own version of the standard, or will you go back and change all your software?

Do you control all the parts that need to communicate using this standard? If so, then you could say that the risk is minimal, since you can make the necessary changes. As soon as you are going to have to communicate or support external parties, or even another developer, the risk grows. The more external factors come into play, the more time (technical debt) and money it will take before the software is updated to the proper standard.

I know this is a lot of 'ifs' - but that's exactly the issue when working with experimental proposals.