Java11 (Java9 really) introduces a new modern API to make HTTP calls which enables us to get rid of the Google API's HTTP client third-party libraries.

This is important because it would lead to a simpler, and easier to integrate client.

Other DNSimple API clients provide specific models for common tasks such as defining pagination parameters. We should have those in this client to avoid having to directly deal with maps and reduce the chance for accidental errors due to typos in key names or data types.

This issue should probably be combined with a review of the arg types of all endpoint methods using the Go client as a baseline, although I would suggest a deviation on the ID args that we know positively that are numbers, which in the Go client are String. I propose we use Long to make our output data classes interoperable with API calls as in: get account and use the account object to update the account without requiring to cast or transform values.

Hello,

Please publish this library to the maven central repositories to make it easier to include it in the projects.

Thanks

Setup CI via Travis to run automatically on commits.

Our client relies on global state in the form of the Dnsimple class for some of the configuration concerns during the instantiation of our Client.

We shouldn't rely on global state and, on top of that, there should be a single point in the system to provide configuration, preferably through a constructor's args.

We need to provide templates to guide the process of creation of issues and PRs

The methods downloadCertificate and getCertificatePrivateKey both return a CertificateBundle object.

The issue here is that if I am downloading and I access the getPrivateKey method on the CertificateBundle, I'll be greeted with a juicy Null.

It would be way better to separate the CertificateBundle into (at least) two objects so that there are no surprises for the developer working with our Java client.

Here is a case where this was misused, and worst of all, we show it when we showcase how our Java client works! In our API showcase, if you click on Java and then SSL Certificates, you will see the last example is wrong and will result in a Null being returned and not the desired private key! You can actually see it in the dnsimple app as well

How do I set the access token I generated from my account page?

The read me usage does not make any sense.

Client client = new Client();
WhoamiResponse response = client.identity.whoami();
Account account = response.getData().getAccount();
System.out.println("Account: " + account);

How can you get information about the current authenticated context when no authentication was seemingly done?

Current data classes have non-coherent property types when compared to each other. For example, the id of a zone record is an int on creation and a string on deletion. An account's id can also be long and string depending on the circumstance.

Data class property types:

• should be coherent from a domain's perspective e.g. an account's id must be of the same type regardless of the data class where it's living.
• should be coherent from a technical perspective e.g. all ids, dates, times, etc. should be of the same type across all data classes

We should base our changes on the Go client, which is the most exigent client regarding data types.

Out current design forces our users to import Google API's HTTP client library, which is great if they previously were using it but a game-stopper if not.

To stop doing this we need to:

• Provide an extension point (an interface) so that users can provide their own implementations
• Change all inner workings of this library so that we don't make any assumption about how the HTTP calls are made. i.e. no part of our library should be coupled to a third-party library except for the class implementing the interface defining the extension point.

README.md, CONTRIBUTING.md, and CHANGELOG should be updated with all the adaptations required for v1.0.0

@dependabot badge me dependabot/feedback#6 (comment)

It is possible for me to add A record using curl, however when using Java client API and specifically running this line:
dnsClient.zones .createZoneRecord(clientId, myDomain, ZoneRecordOptions .of("ABC", "A", "1.2.3.4"))
I get 400 Http Status. After debugging very deep the client library, I found the following error message:
"Regions are not allowed in Your plan"
I am not setting up any region explicitly - in the debug mode I see that the Java Client placed here "global" as written in the documentation. I think there is a bug in the library as it adds the "global" region, but then it validates the request against the plan and reject it, due to the regions value specified.
When I set the value of regions to null explicitly via Java reflection mechanism, everything works fine

Each time we need to release a new version, we need to update the version of the project twice. Gradle has plugins to automate that process. We should investigate and put in place the simplest possible system that helps us reduce work during releases.

While working on #30 I concept-tested a new kind of test that, instead of using the mocks in place - which parse and manipulate fixtures, introducing false positives, it spun up a lightweight HTTP server to replay untampered fixtures.

This test avoids the introduction of false positives by putting in motion the full HTTP stack of our client without requiring live requests to our API.

We should migrate the full test suite to this kind of test to uncover and fix any remaining false positives.

We need a format code styler for this repo. Perhaps something like https://github.com/checkstyle/checkstyle?

dnsimple/dnsimple-developer#250 updated the fixtures to apply what we learned while working on #35

We should update all fixtures from the dnsimple-developers repo.

Belongs to https://github.com/dnsimple/dnsimple-business/issues/1132

We should provide an easy way for users to test this client without having to mock HTTP requests

Hello,

I'm trying to create a zone record on my sandbox environment but I get an error:
"Regions are not allowed for your plan."

        ZoneRecordOptions zoneRecordOptions = ZoneRecordOptions.of(subdomain, "A", ip);
        dnsimpleClient.zones.createZoneRecord(dnsimpleConfig.getAccountId(),
                dnsimpleConfig.getMainDomain(), zoneRecordOptions);

So it seems by default the API uses the region global and there is no way at least of my knowledge to set to null the region.

    public static ZoneRecordOptions of(String name, String type, String content) {
        return new ZoneRecordOptions(name, type, content, null, null, singletonList("global"));
    }

Thanks

The recently published C# client uses generic empty, simple, list, and paginated classes with type parameters, which would dramatically decrease the footprint of library.

Current data classes have a series of flaws:

• They are coupled to third party libraries, which makes our users have to deal with the libraries we've chosen to implement the client.
• They are mutable, which is confusing and promotes unwanted use of our library.

Our data classes should be:

• Immutable. They should be considered static, fixed values that our API provides. No user should be able to tamper with values generated by us based on API call responses
• They should be POJOs that don't know anything about how they are created. Therefore, they should have no dependencies on third-party libraries whatsoever.

The Google HTTP client library we're using uses an HttpTransport implementation that doesn't support the PATCH HTTP method, which would make all our API methods requiring it impossible to be used with this client.

This example test method can be used to reproduce the error:

package com.dnsimple.regression;

import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;

import com.dnsimple.Client;
import com.dnsimple.Dnsimple;
import com.dnsimple.exception.DnsimpleException;
import com.dnsimple.response.UpdateContactResponse;
import java.io.IOException;
import java.util.Collections;
import org.junit.Test;

public class UpdateContactTest {
  @Test
  public void HTTP_method_PATCH_not_supported() throws IOException, DnsimpleException {
    Dnsimple.setApiBase("https://api.sandbox.dnsimple.com");
    Client client = new Client();
    client.setAccessToken("YOUR TOKEN");

    UpdateContactResponse response = client.contacts.updateContact("2622", "1324", Collections.singletonMap("label", "chuchu"));
    assertThat(response.getData().getLabel(), is("chuchu"));
  }
}

This is the stacktrace:

java.lang.IllegalArgumentException: HTTP method PATCH not supported

	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:164)
	at com.google.api.client.util.Preconditions.checkArgument(Preconditions.java:67)
	at com.google.api.client.http.javanet.NetHttpTransport.buildRequest(NetHttpTransport.java:146)
	at com.google.api.client.http.javanet.NetHttpTransport.buildRequest(NetHttpTransport.java:55)
	at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:889)
	at com.dnsimple.endpoints.http.HttpEndpointClient.request(HttpEndpointClient.java:150)
	at com.dnsimple.endpoints.http.HttpEndpointClient.patch(HttpEndpointClient.java:111)
	at com.dnsimple.endpoints.http.HttpEndpointClient.patch(HttpEndpointClient.java:107)
	at com.dnsimple.endpoints.http.ContactsEndpoint.updateContact(ContactsEndpoint.java:48)
	at com.dnsimple.regression.UpdateContactTest.issue_13_deleteZoneRecord_throws_IllegalArgumentException(UpdateContactTest.java:24)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)

The fix for this is to add a new dependency that bridges Google HTTP client library requests through the Apache HTTP client library, and setting the transport to an instance of ApacheHTTPTransport:

public class HttpEndpointClient {

  // ...

  public HttpEndpointClient() {
    this.transport = new ApacheHttpTransport();
  }

  // ...
}

(and, in the pom.xml)

    <dependency>
      <groupId>com.google.http-client</groupId>
      <artifactId>google-http-client-apache-v2</artifactId>
      <version>1.35.0</version>
    </dependency>

We should have an automated process that deals with refreshing the fixture files. Such a process should/could/would:

• Download the fixtures from https://github.com/dnsimple/dnsimple-developer
• Compare downloaded fixtures with present fixtures and provide a report with new, changed, removed, unknown (as in fixtures that have been created only in this repo) fixtures
• Run the tests and report back if any test breaks due to changes on the fixtures
• Stash all the changes, commit and even push them

We should add automatic coverage reports to our builds with some tool like https://codecov.io

We should add a badge for that on the README.md

We shouldn't break the build on CI for changes in coverage.

Current error types have a series of flaws:

• The base class DnsimpleException it's a checked exception class, and it has a non-standard constructors scheme with args that suggest we would be providing some details about errors that ultimately we're not filling in when creating exception instances.
• There's a specific ResourceNotFoundException class for HTTP 404s, but DnsimpleException is used otherwise, which makes it difficult to make sense of errors and their context.

Exceptions should be:

• Unchecked
• Follow the standard constructor guidelines from Throwable
• Be as specific as possible

Blocked by #67

We don't want users to ever extend that part of the client. The goal of having those in the past was to give them options for mocking them in their tests, but we will be providing better built-in alternatives that avoid opening implementation details such as those interfaces.

• Prescribe Temurin 11 (LTS) for working on this project (.tool-versions, CONTRIBUTING.md, etc)
• Use Temurin 11 (LTS) for CI

Temurin website at https://adoptium.net

More context at https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-an-update/

Using 0.6.0

While invoking com.dnsimple.Zones#deleteZoneRecord against the production API I keep getting an exception even when the underlying HTTP call returns a successful 204 response and the corresponding zone record is deleted (no longer visible in the dnsimple.com UI)

Within com.dnsimple.endpoints.http.HttpEndpointClient#parseResponse an exception is thrown as it attempts to parse JSON from the response body, however there is none present in this call (the API documentation notes it just returns a 204 when successful).

The exception thrown is: java.lang.IllegalArgumentException: no JSON input found