Skip to content

Tidy Policy per Status Code #94

Description

@jonthegeek

TICKET STILL IN PROGRESS. CAPTURING MY THOUGHTS BUT NOT YET ASSIGNABLE.

Summary

As a maintainer of an API-wrapping package, I'd like to configure response parsers per status code, so that I can handle responses exactly as described in an API definition.

Details

Update req_tidy_policy(), .as_nectar_tidy_policy(), etc to accept a list of tidy policies for tidy_policy argument, named by status code. By default, if the tidy_policy is not a list, assume that it is a policy for status code "200" (ie, if the tidy_policy arg is x, treat it as if it's list(`200` = x)). The names can be a specific status code ("200", "400", etc), or a range of status codes ("2xx", "4xx", etc).

Add a helper for req_error() body argument. That's a function(resp), so apply that function if we have parsers for 400+. Split the req_error() stuff into a separate ticket, get that worked out, THEN implement this.

resp_parse() should do something with error responses, too. And req_perform_opinionated() should probably have an on_error arg to pass on to httr2::req_perform_iterative(), and that will impact how/whether we deal with errors in resp_parse().

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions