This is a really good point. The generated SDK is configured to allow a super-set of the API request body to hit the backend, which could expose unnecessary data fields if passed in by client code.
It comes because we’re a bit pragmatic: if a user doesn’t specify their full data structure in their OpenAPI specification, and we can’t generate a strict type, we allow an arbitrary structure to reach the backend. In our experience the hard bit isn’t really writing the SDK, it’s making and maintaining a good OpenAPI spec (hence part of the commercial product we’re moving towards is the ability to generate a strict OpenAPI specification directly from handler code / traffic analysis in a backend server). Your concern is totally valid, and this is something we will make configurable.
Comments
This is a really good point. The generated SDK is configured to allow a super-set of the API request body to hit the backend, which could expose unnecessary data fields if passed in by client code.
It comes because we’re a bit pragmatic: if a user doesn’t specify their full data structure in their OpenAPI specification, and we can’t generate a strict type, we allow an arbitrary structure to reach the backend. In our experience the hard bit isn’t really writing the SDK, it’s making and maintaining a good OpenAPI spec (hence part of the commercial product we’re moving towards is the ability to generate a strict OpenAPI specification directly from handler code / traffic analysis in a backend server). Your concern is totally valid, and this is something we will make configurable.