How do their APIs compare?

I can only meaningfully compare these two projects at a conceptual level, since they serve fundamentally different purposes — one is a runtime web framework, the other is an educational algorithms library. Let me lay out what the retrieved code shows about each "API."

koajs/koa: a runtime, object-oriented HTTP API

Koa's public surface is built around three delegating objects — Context, Request, and Response — that wrap Node's raw http primitives (req/res) with getters/setters and convenience methods, as described in [Readme.md:L88-L141].

Concretely, from the retrieved source:

• Property-style accessors with side effects: request.querystring has both a getter and setter; the setter re-parses the URL, updates url.search, clears url.path, and re-stringifies the whole URL [lib/request.js:L201-L215]. search/search= are thin wrappers around querystring for API "ubiquity" [lib/request.js:L217-L240].
• Delegation methods: is(type, ...types) on both Request and Response just forwards to the type-is library against this.req or this.type respectively [lib/request.js:L641-L649], [lib/response.js:L474-L476] — so the API is largely a thin, ergonomic layer over existing Node/npm primitives rather than new algorithmic logic.
• Shortcuts on ctx: the context exposes ctx.type instead of ctx.response.type, ctx.accepts instead of ctx.request.accepts, etc. [Readme.md:L88-L141].
• Small self-contained utilities: lib/search-params.js (not shown in full, but exercised in [tests/lib/search-params.test.js:L1-L42]) provides stringify/parse for query strings, including edge cases like arrays and empty values — this is Koa's own minimal reimplementation of query-string handling rather than a generic algorithm.

So Koa's "API" is about shaping interaction with a live request/response lifecycle: stateful getters/setters, middleware composition (ctx, next), and delegation to Node internals. Correctness is verified through integration-style tests against a mock ctx [tests/request/query.test.js:L36-L44] and unit tests for the helper module [tests/lib/search-params.test.js:L1-L42].

trekhleb/javascript-algorithms: a functional, stateless API

This repo's "API" is a catalog of standalone functions/classes implementing classic algorithms, each independent of any runtime or I/O:

• Pure functions: getNextDirection({ railCount, currentRail, direction }) in the Rail Fence Cipher takes a plain object and returns a direction enum with no side effects [src/algorithms/cryptography/rail-fence-cipher/railFenceCipher.js:L34-L46]; encodeRailFenceCipher/decodeRailFenceCipher are exported top-level functions tested with plain input/output assertions [src/algorithms/cryptography/rail-fence-cipher/test/railFenceCipher.test.js:L1-L40].
• Class/callback-based traversal APIs: graph algorithms like BFS/DFS take a Graph/GraphVertex object plus callback hooks (enterVertex, leaveVertex) that receive { currentVertex, previousVertex } — an event-driven but still fully synchronous, deterministic API [src/algorithms/graph/depth-first-search/test/depthFirstSearch.test.js:L141-L163], [src/algorithms/graph/breadth-first-search/test/breadthFirstSearch.test.js:L71-L110, L141-L175].
• Math/matrix-based APIs: Hill Cipher documents its interface conceptually (vector-matrix multiplication mod 26) rather than as a middleware chain [src/algorithms/cryptography/hill-cipher/README.md:L11-L60].

Key contrasts

Aspect	koajs/koa	javascript-algorithms
Shape	Stateful objects (ctx, request, response) with getters/setters	Pure functions and classes with explicit inputs/outputs
Side effects	Yes — mutating URL/headers, wrapping Node req/res	None — deterministic transforms