This is a follow up to this thread from a few weeks ago:
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg40287.html
I've updated the nova spec in this area to include the total server count
in the server_links based on the existence of an include_count query
parameter (eg: GET
Thanks, Steven, much appreciated! :)
On 12/16/2014 01:26 PM, Steven Kaufer wrote:
This is a follow up to this thread from a few weeks ago:
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg40287.html
I've updated the nova spec in this area to include the total server
count in
detail=concise is not a media type and looking at the grammar in the RFC it
wouldn’t be valid.
I think the grammar would allow for application/json; detail=concise. See
the last line in the definition of the media-range nonterminal in the
grammar (copied below for convenience):
Accept
On 12/01/2014 05:36 AM, Eoghan Glynn wrote:
detail=concise is not a media type and looking at the grammar in the RFC it
wouldn’t be valid.
I think the grammar would allow for application/json; detail=concise. See
the last line in the definition of the media-range nonterminal in the
On Nov 20, 2014, at 4:06 PM, Eoghan Glynn
egl...@redhat.commailto:egl...@redhat.com wrote:
How about allowing the caller to specify what level of detail
they require via the Accept header?
▶ GET /prefix/resource_name
Accept: application/json; detail=concise
The Accept request-header field can
detail=concise is not a media type and looking at the grammar in the RFC it
wouldn’t be valid.
I think the grammar would allow for application/json; detail=concise. See the
last line in the definition of the media-range nonterminal in the grammar
(copied below for convenience):
Accept
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working group. Your
On 11/20/2014 08:47 AM, Salvatore Orlando wrote:
Aloha guardians of the API!
LOL :)
I haven recently* reviewed a spec for neutron [1] proposing a distinct
URI for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic
is general
On 11/20/2014 09:12 AM, Jay Pipes wrote:
On 11/20/2014 08:47 AM, Salvatore Orlando wrote:
Aloha guardians of the API!
LOL :)
I haven recently* reviewed a spec for neutron [1] proposing a distinct
URI for returning resource count on list operations.
This proposal is for selected neutron
On Thu, 20 Nov 2014 14:47:16 +0100
Salvatore Orlando sorla...@nicira.com wrote:
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a
distinct URI for returning resource count on list operations.
This proposal is for selected neutron resources, but I
The Nova proposal appears to be identical to neutron's, at least from a
consumer perspective.
If I were to pick a winner, I'd follow Sean's advice regarding the 'more'
attribute in responses, and put the total number of resources there; I
would also take Jay's advice of including the total only
The only thing I want to caution against is making a SQL-specific choice. In
the case of some other backends, it may not be possible (for an extremely large
dataset) to get a full count, where SQL does this fairly elegantly. For
example, LDAP (in some cases) may have an administrative limit
On Thu, 2014-11-20 at 08:28 -0800, Morgan Fainberg wrote:
The only thing I want to caution against is making a SQL-specific
choice. In the case of some other backends, it may not be possible
(for an extremely large dataset) to get a full count, where SQL does
this fairly elegantly. For
I'm looking at the Nova spec, and it seems very taylored to a specific
GUI. I'm also not sure that 17128 errors is more useful than 500+ errors
when presenting to the user (the following in my twitter stream made me
think about that this morning -
@lists.openstack.org
Date: 11/20/2014 10:57 AM
Subject: Re: [openstack-dev] [api] Counting resources
I'm looking at the Nova spec, and it seems very taylored to a specific
GUI. I'm also not sure that 17128 errors is more useful than 500+ errors
when presenting to the user (the following in my
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working
My primary concern (and use of the numbers) was to make sure it isn’t expected
on all “list” operations, as (albeit specifically for Keystone) some of the
projects + backends can’t really support it. If we really are tied to SQL-isms
(which is a fine approach) we can make these consistent where
17 matches
Mail list logo
