[openstack-dev] Modelling the creation of multiple networks in Nova's REST API
Mark McLoughlin
markmc at redhat.com
Wed Aug 15 08:58:10 UTC 2012
On Wed, 2012-08-15 at 12:55 +0400, Oleg Gelbukh wrote:
> Hello,
>
>
> It seems to me that this call just mimics the behavior of nova-manage
> utility which allows to create multiple networks for single
> project/tenant with single CLI command.
Yes, but that doesn't mean it's a sane REST API.
Cheers,
Mark.
> --
> Best regards,
> Oleg
>
> On Wed, Aug 15, 2012 at 12:22 PM, Mark McLoughlin <markmc at redhat.com>
> wrote:
> On Thu, 2012-07-19 at 14:20 +0100, Mark McLoughlin wrote:
> > Hi,
> >
> > I was just reviewing the code for this:
> >
> >
> https://blueprints.launchpad.net/nova/+spec/os-api-network-create
> >
> > You POST to /networks:
> >
> > {"network": {"vlan_start": 234, "cidr": "10.70.105.0/24",
> "label": "net234"}}
> >
> > and get back e.g.
> >
> > {"networks": [{..., "id":
> 66085e78-8f6-4a26-b16c-4b1f55901fbd", ..., "label":
> "net234", ..., "vlan": 234, ..., "cidr":
> "10.70.105.0/24", ...}]}
> >
> > Notice the plural "networks" in the response. A single POST
> may create
> > multiple networks (where e.g. FLAGS.num_networks > 1), but
> it's not
> > clear to me what the use case for this is.
> >
> > The issue with this is that (at least IMHO) POST requests
> should only
> > create a single resource - e.g. we want to be able to return
> a 201
> > Created response with a Location header and it would seem
> bizarre to
> > include multiple location headers.
>
>
> For anyone interested, this debate is still rumbling on here:
>
> https://review.openstack.org/#/c/9847/
>
> I've tried to be pretty clear about my objection to the
> proposed
> modelling:
>
> REST stands for Representational State Transfer
>
> When you POST to /networks, you are sending a representation
> of the
> network resource you want to create
>
> The sensible thing for a client to expect is that a network
> resource
> will be created and for a 201 Created response to include a
> representation the resource and a Location header with a URI
> for the
> resource
>
> What doesn't seem at all sensible is for the server to
> return a
> collection of resources, based on "num_networks" and
> "network_size"
> properties in the network representation and also based on
> the server
> configuration
>
> Other opinions are most welcome, though.
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
More information about the OpenStack-dev
mailing list