Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

argo_tunnel: make V4 API response compatible #572

Conversation

jacobbednarz
Copy link
Member

@jacobbednarz jacobbednarz commented Jan 6, 2021

While diagnosing some issues implementing the cloudflare_argo_tunnel
resource in Terraform, I noticed that the API response was lacking the
outer response structure that the other V4 endpoints have.

The early implementation of Argo Tunnel endpoints didn't conform to the
V4 API standard response structure. This has been remedied going forward
however to support older clients this isn't yet the default. An explicit
Accept header is used to get the V4 compatible version.

Along with this change, is removing the use of the context package in
favour of existing request helpers. I opted not to reinvent a specific
case for this right now because:

  • It's highly unlikely these requests will need to be cancelled; and
  • This is currently a snowflake scenario and I didn't want to build a
    new interface after only needing it once. I'd prefer to wait for more
    use cases before expanding it.

As this change is internal, it won't impact clients and we can revert
this once the default response is the V4 compatible version without
interruption.

While diagnosing some issues implementing the `cloudflare_argo_tunnel`
resource in Terraform, I noticed that the API response was lacking the
outer response structure that the other V4 endpoints have.

The early implementation of Argo Tunnel endpoints didn't conform to the
V4 API standard response structure. This has been remedied going forward
however to support older clients this isn't yet the default. An explicit
`Accept` header is used to get the V4 compatible version.

Along with this change, is removing the use of the `context` package in
favour of existing request helpers. I opted not to reinvent a specific
case for this right now because:

- It's highly unlikely these requests will need to be cancelled; and
- This is currently a snowflake scenario and I didn't want to build a
  new interface after only needing it once. I'd prefer to wait for more
  use cases before expanding it.

As this change is internal, it won't impact clients and we can revert
this once the default response is the V4 compatible version without
interruption.
@patryk
Copy link
Contributor

patryk commented Jan 6, 2021

I'd prefer we kept context in these functions (the idea is to refactor all remaining functions in #324 by 0.14 release). Because we don't have makeRequest... with headers and context, we should add one.

@jacobbednarz
Copy link
Member Author

Sure thing. I didn't really want to copy paste as is due to the confusion around which method you should be using for what purposes. Alongside that, the method signatures are quite long which makes determining parameters a little more confusing again.

I'll add a new method that follows the same patterns and we can always rejig it once we get a bit more usage under our belt.

Implements `makeRequestContextWithHeaders` which is similar to
`makeRequestWithHeaders` however it accepts a context as a parameter.
@jacobbednarz
Copy link
Member Author

f90d975 has the changes I've mentioned above.

@patryk
Copy link
Contributor

patryk commented Jan 6, 2021

No worries, they are internal to the library (lowercased name), we will likely clean them up during refactor by allowing optional arguments.

@patryk patryk merged commit a396e40 into cloudflare:master Jan 6, 2021
@jacobbednarz jacobbednarz deleted the make-argo-tunnel-endpoints-use-v4-compat-version branch February 1, 2021 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants