Generated OpenAPI doc uses snake_case: support for subset of serde attributes (rename_all, skip)

[clearydude]

I've noticed that the generated open API docs component fields don't seem to respect set serde rules -- namely rust conventions use snake_case while JSON uses camelCase.
Normally I've had to add a serde attribute (#[serde(rename_all = "camelCase")]) to rename these when converting between the two. I have these added to my components currently but the generated code is still snake case.
Is there some option I can set so that the generated code will be in camel case format? Thanks!

[juhaku]

Yeah.. Actually support for this hasn't been yet implemented. This is something that still need to be addressed in future releases. Currently it indeed bluntly uses snake_case.

[juhaku]

As what comes to this case feature. I plan to add support to skip fields from serializing to the api doc? It could also be done with that #[serde(skip)] attribute. Is that something you think would be useful?

Also about the rename thing. Yes I guess typically camelCase is involved with the JSON but I guess it mostly depends on with what langauge the actual API's writen and I guess the habits derive from there. Like with Java, JavaScript, TypeScript its indeed most of the time camelCase and with Go it can be PascalCase or camelCase depending whether people really see the trouble to rename manually all the fields. And I gues python goes with the snake_case as well, not sure though.

But ability to support different cases. It should be quite easy to add support for #[serde(rename_all = "...")] at Component level. But it might look jarring if path parameters where in snake_case and other content would be camelCase? For example in actix-web path parameters are defined within macro #[get("/user/{user_id}")] which assumes there is variable user_id within path. And if this was also to be renamed to camelCase the the path should be written like this #[get("/user/{userId}")] and it would definitely alarm somebody about the style.

[juhaku]

Closing this issue, since there has not been any activity for a while.