Re: Proposed HTTP SEARCH method update

> On 1 May 2015, at 18:12, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
> 
> One of the use cases I am having difficulty is what I will call “MATCH”.  This is a bit different from doing a system wide search as much of the discussion has focused on.  In this case, we want to test if a certain filter condition is true for a given resource and optionally return some attributes (or nothing at all).

yep .

> 
> We talked about this in developing the SCIM protocol.  We decided to go with the POST option since a SEARCH method would be long term (C below).
> 
> I’ve looked at a number of approaches on this case:
> 
> A. A GET is inappropriate because the filter condition cannot be passed on the URL.  It would be ok if it could be passed in the BODY, but I hear that’s bad.

There are two possibilities here, both allowed by the current spec.
 1) GET with Query: and Query-Type: header ( the second one giving the mime type of the header
 2) GET with Content-Type header and body.

There have been no criticisms of (1), only of (2) . 
(2) does not go against any of the more recent specs - it is even allowed, and probably works for most servers. It should be left open for the longer term after studies if it really is problematic and in what circumstances. But 1) is a good fallback position.

The fallback position of both is that if the server does not understand the headers or body, it returns the value it would have returned on a plain GET. This actually works: you can try it on any web server to see :-)

The main problem with a GET is when the resource is to all intents and purposes infinitely long and one really never wants to do a GET on the resource. In that case it is important to be able to run SEARCH ( or some other verb such as QUERY). Could it be that some resource just offer SEARCH/QUERY and not GET in that case?


> B. A POST is problematic because it should be to create or replace the resource.  How does the server detect the intended operation?
> 
> C. A POST + a path extension (e.g., “/.search” giving   https://example.com/Users/<id>/.search <https://example.com/Users/%3Cid%3E/.search>) is a work around works, but seems kludgy.  Access control systems have to know that https://example.com/Users/<id>/.search <https://example.com/Users/%3Cid%3E/.search> is the same resource as https://example.com/Users/<id> <https://example.com/Users/%3Cid%3E>
> 
> D. A POST to /search can also work, but makes for a more complex operation as now we are not talking about an operation based on a URL.  It also may complicate access control since the resource being queried isn’t part of the URL.
> 
> I recall talking to Julian about if-match headers…I can’t remember the pros/cons we talked about. But I do think that the semantics shouldn’t change. I can see adding if-match conditions to a SEARCH command as being useful. I think overloading these might be more complexity.
> 
> I think this is a case that more clearly shows why “SEARCH” is useful. 
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>