HTTP boundaries
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
Treat HTTP as a contract boundary
Section titled “Treat HTTP as a contract boundary”HTTP is an integration concern for Runtime development, but no public connector contract, endpoint syntax, or supported feature matrix is published. This page is a design checklist.
Receiving a request
Section titled “Receiving a request”Decide which methods and media types the service accepts. Define body-size limits, validation rules, authentication ownership, and the meaning of each response category. Do not make a successful acknowledgement promise more than the system has completed.
A request identifier should support diagnosis without carrying secrets or personal details. Headers forwarded downstream need an explicit allowlist; forwarding all headers can expose credentials or create confusing trust relationships.
Calling another service
Section titled “Calling another service”Distinguish connection establishment, response waiting, and the total integration time budget. Define maximum body sizes, redirect behavior, certificate verification, and destination restrictions. An integration that accepts arbitrary outbound destinations needs protection against requests to internal services.
| Outcome | Question to answer |
|---|---|
| Validation failure | Can the caller correct the request? |
| Rate limit | Is retry advice trustworthy and within the time budget? |
| Timeout | Could the remote side have already committed? |
| Redirect | Is forwarding credentials to the next host allowed? |
Keep evidence with the contract
Section titled “Keep evidence with the contract”A future connector reference must name supported methods, encodings, TLS behavior, timeout settings, header handling, and error mapping, with release-specific tests. Until then, there are no executable Runtime HTTP examples to copy.
See errors and retries before deciding which HTTP outcomes can be retried.