How do their APIs compare?

These two projects operate at very different layers, so "API" means something different in each — let me break down what's actually visible in the retrieved data.

SuperSocket: server/socket framework API surface

SuperSocket exposes a runtime, object-oriented API for building socket servers and clients:

• Pipeline filters — the core abstraction for protocol parsing. IPipelineFilter<TPackage> implementations like HttpKeepAliveFilter wrap an inner filter (HttpPipelineFilter) and expose Decoder, NextFilter, and Context properties, then implement a Filter(ref SequenceReader...) method that parses a request or returns null if more data is needed [src/SuperSocket.Http/HttpKeepAliveFilter.cs:L11-L55]. This is a chain-of-responsibility style API driven at runtime.
• Middleware — e.g. CommandMiddleware.cs defines factory interfaces like ICommandSetFactory.Create(IServiceProvider, CommandOptions) for wiring up command handling via DI [src/SuperSocket.Command/CommandMiddleware.cs:L379-L393].
• Fluent/extension-method style helpers for common tasks, shown in the HTTP README: session.SendJsonResponseAsync(...), session.StartSSEAsync(), sseWriter.SendEventAsync(...) — these are convenience wrappers over manual response building [src/SuperSocket.Http/README.md:L45-L71, L219-L243].
• Client side — EasyClient<TPackage, TSendPackage> has virtual methods like OnPackageReceived that invoke a PackageHandler delegate, giving consumers an event/callback-style API for received packages [src/SuperSocket.Client/EasyClient.cs:L547-L566].

So SuperSocket's API is fundamentally imperative and reflection/interface-based at runtime — you implement interfaces (IPipelineFilter, IPackageDecoder), register middleware/handlers with DI, and the framework calls into your code as bytes arrive.

Refit: compile-time source-generated API surface

Refit's API is the opposite in nature — it's a declarative, attribute-driven interface that gets turned into generated code at compile time rather than reflection at runtime:

• You declare an interface method with attributes like [Query], [Body], [Header], [AliasAs], and the generator (Parser in InterfaceStubGenerator.Shared) parses these into models — e.g. QueryParameterModel captures shape, formatting, and encoding rules for a single query-bound parameter [src/InterfaceStubGenerator.Shared/Models/QueryParameterModel.cs:L23-L35].
• The parser (Parser.Request.Query.cs) classifies each parameter's query-binding shape — scalar, collection, dictionary, converter, or flattened object — via TryBuildQueryModel, falling back to reflection-based request building only when a shape can't be flattened at compile time (e.g. dictionaries with object-typed values) [src/InterfaceStubGenerator.Shared/Parser.Request.Query.cs:L155-L226, L408-L425].
• Diagnostics are part of the API contract too: e.g. RF002 fires if Refit isn't referenced, and RF007 fires if a source-gen-only attribute is used where inline generation isn't possible [src/InterfaceStubGenerator.Shared/DiagnosticDescriptors.cs:L9-L37].

So Refit's "API" is really your own interface definitions plus Refit's attributes, transformed by a Roslyn source generator into concrete HTTP client implementations — there's no runtime object model you interact with directly the way you do with SuperSocket's filters/middleware.

Summary comparison

Aspect	SuperSocket	Refit
API style	Runtime OOP: implement interfaces (IPipelineFilter, IPackageDecoder), register middleware	Declarative: annotate interface methods with attributes ([Query], [Body], etc.)
Extension mechanism	DI-based middleware/handlers (CommandMiddleware.cs)	Roslyn source generator (Parser.Request.*.cs) with re