- From: <henry.story@bblfish.net>
- Date: Tue, 28 Apr 2015 23:38:50 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Earlier today it occurred to me [1] that one could perhaps just use GET as a query verb, by adding the query to the unused GET body like this: >>>>> GET /contacts HTTP/1.1 Host: example.org Content-Type: text/query Accept: text/csv select surname, givenname, email limit 10 <<<<< where the result value could be the following if the server understood the query language: >>>>> HTTP/1.1 206 OK Content-Type: text/csv Query-Result: yes surname, givenname, email Smith, John, john.smith@example.org Jones, Sally, sally.jones@example.com Dubois, Camille, camille.dubois@example.net <<<<< One would need a header such as Query-Result in order to be able to distinguish an answer from a server that had understood the query from one answered by a server who did not understand it, and so just returned the whole representation. I am thinking of having it return a 206 as the result is a partial representation of the remote resource. A server that does not understand the query, and does not even know about the possibility that GET can have a body would just return the full list of contacts in csv format. The advantage of this is that a client could send a query asking for a precise part of any data to any resource on the web, without knowing in advance if it had the query capability, but still get back a good response to the request if the server did not understand the query. In the case of SEARCH or QUERY that it is unlikely unless one goes through a well known proxy that the remote resource understands the QUERY so that one really always would need to start with a HEAD or OPTIONS before sending a QUERY. And sending a packet to the other side of the world, is pretty slow. It also ties QUERY nicely into GET semantics. Just a thought at this point. Henry [1] see last paragraph at end of https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0256.html Social Web Architect http://bblfish.net/
Received on Tuesday, 28 April 2015 21:39:20 UTC