Skip to content

Latest commit

 

History

History
48 lines (39 loc) · 3.11 KB

DESIGN.md

File metadata and controls

48 lines (39 loc) · 3.11 KB
Raw

HTTP Provider Design

The HTTP Provider offers functionality for interacting with generic HTTP servers as part of terraform configuration. Specifically, the provider issues an HTTP GET request to the defined URL on every Terraform run.

Below we have a collection of Goals and Patterns: they represent the guiding principles applied during the development of this provider. Some are in place, others are ongoing processes, others are still just inspirational.

Goals

  • Stability over features
  • Provide managed data source to issue HTTP GET request. The underlying default transport uses HTTP/1.1 for HTTP URLs and either HTTP/1.1 or HTTP/2.0 for HTTPS URLs depending on whether the server supports HTTP/2.0. Non-standard protocols (e.g., SPDY, QUIC) are not supported.
  • Support usage of either http (plaintext) or https (secure) requests. The current version of this provider is built with Go 1.22 which supports TLS/1.0 (deprecated), TLS/1.1 (deprecated), TLS/1.2 and TLS/1.3. TLS support will track the version of Go that the provider is built with and will likely change over time.
  • Support the supplying of request headers.
  • Expose response headers returned from request.
  • Expose response body as string where applicable.

Patterns

Specific to this provider:

  • Only idempotent GET requests are supported.
  • Only 200 status codes are considered successful.

General to development:

  • Avoid repetition: the entities managed can sometimes require similar pieces of logic and/or schema to be realised. When this happens it's important to keep the code shared in communal sections, so to avoid having to modify code in multiple places when they start changing.
  • Test expectations as well as bugs: While it's typical to write tests to exercise a new functionality, it's key to also provide tests for issues that get identified and fixed, so to prove resolution as well as avoid regression.
  • Automate boring tasks: Processes that are manual, repetitive and can be automated, should be. In addition to be a time-saving practice, this ensures consistency and reduces human error (ex. static code analysis).
  • Semantic versioning: Adhering to HashiCorp's own Versioning Specification ensures we provide a consistent practitioner experience, and a clear process to deprecation and decommission.