>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...
Well, if someone is using a TC data field for something outside TC, I don't know that we promise to keep the data posted exactly as it was posted, and return it exactly the same. For example, if you POST "httplivenatnl" and we accept it, and you GET the data you just posted, you're going to get "HTTP_LIVE_NATNL". Along those same lines, I'd argue that because TC doesn't use `gid` or `uid` anymore, we're allowed to "manipulate" the data posted, and return only the data relevant to TC, namely `null`. It's certainly a grey area, and there's an argument we should preserve the posted value, especially if it breaks someone in practice. But that's my vote. On Fri, Sep 14, 2018 at 2:50 PM Moltzau, Matthew < [email protected]> wrote: > PUT api/*/users/:id > Doesn't actually exist in v13 (which is perl for this particular endpoint) > > On 9/14/18, 2:46 PM, "Jeremy Mitchell" <[email protected]> wrote: > > 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. > > > > > > > > > > > > > > > > > > > > > >
