Hi All,
This is a general doubt related to taking a decision on REST API url construction.
In case of “nested urls”, lets say I have a relationship between
two entities as below:
access_group is parent can have many access_group_entries.
Now for accessing access_group I have already created
· Create access group - POST /access_groups
· Show access_group – GET /access_groups/<access-group-uuid>
· List access_group – GET /access_groups/
· Delete access_group – PUT /access_groups/<access-group-uuid>
That’s fine till here.
Now when I work on child entity that is access_group_entry, I
face a problem.
Here, i have two options for url construction for access_group_entries.
Option1 :-
Considering that access_group_entry is related to access_group, it
should be designed as a suburl, I go as below:
· Create access-group-entry -- POST '/access_groups/%s/entries' >>>> i send “access_group_id” in which entry is to be created, as part of url, okay. no issue. it works.
· Show access-group-entry -- GET '/access_groups/%s/entries/%s' >>>> need two variables from user, access_group_id and access_group_entry_id -
But I do not have access_group_id!!!!!!!!!!
as when, i say show access_group_entry <access-group-entry-uuid> - i have just uuid of access_group_entry_directly.
That's a problem. is it ? what to do in such case?
· List access-group-entry -- GET '/access_groups/%s/entries'>>> Here also its not mandatory that user will always give access_group_id.
He might ask access_group_entry list for all access_groups in a go..
hence same problem.
Option2 :-
==========================
Not creating a suburl, instead creating an independent url
RESOURCES_PATH = '/access_groups_entries'
RESOURCE_PATH = '/access_groups_entries/%s'
1)Create POST '/access_groups_entries' >>>>>> Passing access_group_id in body
2)Show GET '/access_groups_entries/%s' >>>> directly access_group_entry_id here to be shown
3)List GET '/access_groups/%s/entries'>>>> directly access_group_entry_id here to be shown.
If access_group_id is given for filtering, will go as part of body.
It solves above problem but it creates a new url for a resource
which is child of a earlier created url.
Is that a problem?
Kindly suggest
Thanks.
Nidhi
From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, March 09, 2016 10:32 AM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: RE: [openstack-dev] [OpenStack-Dev][All] Api development question
Thank you Valeriy.
From: Valeriy Ponomaryov [mailto:vponomaryov at mirantis.com]
Sent: Tuesday, March 08, 2016 7:05 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [OpenStack-Dev][All] Api development question
"Not found" means API you request is not registered. AFAICS, you register "access_groups", but request "access-groups". Diff in symbols "_" and "-".
On Tue, Mar 8, 2016 at 1:34 PM, <nidhi.hada at wipro.com<mailto:nidhi.hada at wipro.com>> wrote:
Hi all,
I am working on a feature for share access in manila.
For that lets say for creating the entity, I created client and server
counterpart.
I am stuck as my client request is not able to reach server resource
I have created for it. This is client server log
http://paste.openstack.org/show/489642/
manila/api/v2/router.py
This is my router entry
from manila.api.v2 import access_groups
.
.
self.resources["access_groups"] = access_groups.create_resource()
mapper.resource("access_group", "access_groups",
controller=self.resources["access_groups"],
collection={"detail": "GET"},
member={"defaults": "GET"})
I don’t understand what mistake I have made that the request
Is not getting mapped to correct resource.
stack at controller:/opt/stack/manila/manila/api/v2$ ls access_groups.py
access_groups.py
stack at controller:/opt/stack/manila/manila/api/v2$
This is access_groups.py snippet
http://paste.openstack.org/show/489667/
Can someone please help in pointing, what can be probable reason of this ?
I have checked the flow from client to server, not able to catch the mistake..
Regards
Nidhi Mittal Hada
Architect | PES / COE – Kolkata India
Wipro Limited
M +91 74 3910 9883<tel:%2B91%2074%203910%209883> | O +91 33 3095 4767<tel:%2B91%2033%203095%204767> | VOIP +91 33 3095 4767<tel:%2B91%2033%203095%204767>
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com<http://www.wipro.com>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com<http://www.mirantis.com>
vponomaryov at mirantis.com<mailto:vponomaryov at mirantis.com>
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/d2c86005/attachment.html>