Help with a strange API

[SirVer]

I am trying to wrap createComment from the LaunchPad API - search for createComment on the page as the method has no direct link.

This looks like this in my code:

fn create_comment_by_url(&self, link: &str, subject: &str, content: &str) {
    POST("{}", link);
    fields! { 
        "ws.op" => "createComment",
        "subject" => subject,
        "content" => content
    }
}

With link being a merge_proposal.self_link.

This does work, however the API states:

On success, the response status will be 201 and the Location header will contain the link to the newly created code_review_comment.

I would like to expose this returned link in my API wrapper, but found no way of extracting a header from the response. Could you give me a hint?

[abonander]

Then you would use anterofit::net::RawResponse as your service method return type:

fn create_comment_by_url(&self, link: &str, subject: &str, content: &str) -> RawResponse {
    POST("{}", link);
    fields! { 
        "ws.op" => "createComment",
        "subject" => subject,
        "content" => content
    }
}

and then the response containing the headers is within.

If you have a type to decode and you also want to inspect the response, you can use anterofit::net::response::WithRaw, or anterofit::net::response::TryWithRaw if you want to inspect the response even if there was an error decoding the body.

[abonander]

However, if you want to abstract over this within the service definition alone, I don't really have anything for that yet. I've been conceptualizing a sort of map_response!{} macro, but I don't have a prototype for that yet.

[SirVer]

Thanks for your comments, that is really helpful. An example would have helped in the code base, since the WithRaw types are hard to find in the docs.

I take your last comment that you mean that a wrapper class to abstract the service a bit more idiomatic is required to hide the WithRaw handling. I agree it would be nice if such a wrapper was not needed, but frankly most returns from Web apis will require some sort of higher level abstraction anyways, so it does not hurt a lot.

[abonander]

The goal is to be able to abstract a lot of the weirdness inside the service definition but I'm not completely sure how I want to do that.