[openstack-dev] [horizon] URL Sanity

Rob Cresswell (rcresswe) rcresswe at cisco.com
Tue Sep 1 14:39:03 UTC 2015


Hi all,

I recently started looking into properly implementing breadcrumbs to make navigation clearer, especially around nested resources (Subnets Detail page, for example). The idea is to use the request.path to form a logical breadcrumb that isn’t dependent on browser history ( https://review.openstack.org/#/c/129985/3/horizon/browsers/breadcrumb.py ). Unfortunately, this breaks down quite quickly because we use odd patterns like `<resources>/<resource_id>/detail`, and `<resources>/<resource_id>` doesn’t exist.

This made me realise how much of an inconsistent mess the URL patterns are.  I’ve started cleaning them up, so we move from these patterns:

`/admin/networks/<network_id>/detail` - Detail page for a Network
`/admin/networks/<network_id>/addsubnet` - Create page for a Subnet

To patterns in line with usual CRUD usages, such as:

`/admin/networks/<network_id>` - Detail page for a Network
`/admin/networks/<network_id>/subnets/create` - Create page for a Subnet

This is mostly trivial, just removing extraneous words and adding consistency, with end goal being every panel following patterns like:

`/<resources>` - Index page
`/<resources>/<resource_id>` - Detail page for a single resource
`/<resources>/create` - Create new resource
`/<resources>/<resource_id>/update` - Update a resource

This gets a little complex around nested items. Should a Port for example, which has a unique ID, be reachable in Horizon by just its ID? Ports must always be attached to a network as I understand it. There are multiple ways to express this:

`/networks/ports/<port_id>` - Current implementation
`/networks/<network_id>/ports/<port_id>` - My preferred structure
`/ports/<port_id>` - Another option

Does anyone have any opinions on how to handle this structuring, or if it’s even necessary?

Regards,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150901/226b1345/attachment.html>


More information about the OpenStack-dev mailing list