We apparently use it for a tool that gets server info for every host, but it seems to only care about fields that also exist in /servers. FWIW, /servers/details also seems to provide the list of delivery service IDs assigned to the given server, but those are largely deprecated by topologies anyways and don't reflect all the delivery services that would actually be served by that particular server. It might also be in use in Ansible playbooks, but I suspect those playbooks could also just use /servers instead.
- Rawlin On Wed, Apr 27, 2022 at 11:04 AM ocket 8888 <[email protected]> wrote: > > What for? Is there some information it gives you that /servers doesn't? > > On Wed, Apr 27, 2022 at 10:51 AM Jeremy Mitchell <[email protected]> > wrote: > > > > looks like we use it a bunch at comcast still > > > > On Tue, Apr 26, 2022 at 5:50 PM ocket 8888 <[email protected]> wrote: > > > > > Well it needs to be deprecated first, but as of right now it could be > > > deprecated in 3.x and removed in 4.x > > > > > > On Tue, Apr 26, 2022, 15:54 Jeremy Mitchell <[email protected]> wrote: > > > > > > > does it first need to be deprecated before being removed? i.e. > > > > deprecated > > > > in 4.x and removed in 5.x > > > > > > > > On Tue, Apr 26, 2022 at 1:15 PM ocket 8888 <[email protected]> wrote: > > > > > > > > > AFAIK the only difference between this and /servers is that > > > > > /servers/details is missing some things (e.g. routerPortName) that > > > > > exist on /servers servers, but they have this "hwinfo" property. Even > > > > > in APIv1 /hwinfo was read-only and now that endpoint no longer exists > > > > > (removed in v2). "Hwinfo" as a concept has sort of passed into > > > > > obscurity as new servers can't have it as of at least a little more > > > > > than a year ago. > > > > > > > > > > Remembering to update an unused endpoint is difficult, and actually > > > > > doing so is annoying. As a result, the object definitions between > > > > > /servers and /servers/details have drifted to the point that I'm not > > > > > sure how the latter could possibly be useful anymore. Which will > > > > > likely continue unless we just get rid of it. > > > > > > > > > > > >
