Just finished a GO-SDK(1.6) for our API, looking for feedback.

<p>Hey everybody, we&#39;ve been working on a <a href="https://github.com/bandwidthcom/go-bandwidth" rel="nofollow">Go SDK</a> recently for our <a href="http://ap.bandwidth.com/?utm_medium=social&amp;utm_source=reddit&amp;utm_campaign=dtolb&amp;utm_content=_" rel="nofollow">API</a> , TelCo API: sending SMS, making phone calls, etc..)</p> <p>It&#39;s not 100% complete yet, but I&#39;d like to get feedback from you all before the official release:</p> <p><a href="https://github.com/bandwidthcom/go-bandwidth" rel="nofollow">Bandwidth Go SDK</a></p> <p>If you need/want an account to test, just PM me with your email (after signing up) and I&#39;ll hook you up with a few dollars to play around. We&#39;re still in limited signups, so I will have to approve your account.</p> <p>Thanks everybody :)</p> <hr/>**评论：**<br/><br/>oefig: <pre><p>I didn&#39;t get a chance to dive see into it but from my first impression I&#39;m a bit wary of every response being returned <code>map[string]interface{}</code>. Usually they&#39;re marshaled into a struct like so an end user (like me) can use the data with type safety.</p></pre>skarlso: <pre><p>Like <a href="/u/oefig" rel="nofollow">/u/oefig</a> said, retuning a map of interface types is really bad. </p> <p>Also your switch case on interface type shows me that you aren&#39;t using types the way they should be. I&#39;m talking about this bit:</p> <pre><code> switch body.(type) { case []interface{}: </code></pre> <p>Re-think your types and abstractions and re-write accordingly. Tight now you are converting needlessly in a lot of places and because of that it&#39;s hard to follow what you are actually trying to do. </p></pre>sethammons: <pre><p>I did not look too deep. One first thought is that by reading the readme, I&#39;m not sure what to really expect from the package or your service nor how to use it. Second thought, being that you have client code, I&#39;d expect some (all?) tests to be using <code>package bandwidth_test</code>. This package can exist in the current namespace, but prevents your test from accessing non-exported methods. This will also give people a better understanding of how to use the package. And I agree with <a href="/u/eofig" rel="nofollow">/u/eofig</a>, have exported structs that we can use and avoid <code>map[string]interface{}</code>.</p></pre>luckyleprechaun98: <pre><p>Take a look at the Stripe Go SDK for examples of how you can export your API responses as a struct. For example, look at card.go and you&#39;ll see they have a struct with types for each field and they use tags to define how it marshals/unmarshals to json. That&#39;s how you want to build your API.</p> <p><a href="https://github.com/stripe/stripe-go" rel="nofollow">https://github.com/stripe/stripe-go</a></p></pre>