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.

  • 3
    so.. like POST but spelt differently? – Ewan Aug 10 at 13:33
  • Not quite like POST from my understanding, a similar mechanism but used only for querrying things – TurtleKwitty Aug 10 at 13:40
  • 2
    The objective and expectation of QUERY is that it's an idempotent safe read-only query. It should not cause a change to data within the system. – andyortlieb Aug 10 at 13:56
  • 3
    More like a GET with a body – Eric King Aug 10 at 14:24
up vote 4 down vote accepted

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.