I agree it may be odd, but is that a strong argument? To me, following RESTful style/constructs is the main thing to consider. If people can specify everything in the parent resource then let them (i.e. single call). If they want to specify at a more granular level then let them do that too (i.e. multiple calls). At the end of the day the API user can choose the style they want.
Cheers, --Jorge From: Youcef Laribi <youcef.lar...@citrix.com<mailto:youcef.lar...@citrix.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, April 30, 2014 1:35 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS Sam, I think it’s important to keep the Neutron API style consistent. It would be odd if LBaaS uses a different style than the rest of the Neutron APIs. Youcef From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Wednesday, April 30, 2014 10:59 AM To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS Hi Everyone, During the last few days I have looked into the different LBaaS API proposals. I have also looked on the API style used in Neutron. I wanted to see how Neutron APIs addressed “tree” like object models. Follows my observation: 1. Security groups - http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html) – a. security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html> are children of security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html>, the capability to create a security group with its children in a single call is not possible. b. The capability to create security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html> using the following URI path v2.0/security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html>/{SG-ID}/security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html> is not supported c. The capability to update security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html> using the following URI path v2.0/security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html>/{SG-ID}/security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>/{SGR-ID} is not supported d. The notion of creating security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html> (child object) without providing the parent {SG-ID} is not supported 2. Firewall as a service - http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html - the API to manage firewall_policy and firewall_rule which have parent child relationships behaves the same way as Security groups 3. Group Policy – this is work in progress - https://wiki.openstack.org/wiki/Neutron/GroupPolicy - If I understand correctly, this API has a complex object model while the API adheres to the way other neutron APIs are done (ex: flat model, granular api, etc.) How critical is it to preserve a consistent API style for LBaaS? Should this be a consideration when evaluating API proposals? Regards, -Sam.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
