Re: Proposed HTTP SEARCH method update

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).

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.

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) is a work around works, but seems kludgy.  Access control systems have to know that https://example.com/Users/<id>/.search is the same resource as https://example.com/Users/<id>

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
phil.hunt@oracle.com