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.)