Open Stack

On Tue, 6 Dec 2016 15:42:18 -0500, Jay Pipes wrote:
> On 12/06/2016 03:28 PM, Ed Leafe wrote:
>> On Dec 6, 2016, at 2:16 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>
>>> I would prefer:
>>>
>>> GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
>>>
>>> to "group" the resources parameter together. When we add in trait
>>> lookups, we're going to want a way to clearly delineate between
>>> resource classes and traits other than just knowing resource classes
>>> are ALL_CAPS...
>>>
>>> GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
>>>      &required=storage:ssd,hw:cpu:x86:avx2
>>>      &preferred=virt:hyperv:gen2
>>
>> OK, that’s fine. The URI path is still just 126 characters, well below
>> the limit of around 8K. It still seems anything but scary.
>
> Oh, absolutely, I wasn't arguing about length of URI or anything.
>
> To be clear, I could either go the above route or even do a POST
> /resource_providers that returns a list of resource providers instead of
> creating a resource provider. Don't mind either way.
>
> But, we should definitely agree on which this is going to be ASAP.

Last time I was aware of the discussion, I thought that sophisticated 
queries for a list of resource providers would involve specifying a 
structured JSON payload. That is where I don't tend to think a query 
string in the URI is so usable. Are we assuming user queries will be 
relatively simple?

 From what I recall, the ideas were:

1. GET with non-JSON query string if simple, else GET with JSON body 
(which is not covered by HTTP spec)

2. GET with JSON query string to cover both simple and sophisticated queries

3. POST with JSON body to a /resource_providers/list URI to cover both 
simple and sophisticated queries

Which option are we talking about now? 1? Or a version of it where 
queries are assumed to be simple and no JSON structure at all?

-melanie