Lost *_with_http_info or *_without_preload_content methods in latest release

[bujasim]

Hi there, I have a question regarding #49.

The removal of the *_with_http_info or *_without_preload_content methods broke everything, was this intentional? Should we proceed with the assumption that such methods won't be available?

I ask because methods like user_service_add_human_user skip deserialization inside response_deserialize whenever the _response_types_map lacks a code, which in the case of that method if the user already exists you don't get the error message, which is why I ended up using the *_without_preload_content and parsing things myself (clunky but what to do, your library silently swallows the original response).

I don't mind losing the *_with_http_info or *_without_preload_content but at think something should be done about missing error codes.

Perhaps include 409 responses in the spec? I assume that would resolve the issue? Or change the library to avoid throwing away the original response data (which happens in response_deserialize).

I'm just making suggestions, you guys know better. Thanks for reading.

[mridang]

Hi @bujasim,

Thanks for reaching out and for your detailed feedback.

First, our apologies for the confusion caused by these changes. You're right, we should have done a better job of documenting these breaking changes, and we're sorry for the trouble this created.

As you noted, methods like _with_http_info were intentionally removed as part of a major redesign in our new 4.x.x releases. Our goal was to make the client library much simpler and more intuitive.

The new design now has one clear, public method for each API endpoint.

For example, creating a user is now as simple as calling the direct method:

client.user_service_add_human_user(body=create_user_request)

Could you please upgrade to the latest version (4.1.0-beta or newer)? This new, simpler approach should resolve the issue for you. I'll leave the issue open for now so we can continue the discussion.

Let us know if anything is unclear. We appreciate you helping us improve the library!

[bujasim]

Hi sorry I have been quite pre-occupied. I tested it out, but now the api calls seem to be trying to call the gRPC-Stub Path?

My requests using SDK all result in 404 Not Found errors. I checked the resource paths and they look like this:

        return self.api_client.param_serialize(
            method='POST',
            resource_path='/zitadel.user.v2.UserService/GetUserByID',

Seems we can't talk to public REST API using SDK anymore?

[mridang]

Hi @bujasim I'm sorry for the delay in circling back to you. With Zitadel 4.0, all these SDKs use ConnectRPC to communicate. Of course, the REST endpoints are still present but the SDKs use ConnectRPC now.

I'll close this issue for now, if you do run into any issues, please do open another issue. 🙏🏻