Why the change? It’s my understanding that path parameters should be used to
specify a particular resource
and query parameters should be used to sort/filter the query. Why use a query
parameter to specify a particular
resource? Is this REST API best practice?
What about sub resource queries
Due to this change, the Traffic Ops APIs may also need change:
(GET/POST/PUT/DELETE) /api/1.2/servers/{:svrId}/2ndintfs
Need change
Suggestion: /api/1.2/servers/{:svrId}/interfaces
(GET/POST/PUT/DELETE) /api/1.2/servers/{:svrId}/2ndips
Don't need change.
Thanks,
Jifeng
On 04/04/2
Ah, sorry, I misunderstood. I thought when you said "a route that never
existed in 1.2 before" you meant e.g. /api/1.3/servers "didn't exist in
Golang or 1.3 before".
Right, for entirely new routes, e.g. deliveryservices/{xmlID}/urisignkeys,
path params are fine, and still conform to SemVer for th
You're right, in our code today, we don't use raw major versions
(/api/1/foo) in our API, and our clients have hard-coded minor versions.
If we feel like that's how we want to design APIs and clients, and say "our
minor versions are not compatible with each-other", we can do that. But
it's not Sem
" a request from a client which is built to understand say /api/1.2/, if
that same request is made to /api/1.3/, it should still work."
But this is a route that never existed in 1.2 before, not a new version of a
route in 1.3,
a client built to understand 1.2 will just not have this route at
Can you clarify what a "howto" is?
Yes, it looks like our README's are a bit out of control. What if we
consolidated them like such:
./README.md <-- this one links to general information about TC
(readthedocs) and also links to the following:
./traffic_portal/README.md
./traffic_monitor/README.m
>Technically, adding new routes does not break old stuff right so i don't
think that warrants a major version roll.
New routes that use query params instead of path params will definitely
break old stuff.
When you say "break old stuff", the idea behind Semantic Versioning, is
that a request from
tbh i'm not sure about versioning. I was just trying to suggest that new
routes be formulated this way per the new API guidelines:
GET /foos[?id, name, etc=]
POST /foos
PUT /foos [?id, name, etc=]
DELETE /foos [?id, name, etc=]
instead of the old way:
GET /foos
GET /foos/:id
POST /foos
PUT /foos
That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
Just to clarify, changing to query parameters breaks compatibility with 1.2
and older, so new APIs in that format have to be a new major version, i.e.
2.0, per Semantic Versioning, right?
On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell
w
Hello All,
I've prepared a release for v2.2.0-RC4
The vote is open for at least 72 hours and passes if a majority of at least
3 +1 PPMC votes are cast.
[ ] +1 Approve the release
[ ] -1 Do not release this package because ...
Changes since 2.1.0:
https://github.com/apache/incubator-trafficcont
Eric,
Great, IP as delivery unit.
Note that I believe the port is part of this unit, and not a common
settings to all IPs in the interface.
+1 for Rob's suggestion (stats are collected on the interface level, and
health/heartbeat on the ip level)
Rob/Jeff
I believe we need to verify this entire c
I've been going through the Traffic Ops API doc's and revamping them with
Swagger and noticed this trend with our documentation. "Guides" (Howto's,
Installs, Developer's) growing because they are easier to maintain
(because they are less fancy) as markdown files in the Github project. My
concer
+1
Jeremy
On Mon, Apr 2, 2018 at 10:28 PM, Jason Tucker
wrote:
> +1
>
> On Tue, Apr 3, 2018 at 2:58 AM, John Rushford
> wrote:
>
> > +1
> >
> > > On Apr 2, 2018, at 7:07 PM, Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> > >
> > > +1
> > >> On Apr 2, 2018, at 4:11 PM, David Neuma
@nbaoping
> So I suggest the change to the current TM to be like:
> 1) Separate the current polling of cache servers into two different
pollings, one for the keep alive, the other for the stat query.
The Golang Monitor already does this. We call it the "health" and "stat"
polls in the code. The s
Hey Nir-
For our particular use case, we are looking at making an IP the delivery
unit. We would like to use a single interface with multiple IPs. DSs would be
assigned to one of the IPs on that interface. Interface (or IP) priority does
not come into play here as there is no failover between
Sounds good John.
If you can provide a path, we shouldn’t call it Error Domain :-) We should call
it “Error Redirect URL”.
—Eric
> On Apr 3, 2018, at 11:02 PM, John Shen (weifensh) wrote:
>
> Hey Eric,
>
> Thanks a lot for your comments. Please refer to my reply inline.
>
> Thanks,
> John
Hi guys,
It’s really exciting that we are moving to one flexible solution to have the IP
and interface tables separately. Based on this, I have some ideas for the
change of the Traffic Monitor(TM). Actually, the TM have two different purposes
to polling the cache servers. One is to make sure th
17 matches
Mail list logo
