From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>
Cc: Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>
Subject: Re: [pdm-devel] Howto access raw response data with pdm-client
Date: Thu, 16 Oct 2025 11:03:05 +0200 [thread overview]
Message-ID: <zs7za7bcmlpdlei5bkipscjc53evfzjzd2z4rhm52atoo3gugl@3sfsedqo6y7y> (raw)
In-Reply-To: <bf85250e-7089-43b1-8a47-0c2842485612@proxmox.com>
On Thu, Oct 16, 2025 at 10:50:41AM +0200, Dominik Csapak wrote:
>
>
> On 10/16/25 10:27 AM, Wolfgang Bumiller wrote:
> > On Thu, Oct 16, 2025 at 10:10:58AM +0200, Dominik Csapak wrote:
> > >
> > >
> > > On 10/15/25 6:06 PM, Dietmar Maurer wrote:
> > > > We currently use proxmox-yew-comp::ApiLoadCallback for many widgets.
> > > >
> > > > This callback returns Result<ApiResponseData<T>, Error>, and
> > > > we use it most times with Result<ApiResponseData<Value>, Error> to access
> > > > raw response data.
> > > >
> > > > Is there a way to get that data using pdm-client?
> >
> > I'm a bit confused as to what "that data" is referring to. The client
> > does give you the above types, and they come from the intermediate
> > `HttpApiResponse` which has all-public fields including the `body:
> > Vec<u8>` if for some reason the `ApiResponseData` is not enough, but why
> > wouldn't it?
>
> ApiResponseData would be enough, but the client (at least the api calls
> we implemented at the moment) does not return that but rather the inner
> type, for example:
>
> ---
> pub async fn get_metric_collection_status(
> &self,
> ) -> Result<Vec<pdm_api_types::MetricCollectionStatus>, Error> {
> let path: &str = "/api2/extjs/metric-collection/status";
> Ok(self.0.get(path_and_query: path).await?.expect_json()?.data)
> }
> ---
>
> which is the pattern i see for (nearly?) all methods of the PdmClient
>
> >
> > > >
> > >
> > > after talking a bit off-list with dietmar, one solution to the problem
> > > could be to not use the statically typed methods but instead provide a
> > > method to generate the url and we use that + e.g. http_post/get/etc. to
> > > make api calls (which can convert the parameter with Serialize and the
> > > return type with Deserialize)
> > >
> > > with that we can also use `Value` if needed and can extract the auxiliary
> > > data from the api call too?
> >
> > Which auxiliary data ends up neither in `data` nor in `attribs`, and
> > more importantly: why? Sounds like something is circumventing the
> > response format we normally get from the formatter?
> > (And then we could just extend `ApiResponseData` to optionally include
> > it, or better yet, fix the API call?)
>
> see above, the question is basically:
>
> should we return ApiResponseData everywhere, or should we decide case by
> case, or ...
Depends on how often we need this, and whether it's specifically only
the attribs or more. If it's only a few cases, add it as-needed case by
case.
IMO the most straightforward would be to just make methods which can
contain important attributes return the typed `ApiResponseData<T>`.
Callers which don't care about the attributes just need to append a
`.data` to the call after all, that's kind of the point of the typed
`ApiResponseData<T>` in the first place ;-)
_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel
prev parent reply other threads:[~2025-10-16 9:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 16:06 Dietmar Maurer
2025-10-16 8:10 ` Dominik Csapak
2025-10-16 8:27 ` Wolfgang Bumiller
2025-10-16 8:50 ` Dominik Csapak
2025-10-16 9:03 ` Wolfgang Bumiller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=zs7za7bcmlpdlei5bkipscjc53evfzjzd2z4rhm52atoo3gugl@3sfsedqo6y7y \
--to=w.bumiller@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.