Yeah, like Rob said, have to keep those fields because they are part of the 1.x contract even though they are null...which does seem kinda silly but api versioning is a promise...
i would be curious if PUT api/*/users/:id PUT api/*/user/current really allows you to change them and if it does even more of a reason to keep them because maybe somebody is setting those id's for some reason... TO API 2.x we nix those imo (unless somebody is really using those fields) jeremy On Fri, Sep 14, 2018 at 2:41 PM Robert Butts <[email protected]> wrote: > -1 on removing them from the API, they're part of API 1.x, we can't remove > them without breaking Semantic Versioning. > > +1 on removing from the db, hard-coding the API to return nulls, and > documenting them as deprecated in the API. The db has no "version promise", > we can definitely clean that up. > > > On Fri, Sep 14, 2018 at 2:41 PM Moltzau, Matthew < > [email protected]> wrote: > > > Yes, this might also affect PUT for /api/*/user/current. > > At least the documentation says that the gid and uid may be altered, > > though I don't currently know if that's actually the case. > > > > On 9/14/18, 2:37 PM, "Jeremy Mitchell" <[email protected]> wrote: > > > > Which endpoints are you talking about specifically? > > > > GET /api/*/users > > GET /api/*/users/:id > > GET /api/*/user/current > > > > ^^ these ones? > > > > Jeremy > > > > On Fri, Sep 14, 2018 at 2:32 PM Moltzau, Matthew < > > [email protected]> wrote: > > > > > Can I get a +1 to remove gid and uid from the user response in > > golang? > > > They aren’t being used at all and are only ever set to null. > > > > > > > > > > > > >
