Replies: 2 comments 1 reply
|
can you send me your documents to hans@scalar.com? I want to make sure they work well |
0 replies
|
Thanks! PRs incoming: |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Support requestBody examples using OpenAPI
externalValueProblem
OpenAPI already provides
externalValueon an Example Object for examples that are stored externally instead of being embedded in the OpenAPI document.For APIs with hundreds or thousands of request examples, embedding every payload directly into the OpenAPI document unnecessarily increases document size, generation time, transfer size and parsing time.
Instead, the OpenAPI document can reference externally stored examples.
Example:
The referenced endpoint simply returns the serialized JSON request:
{ "shippingType": "Shipper_001", "packages": [ ... ] }This keeps the OpenAPI document small while allowing the full payload to be retrieved only when needed.
Current behavior
The native example selector displays examples correctly.
However, selecting an example does not appear to resolve
externalValuefor request examples.As a result:
The endpoint itself is reachable and returns the expected JSON.
Current workaround
We currently solve this by adding a small JavaScript integration which:
externalValueThis works, but it requires accessing internal implementation details such as the WorkspaceStore and CodeMirror editor.
Proposal
When a request example contains
externalValue, Scalar could resolve it lazily when the example becomes active.Conceptually:
externalValue.Only the selected example would be downloaded.
Previously selected examples could optionally be cached.
Benefits
This would allow API authors to:
Additional context
One of our APIs currently exposes more than 1,200 request examples, with time up to 12000 request examples.
Using
externalValuereduces the OpenAPI document considerably while remaining standards-compliant.Supporting
externalValueend-to-end would provide a standards-based solution that should also benefit integrations beyond ours.All reactions