Presently PR 3585 doesn't leverage that particular endpoint. However, I'd lean towards resisting the temptation during the perl -> go rewrites to change how things work as much as possible; even if it's wrong. That way if something goes wrong unexpectedly, it's easier to determine which was the cause. That's not to say we shouldn't fix it, just that it's separate with all the discussions that go with that change in behavior.
Jonathan G On 10/21/19, 12:16 PM, "ocket 8888" <[email protected]> wrote: I've been rewriting the PUT method handler for the /user/current endpoint (PR open: https://github.com/apache/trafficcontrol/pull/3996) and I wanted to make some changes to it that would break the "API version promise". Currently, in Perl, the way the endpoint works is more like a PATCH than a PUT. It only updates the fields sent in the request. That makes it not idempotent and PUT is supposed to be idempotent. So, would it be alright to require that all fields (except localPasswd and confirmLocalPasswd as special cases, since you don't want to send cleartext passwords if its not absolutely necessary) be defined explicitly? If it's implemented the way endpoints sometimes are where missing fields are implicitly `null`, then clients used to the old Perl API will accidentally set things to `NULL` that they don't mean to. If we want to keep PUT idempotent, then we either break clients like that, or we break the API (which also breaks clients, but in a safer way by rejecting problematic requests).
