Ok, I wasn't sure if this was done intentionally as part of some framework planning or not. It would seem that most if not all of the files in the client/v13 directory came after 2.2.0-RC1, and assuming that's true, do we really have an obligation to follow the deprecation process for unreleased code?
I might be wrong about the age of some of those files, but I know at least a handful of them were added after 2.2.0-RC1 for sure. - Rawlin On Thu, Apr 26, 2018 at 12:27 PM, Robert Butts <[email protected]> wrote: >>client methods take the Foo struct as input rather than the FooNullable > struct, so it's impossible to create a request with null fields > > It's a legacy artifact. You're right, it's a serious limitation, it's just > never been a priority to fix. > > The client is a public interface to the API, we can't just change it and > break people. I propose we add new functions, e.g. `CreateTenantNullable`, > and mark the existing functions as deprecated, and remove them in the next > major version. > > > On Thu, Apr 26, 2018 at 12:02 PM, Rawlin Peters <[email protected]> > wrote: > >> Digging a little further into this, it looks like in the older client >> we actually did decode the json response from PUT/POST requests and >> return it, as evidenced by this CreateTenant method signature: >> >> func (to *Session) CreateTenant(t *tc.Tenant) (*tc.TenantResponse, error) { >> >> Now I'm really confused as to why we've deviated from this behavior in >> the 1.3 client so far. >> >> Another issue is that the client methods take the Foo struct as input >> rather than the FooNullable struct, so it's impossible to create a >> request with null fields where applicable. Does anyone know of a good >> reason why we're implementing the new client like this? >> >> - Rawlin >> >> On Thu, Apr 26, 2018 at 11:11 AM, Rawlin Peters <[email protected]> >> wrote: >> > If you've found some Perl endpoints that aren't returning the modified >> > record, I think that's definitely a bug, and there should be GitHub >> > issues filed to fix them (unless they're already fixed in the Go >> > implementation). The API should always return the modified resource, >> > and the client should have immediate access to the modified resource >> > without needing a subsequent GET after every PUT/POST. >> > >> > At least for some new Go endpoints I'm working on, I'm going to make >> > the client decode the json responses, but I think we should definitely >> > consider making that the standard with our API clients. >> > >> > -Rawlin >> > >> > On Wed, Apr 25, 2018 at 7:14 PM, Schmidt, Andrew (Contractor) >> > <[email protected]> wrote: >> >> I've noticed that the Put/Post responses are incorrect from some of the >> Perl endpoints. I'm guessing maybe that is the reason. For example the Put >> response returns the unmodified record. You have to do a Get to verify that >> the change occurred. >> >> >> >> Andy >> >> >> >> On 4/25/18, 3:53 PM, "Rawlin Peters" <[email protected]> wrote: >> >> >> >> Hey folks, >> >> >> >> I noticed in our TO go client that we aren't decoding the JSON >> >> response returned from PUT/POST endpoints. If we actually decoded >> >> those responses, it would be quicker and more useful from a user's >> >> perspective, save bandwidth from all the unnecessary GETs after >> >> POST/PUTs, and also reduce load on the API server. >> >> >> >> Is there a reason why we don't decode those responses? >> >> >> >> - Rawlin >> >> >> >> >> >> >>
