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