Web applications can expose custom HTTP endpoints

Allow Web projects to expose application-defined HTTP endpoints for webhooks, health checks, OAuth callbacks, integrations, custom error responses, and lightweight JSON services.

Requests should be handled without creating a logical browser session or loading a WebPage/control graph. The API should provide typed access to the HTTP method, canonical path, query parameters, headers, cookies, request body, connection information, and cancellation. Applications should be able to return status codes, headers, cookies, redirects, text, JSON, binary data, or an explicit empty response. Both synchronous and asynchronous handlers should be supported.

Objo's browser-client, WebSocket, IDE-authentication, Canvas-runtime, and deployed-resource routes must remain reserved and must take precedence over application endpoints. Unhandled requests should retain the normal 404 response. Request execution must use bounded queues, body and response limits, timeouts, cancellation, safe error handling, and isolated runtime state so the feature remains suitable for deployed applications under concurrent load.

A Web project with an HTTP request handler but no default WebPage should be valid as a service-only application and should not package or initialise the browser UI runtime.