It happened to me that I had a resource with only GET request support, and Falcon forced me to define all types of routes e.g. POST, GET, PATCH, ... while that endpoint should only support GET request.
I wanted to propose an idea to add an extra parameter in route to get a restriction list of requests:
add_route("/users/{username}/", suffix="user_by_username", restriction=["GET", "HEAD", "OPTIONS"])
In this way, we don't force a resource to support all request types, and also it makes it easy to limit requests and it's clean to maintain because all "restrictions" are in one place and not in a resource on other places.
It was my idea, I've searched in the Issues list but I didn't find anything related to it. I'm not sure, but sorry if it's duplicated.
I want to know your idea and if you guys agree, I wish to send the PR related to it.
Hi :wave:,
Thanks for using Falcon. The large amount of time and effort needed to
maintain the project and develop new features is not sustainable without
the generous financial support of community members like you.
Please consider helping us secure the future of the Falcon framework with a
one-time or recurring donation.
Thank you for your support!
Hi @mortymacs !
I believe we would need more details what your definition of "supported" is :smiling_imp:
Falcon does not force you to define responders for all HTTP methods. Instead, other methods (that you have not explicitly defined) would simply use the default responder. The default responder would just say HTTP 405 Method Not Allowed, and would tell the user which methods are allowed (via the Allow header).
To illustrate, using QuoteResource from our frontpage example gives:
$ http PATCH http://localhost:8000/quote
HTTP/1.1 405 Method Not Allowed
Connection: close
Date: Sun, 06 Dec 2020 14:44:11 GMT
Server: gunicorn/19.9.0
allow: GET, OPTIONS
content-length: 0
content-type: application/json
According to your suggestion, what type of response should the framework render for methods that are not included in the restriction?
@mortymacs adding to my previous answer above, how does your suggestion compare to https://github.com/falconry/falcon/issues/555?
Hi @vytas7 :)
Thanks for the quick response.
Sorry, I was wrong in:
Falcon forced me to define all types of routes
And about issue #555 , yes, it was somehow what I expected to have, but it's not necessarily needed as you mentioned I can easily define methods that I need by on_* and others which are not defined will be Method Not Allowed.
Thanks :+1:
Yeah, #555 is only relevant when you are subclassing 3rd party (or even your own, for that matter) resources, and want to cleanly disable their handlers for certain HTTP verbs (without needing to resort to delattrs in the initializer, on_patch = on_lock = on_trace = my_default_responder or similar workarounds).
Glad to hear you sorted this out. Don't hesitate to report any other issues you find in Falcon!
You are also very welcome to hang in our Gitter channels.