Response

Build responses with the res helpers rather than a raw Response. They apply the JSON content type and CORS headers, and normalise the payload.

import { res, res_201, res_400 } from "apiker";

res("Hello")                 // { "message": "Hello" }
res({ id: 1, name: "Ada" })  // { "id": 1, "name": "Ada" }
res({ id: 1 }, 201)          // same body, status 201
res_400("Email required")    // { "message": "Email required" }, status 400

A string or a number becomes { message: value }. An object is serialised as-is. Passing nothing gives an empty object.

Status helpers

Each one takes the same arguments as res and carries a sensible default message, so res_404() alone is a complete answer.

res_200 — Success
res_201 — Created
res_204 — No Content
res_400 — Bad request
res_401 — Forbidden
res_404 — Not found
res_405 — Invalid Method
res_429 — Too many requests
res_500 — Internal Server Error

Custom status and headers

The second argument is either a status code or a full init object, merged over the defaults.

res({ ok: true }, { status: 202, headers: { "X-Request-Id": id } });

Non-JSON responses

resRaw skips serialisation, for HTML, scripts or plain text.

import { resRaw } from "apiker";

resRaw("<h1>Hello</h1>");                  // text/html
resRaw("console.log(1)", "text/javascript");

CORS

Every helper sends permissive CORS headers by default, so a browser on any origin can call your API:

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,HEAD,PUT,POST,DELETE,PATCH
content-type: application/json

A wildcard origin combined with credentials is fine for a public API, but if you serve authenticated browser traffic, override the origin header with your own domain.