Alright, I think this has been open long enough for everyone with an
opinion to weigh in.

I don't have a counter-argument to "change as little as possible in
rewrites to ensure accuracy and smooth transitions" that doesn't just boil
down to whining about API versions being a thing. So I'll implement the PUT
handler  as though it were PATCH to remain true to the Perl handler's
behavior.

On Mon, Oct 21, 2019 at 1:11 PM Gray, Jonathan <[email protected]>
wrote:

> 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).
>
>
>

Reply via email to