Conversation
wgsadmin
left a comment
There was a problem hiding this comment.
Review finding:
- Should fix:
AssetAutocompleteResponse.predictionsis now required, but the property is still missing its array type, so generated docs/SDKs can continue treating it as untyped.
| required: | ||
| - predictions | ||
| properties: | ||
| predictions: |
There was a problem hiding this comment.
predictions is being made required, but the schema still does not declare it as an array. In OpenAPI 3.1/JSON Schema, items only constrains values that are already arrays; without type: array, validators and SDK generators can still treat this property as untyped, and the generated docs already show a blank Type column. Could we add type: array under predictions before items so clients get predictions[] correctly?
There was a problem hiding this comment.
Done in f598151. A bare type: array makes the doc generator fail on inline object items, so the item moved to a new AssetAutocompletePrediction schema and predictions is now type: array with items: $ref. The generated docs show Array<AssetAutocompletePrediction>.
What?
Aligns the Stores response schemas and query parameters with what the Stores API returns and accepts. Closes #84.
Responses: marks the always-returned fields as
required, typesuser_propertiesas a non-null object, makes the address fields nullable, addslocalized_namestoAssetResponse, and makesnext_openingnullable withall-day(itsstart/enddescriptions were swapped).Parameters: renames
encoded_polylinetopolyline, the name the API reads, addsboundsto/stores/search, declares the defaults, allowsoffset=0on/zones, and documents thatlat/lnggo together, thatpolylineneedsradius, and that autocomplete withoutqueryreturns no predictions.Why?
The API reference is generated from this spec, and
llms-rules.txttells agents it is authoritative for required flags and parameters. A client following it today sendsencoded_polyline, which the API ignores, and treatsstore_idornameas optional. Making fields required tightens the types of SDKs generated from the spec, so MapsJS, the Native SDK and the plugins need a heads-up.How to test
npm run build && npm test.dist/merged-woosmap-openapi3.jsonanddist/woosmap-postman.jsonare left to the release, which regenerates them.