Resty replaces repeated HTTP plumbing with one client API
Resty gives Go developers a fluent layer for building requests, encoding bodies, parsing responses, setting authentication, uploading files, tracing calls, and handling redirects. Client settings become defaults, while a request can override many of them. Middleware covers work before and after the round trip.
The repository stays compact despite that surface. Our checkout contained 56 files, about 26,758 source lines, and occupied 3.4 MB. Most tests live beside the implementation as Go convention encourages, so the absence of a tests directory is not a missing-test signal here.
Version 3 adds client-side resilience beyond retries
The v3 documentation covers retry conditions and delay strategies, request timeouts, circuit breakers, hedged requests, rate limiting, and load balancing. Round-robin and weighted round-robin algorithms are built in, including weighted SRV discovery, while a custom interface can choose another host-selection method.
Our install pulled only 6 packages in 7 seconds, a small cost for this feature set. Resty still sits above net/http, so transport settings and standard request behavior remain relevant.
What happened when we ran it
Our sandbox installed Resty in 7 seconds with 6 Go packages. The build then succeeded in 27 seconds. We used commit 51f294a in a fresh unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. The 56-file checkout was 3.4 MB and contained roughly 26,758 lines of source.
The test command completed in 57 seconds, and go test reported 2 passed, 0 failed of 2. It also found no tests directory, while the repository tree places many _test.go files beside their source. These results confirm that the measured commit installed, compiled, and passed the available Go test invocation in our environment.
Version 3 is an RC while v2.17.2 is the stable release
Resty's default branch, README, module path, and current documentation focus on v3. The site labels v3 a release candidate, and the newest prerelease was v3.0.0-rc.4 on September 6, 2026. GitHub's latest stable endpoint instead returns v2.17.2, published February 14. Teams should make that choice explicitly because v3 changes the module path to resty.dev/v3 and includes breaking API changes documented in the upgrade guide.
Our lab used the 51f294a v3 commit and passed its 27-second build plus 57-second test step. That is good evidence for the candidate's repository health, but it does not turn an RC into a final release.
A v3 client should close once during application shutdown
Version 3 adds Client.Close because a client can own background resources, including certificate watchers and load balancers. The migration guide says not to close it after every request. Build one client for the intended scope, reuse it, and call Close during shutdown.
The 26,758-line codebase includes more stateful behavior than its 3.4 MB checkout suggests. Retry settings can exist at client and request level, response bodies may be streamed or saved, and resilience components keep their own timing and host state. A thin internal wrapper should expose context, shutdown, and the policies callers genuinely need.
Three open issues define specific v3 limits
Issue 1046 reports that a SetFiles request works on v2 but reaches an HTTP 412 response with empty form data on a v3 beta. Issue 1142 reports that TraceInfo().TotalTime showed 363 ms for an operation whose retry path consumed 30 seconds. Issue 1213 says a load balancer may select an unreachable host again because connection errors do not produce the expected feedback. Each report is narrow and remains open.
GitHub listed 19 open issues and pull requests when fetched, split into 9 issues and 10 pull requests in the API response. That is a manageable queue for an 11,791-star project, though volume alone says little about severity. For file uploads, tracing, or client-side balancing, turn the relevant report into a regression test before migration. The passing 2-of-2 lab result covers the repository command, not every application-specific combination.
The standard library wins when the request is simple
Go's net/http is the better default for a small client that sends a few requests and already has clear error handling. Resty earns its import when shared authentication, typed body handling, middleware, retries, tracing, or resilience policies would otherwise be rebuilt in each call site. Its fluent API can make ordinary work shorter, but it also gives a team another vocabulary and version boundary to maintain.
A 7-second install, 27-second build, and 57-second passing test step make comparison cheap. Req is the closest broad alternative, while go-retryablehttp is narrower when retry policy is the only missing piece. Heimdall also centers timeouts, retries, and circuit breaking. Pick by the smallest surface that covers the service's real needs, then test cancellation, body replay, redirects, and logging with the same transports used in production.
September activity supports v3, but migration still needs a gate
The last push was September 7, 2026, one day after v3.0.0-rc.4. That release fixed multipart shutdown, digest parsing, buffer ownership, SSE locking, hedging, and load-balancer concurrency, and it added tests and CI hardening. Combined with current issue replies and 10 open pull requests, the dates show active maintenance. They also show that v3 is still receiving fixes in code paths that production clients may exercise.
Our measured commit passed all 2 reported Go test results and built without special setup. Resty v2 is the conservative choice for teams that want a final tag, while v3 is a credible candidate for applications that need its broader resilience layer. Migration should include application tests for retries, uploads, traces, and shutdown. If those features are absent from your client, standard Go remains easier to explain and maintain.