Open Stack

Interesting idea, and in general I'm for consistency. I can't speak
directly to the network/port question, though it seems to me that if ports
must be attached to networks then it makes sense for the URL to reflect
that.

On the other hand, some could argue that the django URL routing is ...
legacy ... and shouldn't me messed with :)

On the gripping hand, thinking about this could inform future angular
routing planning...

On 2 September 2015 at 00:39, Rob Cresswell (rcresswe) <rcresswe at cisco.com>
wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/505e1e01/attachment.html>