Request & Response

The MionRequest and MionResponse objects available to every hook/route within the CallContext (first parameter of every hook/route).

mion's request and response are different from the underlying native http request and response, so mion can be used seamlessly in different environments.

@mionkit/http uses node's native IncomingMessage and ServerResponse while @mionkit/serverless uses APIGatewayEvent and APIGatewayProxyResult. But routes and hooks will alway receive a standard MionRequest & MionResponse.

Quick Tip:
Passing the correct parameters to routes and hooks is automatically managed by mion so accessing the Request and Response objects is not usually required.
Developers just need to take care of declaring the route/hook parameters and their types.

How data is sent and received

When making a route call the URL.path is the route's id and is used for the route lookup. The http request body is a json object where keys are the route or hooks ids and the values are Arrays containing the parameters for each respective route or hook. This is done so multiple hooks or routes can be called in a single http request.

The http response follows the same format were the body is a json object where the keys are the ids and the values are the responses from the remote methods.

Request PathRequest BodyResponse Body
/sayHello{"sayHello": ["John"] }{"sayHello": "Hello John."}
/greetings{"greetings": ["Adan", "Eve"] }{"greetings": "Hello Adan and Eve."}

The reason for this format is to be able to send/receive data for multiple hooks and routes in a single http request, independently of which route has been called.

import {Routes} from '@mionkit/router';

const routes = {
    sayHello: (ctx, name: string): string => {
        return `Hello ${name}.`;
    greetings: (ctx, name1: string, name2: string): string => {
        return `Hello ${name1} and ${name2}.`;
} satisfies Routes;
Please note all this logic of correctly formatting request & response data is handled transparently by the Client.

Type Reference


mion's Request object, does not depends on the underlay native request.

export interface MionRequest {
    /** parsed headers */
    readonly headers: Readonly<MionHeaders>;
    /** json encoded request body. */
    readonly rawBody: string;
    /** parsed request body */
    readonly body: Readonly<AnyObject>;
    /** All errors thrown during the call are stored here so they can bee logged or handler by a some error handler hook */
    readonly internalErrors: Readonly<RpcError[]>;


mion's Response object, does not depends on the underlay native response.

export interface MionResponse {
    /** response http status code */
    readonly statusCode: number;
    /** response headers */
    readonly headers: Readonly<MionHeaders>;
    /** json encoded response body, filled only after all routes/hook has ben finalized. */
    readonly rawBody: string;
    /** the router response data, body should not be modified manually so marked as Read Only */
    readonly body: Readonly<RemoteMethodResponses>;
    /** response errors: empty if there were no errors during execution */
    readonly hasErrors: boolean;


mion's headers object, does not depends on the underlay native response.

Similar to the Headers Fetch API

export interface MionHeaders {
    append(name: string, value: HeaderValue): void;
    delete(name: string): void;
    set(name: string, value: HeaderValue): void;
    get(name: string): HeaderValue | undefined | null;
    has(name: string): boolean;
    entries(): IterableIterator<[string, HeaderValue]>;
    keys(): IterableIterator<string>;
    values(): IterableIterator<HeaderValue>;