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