Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SergioBenitez opened this issue Jul 15, 2016 · 11 comments
Labels
declined A declined request or suggestion enhancement A minor feature request feedback wanted User feedback is needed

Comments

@SergioBenitez
Copy link
Member

SergioBenitez commented Jul 15, 2016

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

#[route(PUT, POST, DELETE, GET, path = "...")]
@SergioBenitez
Copy link
Member Author

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

@SergioBenitez
Copy link
Member Author

SergioBenitez commented Sep 12, 2016

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 SergioBenitez added the enhancement A minor feature request label Sep 13, 2016
@SergioBenitez SergioBenitez added this to the 0.1.0 milestone Sep 13, 2016
@SergioBenitez SergioBenitez modified the milestones: 0.2.0, 0.1.0 Oct 12, 2016
@SergioBenitez
Copy link
Member Author

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 SergioBenitez removed this from the 0.2.0 milestone Jan 3, 2017
@SergioBenitez SergioBenitez added the feedback wanted User feedback is needed label Jan 3, 2017
@SergioBenitez
Copy link
Member Author

Pushing this to a decision by 0.4.

@kylone
Copy link

kylone commented Mar 7, 2017

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
Copy link
Contributor

mehcode commented Mar 7, 2017

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
Copy link
Contributor

lawliet89 commented Mar 9, 2017

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
Copy link

kylone commented Mar 14, 2017

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

@echochamber
Copy link

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
Copy link
Member Author

Pushing into the future.

@SergioBenitez SergioBenitez modified the milestones: 0.7.0, 0.4.0 Sep 7, 2017
@SergioBenitez SergioBenitez added the declined A declined request or suggestion label Feb 16, 2020
@SergioBenitez
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
declined A declined request or suggestion enhancement A minor feature request feedback wanted User feedback is needed
Projects
None yet
Development

No branches or pull requests

5 participants