Sample Responses

[tomharmon]

Feature Request

Add ability to store sample responses for requests. I'm opening this issue to get feedback on how to implement before going ahead and doing it

Motivation

it's in the TODO and I want to contribute

Proposal

A possibility would be to update the RequestKind like so:

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct SampleResponse {
    #[serde(skip_serializing_if = "Option::is_none")]
    pub body: Option<String>,
    #[serde(skip_serializing_if = "IndexMap::is_empty")]
    pub headers: IndexMap<String, Vec<String>>,
    #[serde(skip_serializing_if = "Option::is_none")]
    pub cookies: Option<CookieStore>,
    #[serde(skip_serializing_if = "Option::is_none")]
    pub status: Option<u16>,
}

/// we store requests on a collection and on directories as a enum that could
/// be either an request or a directory. This enables us to have nested
/// directories, although we don't support that now and might not ever support.
///
/// Single means its a request
/// SingleWithSampleResp means its a request with a sample response
/// Nested means its a directory
#[derive(Debug, Serialize, Deserialize, Clone)]
#[serde(untagged)]
pub enum RequestKind {
    Single(Arc<RwLock<Request>>),
    SingleWithSampleResp {
        request: Arc<RwLock<Request>>,
        sample_response: SampleResponse,
    },
    Nested(Directory),
}

I was thinking that the TUI could show sample responses in the preview window. We could use some kind of icon next to preview to indicate that a sample response is available. Then the user could press a key to switch from regular Preview of an actual request to the sample response preview.

Preview (S *)
Pretty | Raw | Headers | Cookies

like this, where the * or something could indicate a sample response is present.

Alternatives

open to suggestions

[wllfaria]

Hey! I like your idea, I think we could avoid having a different RequestKind for sample responses by just having a vector or map of saved responses, which could also allow the user to save multiple responses, maybe a sample response per status.

Which could be useful in situations like, saving a success and errors, 401, 200, 400, things like that, what do you think?

maybe something like this:

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct Request {
    pub id: String,
    pub method: RequestMethod,
    pub uri: String,
    pub headers: Option<Vec<HeaderMap>>,
    pub auth_method: Option<AuthMethod>,
    pub parent: Option<String>,
    pub body: Option<String>,
    #[serde(rename = "bodyType")]
    pub body_type: Option<BodyType>,
    pub responses: HashMap<u16, SampleResponse>,
}

[tomharmon]

Nice. I feel like it makes sense to go with a Vec<SampleResponse> over a HashMap because I can imagine scenarios where you want to give examples of different response body formats even if they may return the same status code, e.g. any time someone is returning an enum.

I threw together a rough draft PR for this in #22 , but I'm very unfamiliar with writing TUI apps and ratatui in general so I was looking for a little more guidance on the right way to implement viewing these sample responses in the ResponseViewer. I assume we want to share most or all of the code for rendering an actual response vs a sample one.

I assume that if the Sample Response pane is selected then you would want it to essentially function as the Editor, so that you can update the sample responses in the TUI easily. I've not yet looked into how the Editor is implemented. I assume this will probably be straightforward.

Secondly I assume I need to add another kind of display menu when the Sample Response pane is selected so that we can choose a particular sample response from the collection, rename them, delete some, create a new one, etc.

[wllfaria]

I totally agree, it makes sense to not limit by a single response per status, i'll take a look at your PR and see where I can add some comments to maybe guide you through the implementation better. As of the TUI, this can be iterated, as most of the design for HAC is a WIP and can change.

I'll also try to give some guidance on how to make the sample responses editable, by having an editor there