-
Notifications
You must be signed in to change notification settings - Fork 140
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
When using $RESOURCES
as routes, a malformed DELETE
(missing an ID) will result in a mismatching action
#392
Comments
I've created an example app displaying this behavior: https://github.com/mjhagen/SSCCE/tree/master/fw1-392 |
👍 |
A possible solution here is to allow per-resource error handling. You can try this by setting the resource template in you configuration: copy the framework default and add a line that has a method of "error" and matches the http method "$*". This will route anything that "almost matches" to /api:myObject/error so you can do better handling. I think I'll add a perResourceError flag to enable this in core. How does that sound? I could just add that as the default and let folks who want the old behavior set it false I guess. This is a 4.0 release after all. |
Add perResourceError config (default true -- breaking change!) that adds a $* match for HTTP method and an error handler per-resource.
Try the develop branch version and see how you like that: it implements the per-resource error handling described above. |
@mjhagen Any thoughts on this new error-handling behavior? |
(as posted on the CFML Slack's #fw1)
This makes sense, but I would like the framework to account for that and maybe provide a better way handling expected errors in routes.
Example:
I have a subsystem with my API in it (api:) and when I call this URL:
DELETE /api/myObject/1
that will be rewritten by fw/1 toapi:myObject.destroy?id=1
but when I callDELETE /api/myObject
it gets rewritten todefaultsubsystem:api.myObject
where I would like it to recognize the pattern and either throw a 404 or a 500 (I'm not sure which is more RESTful).The text was updated successfully, but these errors were encountered: