Client, Request, Response

[at15]

We need to design a standard struct/interface for client, request, response to use across all the operations, schema changes, updating documents etc. It is possible we do the converting directly and user don't need to call json.Unmarshal directly

TODO

• checkResponse does not work for certain APIs because
  • they don't use status code to indicate error
  • 404 returns html page
  • schema management has its own error response format

Ref

• net/http
• google cloud client https://github.com/GoogleCloudPlatform/google-cloud-go
• github client https://github.com/google/go-github
  • when using json.Decoder extra call is needed to drain the body and reuse connection Drain Response.Body to enable TCP/TLS connection reuse (4x speedup) google/go-github#317 (does it still needed for newer golang version?)
• docker client https://github.com/moby/moby/tree/master/client
• elastic https://github.com/olivere/elastic
• https://github.com/kubernetes/client-go
• gocql https://github.com/gocql/gocql

[at15]

there is one problem of how to organize the files, we can put all the files under one package

schema_core.go
schema_filed.go
admin_info.go
client.go

or use multiple packages

schema
   - core.go
   - field.go
admin
   - info.go
client.go

The main problem of using multiple packages is there is import cycle for client, one way to solve it to have a service wrapper different packages, so the user is calling the service instead of the client package directly

[dio]

I'm interested in google/go-github#317 as one of the listed items. As the merged patch is: https://github.com/google/go-github/blob/master/github/github.go#L482-L486 do you think this is still required for a client in newer current golang version?

[at15]

@dio based on comments in the original issue, it seems net/http has already fixed that in https://go-review.googlesource.com/c/go/+/21291.

There are some similar issues go-kit/kit#249 which leads to golang/go#15703 then leads to https://go-review.googlesource.com/c/go/+/23200

This verifies that the client's bufio reading reads ahead and notes the EOF, so even if the JSON
decoder doesn't read the EOF itself, as long as somebody sees it, a close won't forcible tear down the connection. This was true at least of https://golang.org/cl/21291

so I believe it is not needed in latest version, but I haven't run any experiment.