feat(address): add address client

[jws]

What:

• Add initial directory structure, sln and csproj files for library and test.
• Add client library functionality to create/delete/get/list addresses.
  • list with parameters deferred until later.

Details:

• Usage:

            // create address
            var response = await LobClient.Address.CreateAsync(
                description: ADDRESS.Description,
                name: ADDRESS.Name,
                company: ADDRESS.Company,
                email: ADDRESS.Email,
                phone: ADDRESS.Phone,
                addressLine1: ADDRESS.AddressLine1,
                addressCity: ADDRESS.AddressCity,
                addressState: ADDRESS.AddressState,
                addressZip: ADDRESS.AddressZip,
                addressCountry: "US", // so odd we can't put UNITED STATES here
                metadata: ADDRESS.Metadata
            );

            // access results
            var httpStatusCode = response.HttpStatusCode;
            var address = response.Result;

            // get address
            await LobClient.Address.GetAsync(id: address.Id);

            // delete address
            await LobClient.Address.DeleteAsync(id: address.Id);

            // list addresses
            await LobClient.Address.ListAsync();

• Overview:
  • LobClient is instantiated with the apiKey and is used to access the various API resources e.g. LobClient.Address.CreateAsync(...) or LobClient.Letter.CreateAsync(...) later
  • LobRestClient is a thin layer over HttpClient and does only the following:
    • Query parameter handling (future)
    • Lob header handling (future)
    • Lob's API response handling (deserialization, error handling)
  • Since LobRestClient has limited intelligence, it pushes content serialization and query parameter encoding to the resource client themselves (AddressClient, LetterClient, etc.). Not a big fan, but open to ideas.

        // LobRestClient.cs
        public async Task<LobResponse<TResult>> ExecuteAsync<TResult>(
            HttpMethod method,
            string requestUrl,
            HttpContent content = null,
            IDictionary<string, string> queryParams = null,
            LobRequestOptions requestOptions = null)

• Notes:
  • This version of the library uses async / await, so we do not support clients without said capability.
  • Since request and response have varying fields (especially for other mail types), the design is to use separate objects. e.g.

public Task<LobResponse<AddressResource>> CreateAsync(CreateAddressRequest options)

• We won't know if this client structure will work going forward until we get to the more complicated types. e.g. Letters. Address is too simplistic. I can see challenges here:
  • Request/Response fields with multiple possible types. Object is the common denominator, but still need to think if that should be exposed to the end user. Also this will be interesting when it comes to serialization and content types.
  • Nested objects (inline address, fancy list filtering, etc.)

[virtualdom]

This is a great base to start with and we can iterate on it. Thanks for putting in the initial work, Jin! LGTM

[dckrooney]

LGTM, with some questions/nits

[dckrooney]

Leftover from debugging?

[dckrooney]

Do we need these prefixed with Address if they're already part of the AddressResource class?

[jws]

since it is reflected with the prefix in the API schema, just keeping it 1-1. its also arguably clearer, since we bundle a number of non-address fields into our address object.