@telorun/http-server 0.1.7 → 0.1.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +7 -0
- package/README.md +150 -0
- package/package.json +21 -2
package/CHANGELOG.md
CHANGED
package/README.md
ADDED
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
# Telo HTTP Standard Specification (v1.0 Draft)
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
The `Http.Server` and `Http.Api` manifests in Telo are designed to be strictly **language-agnostic** and **framework-agnostic**. To maintain the "Zero Lock-in" promise, the underlying HTTP engine (e.g., Fastify in Node.js, Actix in Rust) is treated purely as an implementation detail.
|
|
6
|
+
|
|
7
|
+
All HTTP modules integrated into the Telo kernel **must** adhere to this behavioral contract. This ensures that a YAML manifest written today will execute with exactly the same I/O and validation behavior regardless of the underlying language or framework.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 1. Routing Contract (Path Definitions)
|
|
12
|
+
|
|
13
|
+
Different web frameworks use different syntaxes for path parameters (e.g., `/users/:id` vs. `/users/{id}`).
|
|
14
|
+
|
|
15
|
+
Telo standardizes on the **OpenAPI specification format** for paths.
|
|
16
|
+
|
|
17
|
+
- **Standard:** Path parameters MUST be enclosed in curly braces: `{parameterName}`.
|
|
18
|
+
- **Module Responsibility:** The underlying HTTP module must parse the Telo path and translate it into its framework's native routing syntax at startup.
|
|
19
|
+
|
|
20
|
+
**Example Manifest Path:** `/api/v1/users/{userId}`
|
|
21
|
+
|
|
22
|
+
- _Node.js (Fastify) Adapter translates to:_ `/api/v1/users/:userId`
|
|
23
|
+
- _Rust (Actix) Adapter translates to:_ `/api/v1/users/{userId}`
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 2. The I/O Context Contract
|
|
28
|
+
|
|
29
|
+
When an incoming HTTP request is received, the underlying framework must normalize it into a standard **Telo Request Object** before passing it to the Handler/CEL engine. Conversely, it must accept a standard **Telo Response Object** to send back to the client.
|
|
30
|
+
|
|
31
|
+
### 2.1. Standardized Telo Request Object (Input)
|
|
32
|
+
|
|
33
|
+
The HTTP module must construct and pass the following exact payload to the execution environment:
|
|
34
|
+
|
|
35
|
+
```json
|
|
36
|
+
{
|
|
37
|
+
"request": {
|
|
38
|
+
"method": "POST",
|
|
39
|
+
"path": "/api/v1/users/123",
|
|
40
|
+
"params": { "userId": "123" },
|
|
41
|
+
"query": { "active": "true" },
|
|
42
|
+
"headers": {
|
|
43
|
+
"content-type": "application/json",
|
|
44
|
+
"authorization": "Bearer token..."
|
|
45
|
+
},
|
|
46
|
+
"body": {
|
|
47
|
+
"name": "Alice",
|
|
48
|
+
"age": 30
|
|
49
|
+
}
|
|
50
|
+
}
|
|
51
|
+
}
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
- **Constraint:** All `headers` keys MUST be normalized to lowercase.
|
|
55
|
+
- **Constraint:** If the `content-type` is `application/json`, the `body` MUST be parsed into a native object/dictionary before evaluation.
|
|
56
|
+
|
|
57
|
+
### 2.2. Standardized Telo Response Object (Output)
|
|
58
|
+
|
|
59
|
+
After the Handler executes and the `response.mapping` evaluates, the engine will return an object to the HTTP module. The module must map this directly to the native HTTP response.
|
|
60
|
+
|
|
61
|
+
```json
|
|
62
|
+
{
|
|
63
|
+
"status": 200,
|
|
64
|
+
"headers": {
|
|
65
|
+
"x-telo-runtime": "0.1.0",
|
|
66
|
+
"content-type": "application/json"
|
|
67
|
+
},
|
|
68
|
+
"body": {
|
|
69
|
+
"id": "123",
|
|
70
|
+
"status": "created"
|
|
71
|
+
}
|
|
72
|
+
}
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
## 3. Validation & Error Handling Contract
|
|
78
|
+
|
|
79
|
+
When a request fails schema validation (defined in the `request.schema` of the manifest), the underlying engine (e.g., AJV in Fastify) will generate native errors. **These internal errors must not leak to the client.**
|
|
80
|
+
|
|
81
|
+
All Telo HTTP modules MUST intercept framework-specific validation errors and return a standardized HTTP 400 Bad Request payload.
|
|
82
|
+
|
|
83
|
+
### Standardized Validation Error Format
|
|
84
|
+
|
|
85
|
+
The response body must strictly follow this JSON structure:
|
|
86
|
+
|
|
87
|
+
```json
|
|
88
|
+
{
|
|
89
|
+
"error": "ValidationError",
|
|
90
|
+
"message": "Request validation failed",
|
|
91
|
+
"status": 400,
|
|
92
|
+
"details": [
|
|
93
|
+
{
|
|
94
|
+
"location": "body",
|
|
95
|
+
"path": "user.age",
|
|
96
|
+
"message": "must be an integer"
|
|
97
|
+
},
|
|
98
|
+
{
|
|
99
|
+
"location": "query",
|
|
100
|
+
"path": "active",
|
|
101
|
+
"message": "is a required property"
|
|
102
|
+
}
|
|
103
|
+
]
|
|
104
|
+
}
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
- **`location` enum:** `body` | `query` | `params` | `headers`
|
|
108
|
+
- **Module Responsibility:** The module author must write an error handler/mapper that transforms the native framework's validation output into the Telo `details` array.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## 4. Manifest Schema Upgrades
|
|
113
|
+
|
|
114
|
+
To fully support this contract, the `Http.Api` JSON Schema definition includes the following structural definitions for the `request` block:
|
|
115
|
+
|
|
116
|
+
```yaml
|
|
117
|
+
request:
|
|
118
|
+
type: "object"
|
|
119
|
+
properties:
|
|
120
|
+
path:
|
|
121
|
+
type: "string"
|
|
122
|
+
description: "Must use OpenAPI style path parameters, e.g., /users/{id}"
|
|
123
|
+
method:
|
|
124
|
+
type: "string"
|
|
125
|
+
enum: ["GET", "POST", "PUT", "DELETE", "PATCH", "HEAD", "OPTIONS"]
|
|
126
|
+
consumes:
|
|
127
|
+
type: "array"
|
|
128
|
+
items: { type: "string" }
|
|
129
|
+
default: ["application/json"]
|
|
130
|
+
produces:
|
|
131
|
+
type: "array"
|
|
132
|
+
items: { type: "string" }
|
|
133
|
+
default: ["application/json"]
|
|
134
|
+
schema:
|
|
135
|
+
type: "object"
|
|
136
|
+
properties:
|
|
137
|
+
params:
|
|
138
|
+
type: "object"
|
|
139
|
+
description: "Validation schema for path parameters"
|
|
140
|
+
query:
|
|
141
|
+
type: "object"
|
|
142
|
+
description: "Validation schema for query string parameters"
|
|
143
|
+
headers:
|
|
144
|
+
type: "object"
|
|
145
|
+
description: "Validation schema for HTTP headers"
|
|
146
|
+
body:
|
|
147
|
+
type: "object"
|
|
148
|
+
description: "Validation schema for the request payload"
|
|
149
|
+
required: ["path", "method"]
|
|
150
|
+
```
|
package/package.json
CHANGED
|
@@ -1,6 +1,25 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@telorun/http-server",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.8",
|
|
4
|
+
"description": "Telo HTTP Server module - HTTP server and API resource kinds for Telo manifests.",
|
|
5
|
+
"keywords": [
|
|
6
|
+
"telo",
|
|
7
|
+
"http",
|
|
8
|
+
"server",
|
|
9
|
+
"api",
|
|
10
|
+
"fastify"
|
|
11
|
+
],
|
|
12
|
+
"author": "Bartosz Pasiński <bartosz.pasinski@codenet.pl>",
|
|
13
|
+
"license": "SEE LICENSE IN LICENSE",
|
|
14
|
+
"repository": {
|
|
15
|
+
"type": "git",
|
|
16
|
+
"url": "git+https://github.com/telorun/telo.git",
|
|
17
|
+
"directory": "modules/http-server/nodejs"
|
|
18
|
+
},
|
|
19
|
+
"homepage": "https://github.com/telorun/telo#readme",
|
|
20
|
+
"bugs": {
|
|
21
|
+
"url": "https://github.com/telorun/telo/issues"
|
|
22
|
+
},
|
|
4
23
|
"type": "module",
|
|
5
24
|
"main": "./dist/index.js",
|
|
6
25
|
"module": "./dist/index.js",
|
|
@@ -24,7 +43,7 @@
|
|
|
24
43
|
"ajv": "^8.17.1",
|
|
25
44
|
"ajv-formats": "^3.0.1",
|
|
26
45
|
"fastify": "^5.7.2",
|
|
27
|
-
"@telorun/sdk": "0.2.
|
|
46
|
+
"@telorun/sdk": "0.2.8"
|
|
28
47
|
},
|
|
29
48
|
"devDependencies": {
|
|
30
49
|
"@types/node": "^20.0.0",
|