-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Required Properties #7
Comments
Thanks for the issue! Starting with 2., definitely makes sense to include the required/optional information from the api reference description, and this whole project is built on many quirks/hacks so that is 100% OK. For 1., I know there are some times when the API doesn't return certain fields. Off the top of my head I can think of |
Makes sense, thanks! Up to you whether you want to close this, not much we can do about optional dto responses |
I'm taking a second look at this, I intend on actually manually going through to figure out which fields may be null. |
Non-required fields: (to be updated as I find more) DTOs
|
I've implemented a hardcoded list of optional/required fields that now gets included in the created schema. DTO's now have the |
Hey!
Thank you for this project as usual. I would like to talk about adding required model properties to two cases:
summoner-v4.SummonerDTO
)tournament-v4.TournamentCodeParameters
)https://docs.swagger.io/spec.html
The reasoning is that it allows one to generate types using sw2dts, for example.
For the first case,
Do you think it would be wise to trust that all Riot League of Legend's model DTO's to always have the properties (required properties as defined by Swagger).
So for example, SummonerDTO
These fields should always exist, and so we can define them in the SwaggerSpec like so:
The second case is a bit weird and really only applies to the models that are used as parameters, such as
tournament-v4.TournamentCodeParameters
.In this case, I noticed that Riot doesn't really have a column to mention that something is optional, and instead places it in the description text. And so in my code, I just have something that checks for "optional" basically.
I've already coded the stuffs required to handle both cases, but it basically makes the above assumptions and is therefore hacky. Is it something safe enough to add? :O If not, I can just maintain it in a fork and keep testing.
The text was updated successfully, but these errors were encountered: