I'm not 100% familiar with how the API gateway will work but I always
assumed that it was a microservice that handled everything /api/*. For
example, if you made a request to traffic-ops.domain.com/foo.jpg, the api
gateway would not kick in....but if you made a request to
traffic-ops.domain.com/api/whatever, the api gateway would kick in and do
it's thing (check roles, capabilities, token, etc).
If that is true, it seems like we need to get these "internal" routes under
the api namespace.
We have 8 "internal" routes:
4 authenticated (you have to be logged in) steering routes that are locked
down by role (admin or steering):
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
$r->get("/internal/api/$version/steering/:xml_id")->over( authenticated =>
1 )->to( 'Steering#index', namespace => 'API::DeliveryService' );
$r->post("/internal/api/$version/steering")->over( authenticated => 1
)->to( 'Steering#add', namespace => 'API::DeliveryService' );
$r->put("/internal/api/$version/steering/:xml_id")->over( authenticated =>
1 )->to( 'Steering#update', namespace => 'API::DeliveryService' );
1 authenticated federation route locked down by role (admin):
$r->get("/internal/api/$version/federations")->over( authenticated => 1
)->to( 'Federation#index', namespace => $namespace );
^^ imo those are all authenticated and locked down by role so there should
be no harm losing the "internal". (as long as any place is the code base
that uses these routes are adjusted)
1 unauthenticated (you don't have to be logged in) dnsseckeys route:
$r->get("/internal/api/$version/cdns/dnsseckeys/refresh")->to(
'Cdn#dnssec_keys_refresh', namespace => $namespace );
2 unauthenticated traffic stats routes:
$r->get("internal/api/$version/daily_summary")->to(
'CacheStats#daily_summary', namespace => $namespace );
$r->get("internal/api/$version/current_stats")->to(
'CacheStats#current_stats', namespace => $namespace );
At the very least, the first 5 routes should be "fixed" imo. Not sure what
to do about the other 3.
Jeremy
On Fri, Mar 17, 2017 at 5:40 AM, Amir Yeshurun <[email protected]> wrote:
> With the API GW, such duplications, or modifications can be defined in the
> GW, if required, instead of in TO
>
> On Thu, Mar 16, 2017, 5:52 PM Jan van Doorn <[email protected]> wrote:
>
> > We should also think about the API gateway future.... I think with that,
> we
> > don't need these special routes at all anymore, right Amir?
> >
> > Cheers,
> > JvD
> >
> >
> > On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <[email protected]>
> > wrote:
> >
> > > I think we should do as Dave mentioned, assess and rename.
> > >
> > > > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <[email protected]>
> > > wrote:
> > > >
> > > > 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
> > > > 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
> > > > > 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
> > > > > >
> > > > >
> >
>
