I don't like duplicating routes either but I thought it would ease the
transition rather than just changing the route. So no code duplication,
just 2 routes that go to the same place:
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
$r->get("/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
And then we circle back and delete
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
at some point.
And yes, this internal namespace was introduced for comcast-specific
reasons that I believe no longer exist.
Jeremy
On Wed, Mar 15, 2017 at 2:13 PM, David Neuman <[email protected]>
wrote:
> At least a few of those (Steering, federations) were put in the "internal"
> namespace to work around Comcast specific issues. I don't know that I like
> the idea of duplicating routes, if anything we should see what is impacted
> by moving them out of the internal namespace.
>
> On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell <[email protected]>
> wrote:
>
> > Currently, we have a number of API routes scoped as "internal". Here are
> a
> > few examples:
> >
> > https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> >
> > I believe this is going to make it more difficult as we try to implement
> > more granular roles / capabilities coupled with tenancy.
> >
> > So I'm proposing that we create a duplicate non-internal route like this,
> > for example:
> >
> > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > 'Steering#index', namespace => 'API::DeliveryService' );
> >
> > that way we can slowly move away from the "internal" routes and
> eventually
> > deprecate them.
> >
> > I think with our upcoming more robust role / tenancy model, there is no
> > longer a need for "internal".
> >
> > Thoughts?
> >
> > Jeremy
> >
>
