enhancement: allow route decorator to declare multiple http verbs at once

[SergioBenitez]

IE, allow the following (in the extreme case):

#[route(PUT, POST, DELETE, GET, path = "...")]

[SergioBenitez]

Additionally, allow the same argument to be used as both the query and form parameters if GET and POST are both present.

[SergioBenitez]

A workaround can be to simply place multiple attributes on the function:

#[get("/?<form>")]
#[post("/", form = "<form>")]
fn my_form() {

}

This won't work at the moment, of course, because the generated items will have the same name.

[SergioBenitez]

I'd like some feedback from others to determine if this feature is indeed worthwhile. I haven't had a need for it, and it seems to only conflate code and ideas. But if someone has a good use-case, I'm all ears.

[SergioBenitez]

Pushing this to a decision by 0.4.

[kylone]

I haven't had much use for this default behavior in Asp.Net MVC. I typically want it to be obvious where a request will be routed. I feel that Get/Post on the same handler function is more hassle than it's worth.

[mehcode]

Routing both GET and POST to the same handler is very useful in a traditional web app that has a postback form.

An example in Flask (Python):

@app.route('/submit', methods=('GET', 'POST'))
def submit():
    form = MyForm()
    if form.validate_on_submit():
        return redirect('/success')
    return render_template('submit.html', form=form)

[lawliet89]

My use case, at the moment, is trying to implement CORS (before middleware support). I would like to have Options and Get (for example) to be handled by the same function so that I can handle the pre-flight and the actual requests without repeating some code.

[kylone]

Those sound like valid use cases. Is there anyone that thinks this is a bad idea?

[echochamber]

It sounds like valid use cases. I agree it can be used to conflate ideas and easily abused. I think best some sort best practices or warning in the docs would helpful at addressing that, at least partially (since the most likely candidates to abuse the feature are newer users, the people who likely to be reading the docs).

[SergioBenitez]

Pushing into the future.

[SergioBenitez]

Closing this as it seems unnecessary. Will revisit if requests call for it.