WebApiClient is an MIT-licensed C# REST API client library for .NET developers who declare HTTP endpoints as interfaces instead of hand-writing HttpClient plumbing.

What it is

WebApiClient lives in the .NET and C# ecosystem and occupies the same slot as declaration-style REST clients such as refit and Retrofit: the developer writes a C# interface, and the library supplies the implementation that performs the request. Its stated goal is better functionality, performance, and scalability than refit. Development work is limited to semantic declaration of interfaces, so the generated client owns request construction, serialization, and dispatch rather than leaving that code in the application.

The concrete problem it solves is the repetitive glue that accumulates around HTTP calls in .NET services. Each hand-written client needs serialization, authentication, retry policy, caching, and logging wired in separately, and each OpenApi-described endpoint needs an interface declared to match it. WebApiClientCore addresses this by generating interface code from local or remote OpenApi documents, by offering OAuth2 and token management extension packages for identity and authorization, and by supplying interceptors, filters, logs, retries, and custom caches as aspects. Syntax analysis and prompts on interface declarations catch improper syntax before it reaches runtime.

Key capabilities

• Semantic declaration: client development requires only a C# interface, with no implementation code written by the consumer.
• Diverse serialization: json, xml, form, and custom serialization methods are supported.
• Full trimmed and AOT publishing on .NET8.
• Aspect-oriented programming: multiple interceptors, filters, logs, retries, and custom caches can be attached to a client.
• Code syntax analysis and prompts for interface declarations, which helps developers avoid improper syntax when declaring interfaces.
• Quick access to identity: OAuth2 and token management extension packages handle authentication and authorization.
• Swagger to code: parsing of local or remote OpenApi documents generates WebApiClientCore interface code, reducing manual interface declaration work.
• BenchmarkDotNet results place performance 2.X times ahead of refit across various request types.

Who uses it and how

• .NET teams consuming OpenApi or Swagger-described services, who generate WebApiClientCore interfaces from the remote document instead of writing each declaration by hand.
• Services that call OAuth2-protected APIs and need token management handled by an extension package rather than custom middleware.
• Applications published as full trimmed or AOT builds on .NET8, where reflection-heavy client code is a problem.
• Projects integrating JSON and XML APIs, or JSON-RPC clients, which the topic list covers alongside form and custom serialization.
• Teams already standardised on refit-style declaration clients that want retry, cache, and logging behaviour expressed as aspects on the same interface.

Getting started

The README points to documentation at https://webapiclient.github.io/ and an English version at https://webapiclient.github.io/en/, with the library itself distributed as the WebApiClientCore package referenced by the benchmark project path WebApiClientCore.Benchmarks and by the Swagger-to-code generator. The README excerpt provided here does not state an explicit install command, so the documentation site is the source for setup steps.

How it compares

Against refit, the project claims better functionality, performance, and scalability, with BenchmarkDotNet results showing 2.X times ahead on various requests. Retrofit, listed among the topics, occupies the same declaration-client position in the Android and Java world but is not a .NET library, so it is not a drop-in alternative for C# projects. WebApiClient is MIT-licensed, which places it alongside those peers on licence terms rather than behind a paid tier.

When to use it — and when not to

This is a client library, so there is no database, object storage, or SMTP service for an adopter to operate; the cost of adoption is a NuGet dependency and the declaration work, not infrastructure. Teams outside .NET should not pick it, since the entire model is built on C# interfaces and .NET8 features such as full trimming and AOT. The README excerpt is thin on concrete install instructions despite a recent push, and with 14 open issues it is a mature but actively maintained project rather than a frozen one.