Conversation
Eventually we could add HTTP resources at this level but HTTP operations doesn't look useful
- add import model and resolver to load consumes adapters from external files - resolve imported consumes entries during capability initialization - support standalone root-level consumes documents in spec model - add custom consumes deserialization for inline vs imported entries - add unit and integration tests for deserialization, resolver behavior, aliases, and error cases - add tutorial step 7 example for consumes import and shared consumes file - update tutorial schema headers to use unified Naftiko schema
|
@eskenazit I've added the implementation to this PR to streamline the review process. I have only left out the "operations" surcharge feature for now. |
| inputParameters: | ||
| - name: "name" | ||
| in: "query" | ||
| value: "${name}" |
There was a problem hiding this comment.
I am not sure there should be a value here since the parameter is in the query. Plus syntax is not mustache ^^'
| outputParameters: | ||
| - name: "message" | ||
| type: "string" | ||
| value: "$.message" |
There was a problem hiding this comment.
missing mustache templating
| name: "${name}" | ||
| outputParameters: | ||
| - type: "string" | ||
| mapping: "$.message" |
There was a problem hiding this comment.
either missing parameter name or wrong type
| // Should not throw | ||
| resolver.resolveImports(null, tempDir.toString()); | ||
| } | ||
| } |
There was a problem hiding this comment.
Should we add a test with a import namespace collision to ensure there is a detection and proper error management ?
|
@jlouvel since this is my own PR, I cannot approve or request for changes for your submissions. Let us discuss this in the retrospective to have a proper process in this case =) |
2 participants
added consumes import support and made some chore cleaning