On Tue, Apr 23, 2019 at 1:04 PM Gray, Jonathan <jonathan_g...@comcast.com> wrote: > > As a developer it sounds just as messy as the other solutions, but it may be > workable. If you internally are chaining the object mashalling and db > queries, how do you handle new mandatory fields that have no default? I > still prefer converting to PATCH instead of POST moving forward. > > Jonathan G
New mandatory fields with no default would not fall under the minor versioning strategy. Those would be breaking changes which would require a new major version. The new API endpoint under the next major version would essentially be a new unique struct and handler, implemented in such a way that it has no dependency on the previous major version. If we can't cleanly remove handlers and associated code for the previous major version (after a deprecation period) without affecting the new major version, then we've done something wrong. I think this solution would greatly organize the code. Part of the problem with the current implementation is that there is too much duplicated code between all of the different minor versions, and there is no clear boundary between what's expected of each minor version. For example, the delivery services API currently has multiple of the same functions attached to each minor-version struct, with the only real difference between each minor version being the struct itself for marshalling/unmarshalling purposes. The code already kind of "upgrades" requests (e.g. 1.1 to 1.5) to be handled by one "main" handler, except it's losing the 1.5 data that might already exist for that object by setting the 1.5 fields to their defaults. My proposal here would fix that data loss problem by reading the 1.5 fields into the struct _first_, before passing it up to the "real" handler to process the request as if it had been made at the latest minor version. What we would end up with would be super simple handlers for each previous minor version, with the latest minor version handler doing all of the legwork. The previous minor version PUT handlers might take a small hit in performance due to the need to read the newer fields from the DB (for the "upgrade" step), but as Traffic Control is primarily a read-heavy system, I think we could manage the small hit in latency. If the small increase in latency becomes a problem for you as a client of a previous minor version, all you have to do is upgrade your code to the latest minor version (which for the Go client should just be a recompile). - Rawlin
