|
14 | 14 | - Technically the OAS allows for parts of a spec to be in separate files, but this isn't supported yet. |
15 | 15 | - `[--output-dir <output dir>]`: The directory to output to. Defaults to `generated/`. |
16 | 16 | - `[--module-name <module name>]`: The Elm module name. Default to `<OAS info.title>`. |
| 17 | +- `[--response-version-header <header name>]`: Expose a response version header through `OpenApi.Common.responseVersionFromError`. |
| 18 | + - If passed without a value, defaults to `OpenAPI-Hash`. |
| 19 | + - This lets your app forward the server's response version to JavaScript or a port. |
| 20 | + - Comparison, storage, and reload behavior stay in your application code. |
17 | 21 | - `[--auto-convert-swagger]`: If passed in, and a Swagger doc is encountered, will attempt to convert it to an Open API file. If not passed in, and a Swagger doc is encountered, the user will be manually prompted to convert. |
18 | 22 | - `[--swagger-conversion-url]`: The URL to use to convert a Swagger doc to an Open API file. Defaults to `https://converter.swagger.io/api/convert`. |
19 | 23 | - `[--swagger-conversion-command]`: Instead of making an HTTP request to convert from Swagger to Open API, use this command. |
|
22 | 26 | - `[--overrides <file path>]`: Load an additional file to override parts of the original Open API file. |
23 | 27 | - This is most commonly used for malformed OAS files (e.g. missing `required` on a required field) but can be used for anything you want |
24 | 28 | - `[--write-merged-to <file path>]`: Write the merged Open API spec to the given file (see `--overrides` for merging). |
| 29 | + |
| 30 | +## Working with response versions |
| 31 | + |
| 32 | +If your backend includes a response header like `OpenAPI-Hash`, you can ask the generator to expose that header through generated `OpenApi.Common` helpers: |
| 33 | + |
| 34 | +```sh |
| 35 | +npx elm-open-api ./my-cool-company-oas.json --response-version-header OpenAPI-Hash |
| 36 | +``` |
| 37 | + |
| 38 | +When enabled, the generated `OpenApi.Common` module includes: |
| 39 | + |
| 40 | +- `type alias ResponseVersion = { headerName : String, responseVersion : String }` |
| 41 | +- `responseVersionFromError : Error err body -> Maybe ResponseVersion` |
| 42 | + |
| 43 | +This helper extracts the configured response version header from generated API errors that include response metadata, such as `BadBody`, `BadErrorBody`, and `UnknownBadStatus`. |
| 44 | + |
| 45 | +Use this when you want your application to observe the response version itself, typically by forwarding the observed value to JavaScript, a port, or shared app state. |
| 46 | + |
| 47 | +### Generic app setup |
| 48 | + |
| 49 | +1. Enable the feature with `--response-version-header` or just `--response-version-header` to use the default `OpenAPI-Hash`. |
| 50 | +2. Route generated API errors through one shared error handler. |
| 51 | +3. In that shared handler, call `OpenApi.Common.responseVersionFromError`. |
| 52 | +4. When it returns `Just responseVersion`, forward that value to JavaScript, a port, or shared app state. |
| 53 | +5. Handle that forwarded value however your application needs. |
| 54 | + |
| 55 | +Example shared handling: |
| 56 | + |
| 57 | +```elm |
| 58 | +case result of |
| 59 | + Err err -> |
| 60 | + case OpenApi.Common.responseVersionFromError err of |
| 61 | + Just responseVersion -> |
| 62 | + forwardObservedResponseVersion err responseVersion |
| 63 | + |
| 64 | + Nothing -> |
| 65 | + handleNormalApiError err |
| 66 | + |
| 67 | + Ok value -> |
| 68 | + handleSuccess value |
| 69 | +``` |
| 70 | + |
| 71 | +Notes: |
| 72 | + |
| 73 | +- This only exposes response versions from generated API errors that include response metadata. |
| 74 | +- If you need to inspect the header on every successful response too, use a JavaScript interceptor instead. |
| 75 | +- The generated SDK only exposes the observed response version. Any follow-up behavior is app-owned. |
| 76 | +- For cross-origin APIs, your backend must expose the response version header through CORS. |
| 77 | + |
| 78 | +### Elm Land |
| 79 | + |
| 80 | +Elm Land is a good fit for this feature when you already use a customized `Effect.elm` and `src/interop.js` for JavaScript interop. |
| 81 | + |
| 82 | +Use this flow when: |
| 83 | + |
| 84 | +- you want one shared application-level place to observe response versions from generated API errors |
| 85 | +- you want JavaScript or ports to receive that observed value |
| 86 | +- you do not want to thread extra config through every generated API call |
| 87 | + |
| 88 | +#### 1. Enable the generator flag |
| 89 | + |
| 90 | +```sh |
| 91 | +npx elm-open-api ./my-cool-company-oas.json --response-version-header OpenAPI-Hash |
| 92 | +``` |
| 93 | + |
| 94 | +#### 2. Customize `Effect.elm` |
| 95 | + |
| 96 | +If you have not already customized it: |
| 97 | + |
| 98 | +```sh |
| 99 | +elm-land customize effect |
| 100 | +``` |
| 101 | + |
| 102 | +Then add an effect that forwards the observed response version to JavaScript. |
| 103 | + |
| 104 | +Example `src/Effect.elm`: |
| 105 | + |
| 106 | +```elm |
| 107 | +port module Effect exposing |
| 108 | + ( Effect |
| 109 | + , none |
| 110 | + , map |
| 111 | + , toCmd |
| 112 | + , reportResponseVersion |
| 113 | + ) |
| 114 | + |
| 115 | +import Json.Encode |
| 116 | + |
| 117 | +type Effect msg |
| 118 | + = None |
| 119 | + | SendMessageToJavaScript |
| 120 | + { tag : String |
| 121 | + , data : Json.Encode.Value |
| 122 | + } |
| 123 | + |
| 124 | +port outgoing : { tag : String, data : Json.Encode.Value } -> Cmd msg |
| 125 | + |
| 126 | +none : Effect msg |
| 127 | +none = |
| 128 | + None |
| 129 | + |
| 130 | +reportResponseVersion : |
| 131 | + { headerName : String, responseVersion : String } |
| 132 | + -> Effect msg |
| 133 | +reportResponseVersion payload = |
| 134 | + SendMessageToJavaScript |
| 135 | + { tag = "REPORT_RESPONSE_VERSION" |
| 136 | + , data = |
| 137 | + Json.Encode.object |
| 138 | + [ ( "headerName", Json.Encode.string payload.headerName ) |
| 139 | + , ( "responseVersion", Json.Encode.string payload.responseVersion ) |
| 140 | + ] |
| 141 | + } |
| 142 | + |
| 143 | +map : (msg1 -> msg2) -> Effect msg1 -> Effect msg2 |
| 144 | +map _ effect = |
| 145 | + case effect of |
| 146 | + None -> |
| 147 | + None |
| 148 | + |
| 149 | + SendMessageToJavaScript message -> |
| 150 | + SendMessageToJavaScript message |
| 151 | + |
| 152 | +toCmd : Effect msg -> Cmd msg |
| 153 | +toCmd effect = |
| 154 | + case effect of |
| 155 | + None -> |
| 156 | + Cmd.none |
| 157 | + |
| 158 | + SendMessageToJavaScript message -> |
| 159 | + outgoing message |
| 160 | +``` |
| 161 | + |
| 162 | +#### 3. Handle generated API errors in one shared place |
| 163 | + |
| 164 | +Use `OpenApi.Common.responseVersionFromError` inside your shared request result handler: |
| 165 | + |
| 166 | +```elm |
| 167 | +case result of |
| 168 | + Err err -> |
| 169 | + case OpenApi.Common.responseVersionFromError err of |
| 170 | + Just responseVersion -> |
| 171 | + ( model |
| 172 | + , Effect.reportResponseVersion |
| 173 | + { headerName = responseVersion.headerName |
| 174 | + , responseVersion = responseVersion.responseVersion |
| 175 | + } |
| 176 | + ) |
| 177 | + |
| 178 | + Nothing -> |
| 179 | + handleNormalApiError model err |
| 180 | + |
| 181 | + Ok value -> |
| 182 | + handleSuccess model value |
| 183 | +``` |
| 184 | + |
| 185 | +This becomes app-global when all generated API errors are funneled through one shared handler. It is not an implicit interceptor. |
| 186 | + |
| 187 | +#### 4. Receive the forwarded version in `src/interop.js` |
| 188 | + |
| 189 | +The generator stops at `OpenApi.Common.responseVersionFromError`. The app decides what, if anything, should happen next. |
| 190 | + |
| 191 | +Example `src/interop.js`: |
| 192 | + |
| 193 | +```js |
| 194 | +export const onReady = ({ app }) => { |
| 195 | + if (!app.ports || !app.ports.outgoing) return |
| 196 | + |
| 197 | + app.ports.outgoing.subscribe(({ tag, data }) => { |
| 198 | + if (tag !== 'REPORT_RESPONSE_VERSION') return |
| 199 | + |
| 200 | + handleObservedResponseVersion(data) |
| 201 | + }) |
| 202 | +} |
| 203 | +``` |
| 204 | + |
| 205 | +Here `handleObservedResponseVersion` is application code. It might store the value, compare it, log it, or ignore it. That behavior is not generated by `elm-open-api`. |
| 206 | + |
| 207 | +#### 5. Important caveats |
| 208 | + |
| 209 | +- This flow reacts to generated API errors with response metadata, not every successful response. |
| 210 | +- If your users frequently keep tabs open for a long time and you need detection on every response, prefer a JavaScript interceptor. |
| 211 | +- For cross-origin APIs, make sure the response version header is exposed to the browser via CORS. |
25 | 212 | ## Example outputs: |
26 | 213 |
|
27 | 214 | Assume we have an OAS file named `my-cool-company-oas.json` and it has a field `"title": "My Coool Company"` and we run the CLI like so |
|
0 commit comments