Refine Inbound API: HTTP contract, extended types, logging, rate limiting
Define POST /api/{methodName} URL structure with X-API-Key header. Flat JSON
request/response with no envelope wrapper. Add extended type system (Object, List)
for complex API parameters and return values, applied to both Inbound API and
External System Gateway method definitions. Only failures logged; no rate limiting
in this controlled industrial environment.
This commit is contained in:
@@ -50,6 +50,61 @@ Each API method definition includes:
|
||||
- Managed by users with the **Design** role via the Central UI.
|
||||
- All method definition changes are audit logged.
|
||||
|
||||
## HTTP Contract
|
||||
|
||||
### URL Structure
|
||||
- All API calls use `POST /api/{methodName}`.
|
||||
- Method names map directly to URL path segments (e.g., method "GetProductionReport" → `POST /api/GetProductionReport`).
|
||||
- All calls are POST — these are RPC-style script invocations, not RESTful resource operations.
|
||||
|
||||
### API Key Header
|
||||
- API key is passed via the `X-API-Key` HTTP header.
|
||||
|
||||
### Request Format
|
||||
- Content-Type: `application/json`.
|
||||
- Parameters are top-level JSON fields in the request body matching the method's parameter definitions:
|
||||
```json
|
||||
{
|
||||
"siteId": "SiteA",
|
||||
"startDate": "2026-03-01",
|
||||
"endDate": "2026-03-16"
|
||||
}
|
||||
```
|
||||
|
||||
### Response Format
|
||||
- **Success (200)**: The response body is the method's return value as JSON, with fields matching the return value definition:
|
||||
```json
|
||||
{
|
||||
"siteName": "Site Alpha",
|
||||
"totalUnits": 14250,
|
||||
"lines": [
|
||||
{ "lineName": "Line-1", "units": 8200, "efficiency": 92.5 },
|
||||
{ "lineName": "Line-2", "units": 6050, "efficiency": 88.1 }
|
||||
]
|
||||
}
|
||||
```
|
||||
- **Failure (4xx/5xx)**: The response body is an error object:
|
||||
```json
|
||||
{
|
||||
"error": "Site unreachable",
|
||||
"code": "SITE_UNREACHABLE"
|
||||
}
|
||||
```
|
||||
- HTTP status codes distinguish success from failure — no envelope wrapper.
|
||||
|
||||
### Extended Type System
|
||||
- API method parameter and return type definitions support an **extended type system** beyond the four template attribute types (Boolean, Integer, Float, String):
|
||||
- **Object**: A named structure with typed fields. Supports nesting.
|
||||
- **List**: An ordered collection of objects or primitive types.
|
||||
- This allows complex request/response structures (e.g., an object containing properties and a list of nested objects).
|
||||
- Template attributes retain the simpler four-type system. The extended types apply only to Inbound API method definitions and External System Gateway method definitions.
|
||||
|
||||
## API Call Logging
|
||||
|
||||
- **Only failures are logged.** Script execution errors (500 responses) are logged centrally.
|
||||
- Successful API calls are **not** logged — the audit log is reserved for configuration changes, not operational traffic.
|
||||
- No rate limiting — this is a private API in a controlled industrial environment with a known set of callers. Misbehaving callers are handled operationally (disable the API key).
|
||||
|
||||
## Request Flow
|
||||
|
||||
```
|
||||
@@ -96,7 +151,7 @@ Inbound API scripts **cannot** call shared scripts directly — shared scripts a
|
||||
|
||||
## Authentication Details
|
||||
|
||||
- API key is passed in the request (e.g., via HTTP header such as `X-API-Key`).
|
||||
- API key is passed via the `X-API-Key` HTTP header.
|
||||
- The system validates:
|
||||
1. The key exists in the configuration database.
|
||||
2. The key is enabled.
|
||||
|
||||
Reference in New Issue
Block a user