this set of null does not help readability, shall this implement functional-options pattern

Originally posted by @pegerto in #42

While mocking up data I discovered a compatibility issue. When a network interface is connected to a NAT network, it has a NAT address which we represent like this:

"nat_addresses": {
  "network_nat_addresses": [
  {
    "ip_address": "10.0.4.1",
    "network_id": 10846630,
    "network_name": "Default Network",
    "network_url": "https://cloud.skytap.com/configurations/18714628/networks/10846630",
    "configuration_id": 18714628,
    "configuration_name": "My Environment",
    "configuration_url": "https://cloud.skytap.com/configurations/18714628",
    "viewable": true
  }
],

The network_id in this data structure is an integer. This is an inconsistency in the REST API -- the network_id of the interface itself is a string. The NetworkNatAddress struct needs to accept an integer when parsing JSON.

should these methods not be part of the environment and not the request, you verify the status, of the instance not the request it self.

Originally posted by @pegerto in #42

This fork uses "github.com/Sirupsen/logrus" and everything else uses "github.com/sirupsen/logrus".

To make the project more compatible with the terraform provider.

see api/api.go and api/requests.go in the original SDK for context.

Originally posted by @jchenry in #5 (comment)

I don't see how to compare response will assert that routable is False? I can find any assert latter?

Originally posted by @pegerto in #49

"should not put this in a string to compare the structs"

Probably wrap the client in top of a library as go-retriable Instead of self implement the logic, it will provide exponential backoff and jitter.

I will probably not differentiate the request by verb in do an let the implementation of the check Resource to take that decision.

Originally posted by @pegerto in #42

To be trackable the latest stable state of the SDK needs to be released. This can simply be a git tag.

In order to allow our API to track calls coming from different clients through the SDK, we need to accept the incoming User-Agent string from SDK clients (eg. terraform), and append it to the outgoing User-Agent string to Skytap APIs.

Terraform client's User-Agent: tf-1.0.0
Go SDK -> API User-Agent: skytap-go-sdk/tf-1.0.0

Relevant for the v2 branch

As suggested in the comments for PR #42 specific logic in the client should be moved into a separate function. This goes for the pre checking of the system state before a request is made. See : #42 (comment)

Also what happens after a request to ensure the state is as expected. See : #42 (comment)

As suggested in the comments for PR #42 the retry logic would be better handled with the go-retryable client. See https://godoc.org/github.com/hashicorp/go-retryablehttp#Client