I think at one point there was some effort to expose some of that with the
"rawRequest" func, not sure who created a lot of these, I have just been
using what was there for the API Tests. I think we do need to do some
refactoring to expose more for proper API Testing.
>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?
Right, if no function with the same signature exists in Release 2.1 or
older, we can change them right
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
>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
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
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
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"
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
