Subject: Re: [scim] Searching with POST instead of GET

From: Scotty Logan <[email-masked]>
Date: Thu, 19 Jul 2012 15:38:39 -0700

On Fri, Jun 29, 2012 at 8:35 AM, Kelly Grizzle
<[email-masked]> wrote:
> I don’t know how often there will be a security concern over GET parameters,
> although I can see some of the more security conscious worrying about this.
> My vote would be to simply add official support for the GET method in Bulk
> requests (it is currently the only excluded method).  Clients that are not
> worried can use a normal GET request and others could use a POST to /Bulk
> with a GET request in the payload.

Coming to this late… finally catching up on mail…

One approach that's come up in some recent discussions at work about
search APIs is to treat complex (or in this case sensitive) searches
as (temporary) resources:

POST /search HTTP/1.1
Content-type: application/json
…

{ … search description… }

The server responds with a 201 and a location:

HTTP/1.1 201 CREATED
Location: https://scim.example.com/search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQaM98JqxwfDg

The client then GETs that resource

GET /search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQaM98JqxwfDg HTTP/1.1
…

And the server returns the results:

HTTP/1.1 200 OK
Content-type: application/json
…

[
  { object1 },
  { object2 },
  { object3 }
]

Servers could automatically delete the search after some period, or
clients could clean up after themselves:

DELETE /search/D9uRkgJhQ04tPhAmYlvMGcHtD4DRWqkQaM98JqxwfDg HTTP/1.1
…

It's up to the server implementation to decide whether the result set
is created when the search is created or when it is retrieved.

  Scotty