Open Stack

On 05/08/2013 02:59 PM, Gabriel Hurley wrote:
>> -----Original Message-----
>> From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
>> Sent: Tuesday, May 07, 2013 3:44 PM
>
>> It is relatively easy to include the info at servers/<uuid> however:
>> {
>>   "features": ["OS-EXT-SRV-ATTR", "os-start-stop"],
>>   "server": {
>>     "OS-EXT-SRV-ATTR:host": "1169a68456af48238da47b1d5957a714",
>>     "OS-EXT-SRV-ATTR:hypervisor_hostname": "fake-mini",
>>     "OS-EXT-SRV-ATTR:instance_name": "instance-00000001",
>>     "links": [
>>       {"rel": "self",
>>        "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
>> 008cfa10b980"},
>>       {"rel": "start",
>>        "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
>> 008cfa10b980/start"
>>        "feature": "os-start-stop"},
>>       {"rel": "stop",
>>        "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
>> 008cfa10b980/stop"
>>        "feature": "os-start-stop"}.
>>     ]
>>    }
>> }
>
> Tht perfectly illustrates my biggest concern with doing this on a per-resource basis. The list of "links" gets unconscionably enormous. If I do a "list" call and retrieve 100 instances each with 100 links because you have 20 extensions the whole thing becomes a mess. I think it's much more sane (though less explicit) to understand what's provided by the service and extrapolate that to the individual resources therein.
>
> As Vish said though, that's the Horizon-esque use case. We deal with the problems of lists of things all the time. It doesn't matter so much for one CLI call, but when you've got dozens or hundreds of simultaneous users, and you have to load all that data every time they change pages... that network traffic adds up fast.

Do you have numbers on that network load? I get that as a human looking 
at things they look big, but these aren't designed to be consumed as a 
human, and this feels a bit like early optimization. If network is 
really the issue would applying gzip encoding on requests remove it, 
this is text and the replication should compress really nicely.

There is value in these being properly hypermedia so that clients don't 
need to specially understand our json to crawl through our resource 
tree. That's what made HTML really powerful, and something that REST + 
JSON is still struggling with, as links aren't really a first class idea 
in JSON.

If the list of links really remains an issue in the long run, my 
instinct would be to provide a parameter or header that says "don't give 
me the links, I'm good", which is off by default. So initial client 
discovery gets everything, but we can have a fast path for clients that 
want to take our logic into the client side.

	-Sean

-- 
Sean Dague
http://dague.net