When using `$RESOURCES` as routes, a malformed `DELETE` (missing an ID) will result in a mismatching action #392

Closed
mjhagen opened this Issue Oct 27, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@mjhagen
Contributor

mjhagen commented Oct 27, 2015

(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 to api:myObject.destroy?id=1 but when I call DELETE /api/myObject it gets rewritten to defaultsubsystem: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).

@seancorfield seancorfield added this to the 4.0 milestone Oct 27, 2015

@mjhagen

This comment has been minimized.

Show comment
Hide comment
@mjhagen

mjhagen Oct 28, 2015

Contributor

I've created an example app displaying this behavior: https://github.com/mjhagen/SSCCE/tree/master/fw1-392
The http call is in views/main/default.cfm

Contributor

mjhagen commented Oct 28, 2015

I've created an example app displaying this behavior: https://github.com/mjhagen/SSCCE/tree/master/fw1-392
The http call is in views/main/default.cfm

@seancorfield

This comment has been minimized.

Show comment
Hide comment
Member

seancorfield commented Oct 28, 2015

👍

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

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.

Member

seancorfield commented Oct 31, 2015

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.

seancorfield added a commit that referenced this issue Oct 31, 2015

Tentative fix for #392
Add perResourceError config (default true -- breaking change!) that adds
a $* match for HTTP method and an error handler per-resource.
@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

Try the develop branch version and see how you like that: it implements the per-resource error handling described above.

Member

seancorfield commented Oct 31, 2015

Try the develop branch version and see how you like that: it implements the per-resource error handling described above.

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

@mjhagen Any thoughts on this new error-handling behavior?

Member

seancorfield commented Oct 31, 2015

@mjhagen Any thoughts on this new error-handling behavior?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment