# Another In-House API Server Frameworklet
-I just wanted a basic little API server for toy projects, without having to park a container-ship of modules under it.
+I just wanted a basic little API server for toy projects, without having to park a container-ship of modules under them.
-This is in no way intended to replace any mature, full-featured framework. It is spartan in some aspects, brings some unexpected baggage in others, makes some questionable design decisions, has the occasional opinion, and is likely somewhat idiosyncratic from an outside perspective.
+So here is a low-dependency toy web server framework. It includes a simple router, some bundled middlewares such as body-parsing and content-negotiation, convenience functions, and a number of opinions.
-This was also created as a means to gain a better understanding of the existing web framework ecosystem by fussing with all the involved fiddly bits, a priori, from the bottom up.
+This is not drop-in compatible with the industry standards, and is in no way intended to replace any mature, full-featured framework. It is spartan in some aspects, brings some unexpected baggage in others, probably makes some questionable design decisions, and is likely somewhat idiosyncratic from an outside perspective.
The primary design goals are:
-- self-contained: as few external dependencies as feasible
-- not-infinitely-extensible: only does the things it needs to do as dictated by the projects it is used in
-- learning from mistakes made along the way
+- self-contained: Uses as few external dependencies as are feasible.
+- not-infinitely-extensible: The projects it gets used in drive the feature set.
+- learning from mistakes made along the way: This was partly created as a means to gain a better understanding of the existing web framework ecosystem by fussing with all the involved fiddly bits, a priori, from the bottom up.
## Getting Started
Within the application implementation:
- `on(method, urlPath, handler)` declares a thing to do when a request matches.
-- `preHandler(req, res, ctx)` can be overridden to do something to every request before it is handled.
-
-Handled content types can be extended by overriding:
-- `parseBody(contentType, ctx)` for incoming types.
-- `renderError(contentType, err)` for outgoing types.
+- `preHandler(req, res, ctx)` is called on every request before the handler function, by default adding some request information to the context.
Within your handlers:
+- parameters from the route and query, along with other metadata, are set in each context.
- `setResponseType(responseTypes, req, res, ctx)` can be called to negotiate content types.
-- `async ingestBody(req, res, ctx)` will parse request body data.
+- `async ingestBody(req, res, ctx, options)` will parse request body data.
- throw an `Error.ResponseError` with an `Enum.ErrorResponse` for a simple status code with optional details, when something goes awry.
-Parameters and metadata are set in each request context.
+Negotiated content types can be extended by overriding:
+- `parseBody(contentType, ctx)` for incoming types.
+- `renderError(contentType, err)` for outgoing types.
+
+Some handler functions are provided:
+- `handlerGetStaticFile(req, res, ctx, file)` will return a file from a configured directory, and also supports including CERN-style header metadata. It will also serve pre-encoded variations (e.g `.gz` or `.br`) if available and requested.
+- `handlerRedirect(req, res, ctx, newPath, statusCode)` will return a redirect response.
projects / squeep-api-dingus / commitdiff