Resty

Resty is a Go library for making HTTP and REST calls with a fluent, chainable API inspired by Ruby’s rest-client. Instead of hand-assembling net/http requests, developers build requests through methods like SetHeader, SetBody, SetResult, and SetQueryParam, with automatic JSON/XML marshaling and unmarshaling based on content type.

Beyond the basic request/response cycle, Resty ships with production-oriented features out of the box: configurable backoff retries with custom retry conditions, request/response middleware hooks, cookie jar support, Basic and Bearer auth, digest authentication, TLS and certificate configuration, path and query parameter helpers, multipart file uploads, redirect policies, SRV-record-based requests, and on-demand curl command generation for debugging.

The library has been stable and widely adopted in the Go ecosystem since 2015, with the v2 module line (github.com/go-resty/resty/v2) maintained as the long-term stable API while newer experimental work happens on a separate v3 branch. It is goroutine-safe and designed so a single *resty.Client can be reused across an application.

What You Get

• Chainable client and request builders (SetHeader, SetBody, SetQueryParam, SetPathParams, SetResult, SetError) instead of manual http.Request construction
• Automatic marshal/unmarshal of JSON and XML request and response bodies, including RFC7807 problem-detail error responses
• Configurable backoff retry mechanism with custom RetryConditionFunc predicates and OnRetryFunc hooks
• Request and response middleware pipeline (OnBeforeRequest / OnAfterResponse) for cross-cutting concerns like logging or auth injection
• Built-in Basic Auth, Bearer token, and full HTTP Digest authentication support
• Multipart file upload helpers with automatic content-type detection
• TLS root certificate and client certificate configuration, plus pluggable http.RoundTripper transport
• Redirect policies (NoRedirectPolicy, FlexibleRedirectPolicy, DomainCheckRedirectPolicy) and SRV-record-based host resolution
• Request tracing (EnableTrace) exposing DNS lookup, connection, and TLS handshake timings
• On-demand curl command generation for a request when debug mode is enabled, useful for reproducing failing calls outside the app

Common Use Cases

• Calling third-party REST APIs from a Go backend with automatic JSON decoding into typed structs via SetResult/SetError
• Building internal service-to-service HTTP clients that need retry-with-backoff and consistent auth headers across every call
• Uploading files or form-encoded multipart payloads to an API endpoint without manually constructing multipart.Writer boilerplate
• Debugging flaky external API integrations by enabling Resty’s debug logging and curl-command generation to see exactly what was sent
• Talking to APIs that require HTTP Digest authentication, which the standard library does not implement

Under The Hood

Architecture Resty centers on a *Client (created via resty.New(), wrapping a standard *http.Client with a public-suffix-aware cookie jar) and a *Request built per call through Client.R(). Execution runs each request through an ordered chain of RequestMiddleware functions defined in middleware.go (URL/path-param interpolation, header assembly, body encoding) before handing off to the wrapped http.Client.Do, then through a parallel ResponseMiddleware chain (body decoding into SetResult/SetError targets, RFC7807 handling) on the way back. Retry logic in retry.go wraps this whole cycle with configurable backoff, jitter, and pluggable RetryConditionFunc/OnRetryFunc hooks rather than being baked into the core request path, and digest authentication (digest.go) is implemented as a separate middleware that intercepts a 401 challenge and replays the request with computed credentials. This keeps the core request/response cycle small while letting orthogonal concerns (retries, auth, tracing) plug in as middleware rather than branching logic in the client itself.

Tech Stack Resty v2 is dependency-light: golang.org/x/net for the public-suffix list used by the cookie jar, and golang.org/x/time for rate-limiting-adjacent time utilities, are its only non-stdlib requirements per go.mod/go.sum. Everything else — the HTTP transport (transport.go, with build-tagged variants for js/wasm vs. standard targets in transport_js.go/transport_other.go), TLS handling, and multipart encoding — is built directly on net/http, net/url, crypto/tls, and mime/multipart from the Go standard library. The module targets Go 1.23+ and is published under the versioned import path github.com/go-resty/resty/v2, Go’s mechanism for a library’s major-version-2 release.

Code Quality The v2 branch carries nine _test.go files (client, context, curl, digest, middleware, request, resty, retry, util) alongside their corresponding implementation files, indicating close 1:1 test coverage of the public surface, plus an example_test.go providing runnable, godoc-indexed usage examples. Comment density in the core files is high — client.go alone is roughly a third comments — with doc comments following Go convention (exported identifiers documented, [Type.Method] cross-reference links used throughout for godoc). Error handling favors explicit sentinel errors (e.g. ErrAutoRedirectDisabled) and wrapped errors via errors/fmt.Errorf rather than panics. CI (GitHub Actions) runs the build/test matrix against both the stable and pinned 1.23.x Go toolchains on every push and PR to the v2 branch.

API Design The chainable-setter style (client.R().SetHeader(...).SetResult(...).Get(url)) reads close to natural language and keeps a single call expression readable even with many options, following the pattern popularized by Ruby’s rest-client and widely imitated in other Go HTTP clients. Getting started requires almost no boilerplate — resty.New().R().Get(url) is a complete request — while still exposing the underlying *http.Request/*http.Response for callers who need lower-level access. Method and field naming is consistent (Set* for configuration, Enable*/Disable* for toggles), and the maintainers document breaking-change intent explicitly in code (e.g. the deprecated HostURL field points callers to BaseURL), which lowers the risk of silent behavior changes across upgrades.