Skip to content
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

Non-typed return values for a few of your api calls #41

Open
rasharab opened this issue Jul 15, 2022 · 4 comments
Open

Non-typed return values for a few of your api calls #41

rasharab opened this issue Jul 15, 2022 · 4 comments

Comments

@rasharab
Copy link

rasharab commented Jul 15, 2022

i.e.

public class GetFolders {
  @SerializedName("folders")
  private List<Object> folders = null;

  public GetFolders folders(List<Object> folders) {
    this.folders = folders;
    return this;
  }

i.e.

public class GetFolderLists {
  @SerializedName("lists")
  private List<Object> lists = null;

  public GetFolderLists lists(List<Object> lists) {
    this.lists = lists;
    return this;
  }

Your openspec apis also are not providing any properly types response objects for GetFolders, GetLists etc.

Is there a reason for this?

@Kool-Hussain
Copy link
Contributor

Hi @rasharab,
This is an auto-generated code using swagger-codegen. For better documentation and readability you can always refer to our API documentation given here:
https://developers.sendinblue.com/reference/getfolders-1
https://developers.sendinblue.com/reference/getfolderlists-1
Thanks!

@rasharab
Copy link
Author

rasharab commented Jan 12, 2023

We use openapi code generation tools as well and outside of possibly how you've typed the aforementioned fields in your spec, it's surprising that it's being translated to the Object type.

The larger point is that it makes end users lives more difficult as we're dealing with non-typed objects.

@oxygenecore
Copy link

oxygenecore commented Jul 2, 2024

SDK which does not allow you to use it, somewhat kills the purpose of having SDK in the first place.
What is the suggested solution? Should we cast to internal Gson classes and freeze the Gson dependency version in the build tool?

@oxygenecore
Copy link

Currently, I hope that the model classes are still properly generated according to actual schema, and use this ad-hoc method to convert each object to the "proper" type (which I only assume from class name):
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants