Support multiple status codes and schemas with responds

Currently, only a single responds decorator may be provided, optionally with a status_code. Support for multiple schemas corresponding to different status codes would be straightforward to implement by inspecting the return type and mapping the status_code to the schema, if it is available.

The current functionality for ignoring pre-made Flask Responses would need to be modified to only ignore those for which it does not have a corresponding Schema.

The status code of the response can come from any of the normal Flask means (i.e. as a data, code, headers tuple, via make_response, etc)

[apogiatzis]

Firstly thanks for this handy package!

That would be a really nice feature! If I find some spare time I will try to open a PR for this

For the time being here is my workaround in case you want to achieve this with Marshmallow schemas:

@ns.route("/testroute")
class TestResource(Resource):
    """Testing Endpoint"""

    @ns.response(200, "Success", for_swagger(model_schema, ns))
    @ns.response(404, "NotFound",for_swagger(error_schema, ns))
    def get(self):
        """Return something"""
        .....
        return obj

where ns is the Namespace or Api, and the schemas are Marshmallow schemas

[apryor6]

Hi!

I agree with the premise that we don’t want to break backwards compatibility. Beyond that, a proposal that provides something like a dict mapping of status codes to associated schemas would seem solid. The decorator code can check for this argument or the type of the argument and react accordingly. This seems straightforward and prevents any need for stacking decorators. To extend an existing responds decorator, simply convert the single params to a dict of status_code:schema.

I’d happily review a tested PR and cut a release, but candidly the likelihood that I can find time to address this any time soon is very small.

-AJ

Sent from my iPhone

On Oct 27, 2020, at 6:55 AM, Peter Volf [e-mail] wrote:

There is no standard for building REST APIs, it’s an API implementation style that uses HTTP methods to communicate semantics. Everything you put on top of this (like PUT must respond with different status codes whether an object was created or updated) is up to you. I actually prefer a simple API style like this (notice the author), but this is also just a preference.

I would argue that in Flask make_response is the standard, but returning simply the result (or maybe an extra status code) is enough in most cases so the devs were kind/smart and added it as a convenience feature for users. You’re also making the assumption that flask-accepts is (or will be) following semantic versioning, which may not be true.

Anyway, we’ve moved to subjective topics, so I’m closing this on my part. Actually the only reason I commented was because not long ago another breaking, not perfectly implemented PR ( #80 ) was accepted here that had to be later reverted, and I would like a solution that doesn’t cause trouble for the existing users of this excellent project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.