REST requests do not call standard Application.cfc methods

In his blog (re: ACF,
http://blog.adamcameron.me/2013/07/rest-requests-dont-seem-to-correctly.html)
and group post (re: Railo,
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ), Adam
Cameron raised the issue that REST calls which generate errors do not
call onError. In the latter link, AJ Mercer notes, “There is a separate
servlet for handling ReST calls - maybe it has not implemented
onCfcRequest()???”

As far as I can tell, REST errors do not respond to the settings on the
Administrator : Settings : Error page (for either the server of web
contexts).

I am trying to make sure my results are consistent for all results but
Lucee REST errors are returning an unformatted (text/html) string of the
exception message, whereas I would like to return a {“status”:“error”,
“message”:“The error message goes here”} struct instead.

If this is a bug, has anybody figured out a workaround? It has not been
filed as a bug yet.

My workaround to this issue is to modify the output buffer using the
onRequestEnd method.

public void function onRequestEnd() {
if (GetPageContext().getResponse().getStatus() != 200 && !isJSON(
GetPageContext().getOut().getString()) {
var tmpOutput = GetPageContext().getOut().getString();
content reset=“true” type=“application/json”;
echo(’{“status”:“error”,“message”:"#tmpOutput#"}’);
}
return;
}

This also allows me to simulate what onError would do when
GetPageContext().getResponse().getStatus() != 200.On Thursday, May 14, 2015 at 11:44:59 AM UTC-4, Juan Aguilar wrote:

In his blog (re: ACF,
http://blog.adamcameron.me/2013/07/rest-requests-dont-seem-to-correctly.html)
and group post (re: Railo,
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ), Adam
Cameron raised the issue that REST calls which generate errors do not
call onError. In the latter link, AJ Mercer notes, “There is a separate
servlet for handling ReST calls - maybe it has not implemented
onCfcRequest()???”

As far as I can tell, REST errors do not respond to the settings on the
Administrator : Settings : Error page (for either the server of web
contexts).

I am trying to make sure my results are consistent for all results but
Lucee REST errors are returning an unformatted (text/html) string of the
exception message, whereas I would like to return a {“status”:“error”,
“message”:“The error message goes here”} struct instead.

If this is a bug, has anybody figured out a workaround? It has not been
filed as a bug yet.


what happens with other success status codes like 201
​,202​
and 204?

I don’t think this will handle run time errors the onError would catch

Hopefully someone from the Lucess Dev Team can explain why onError is not
supported for /rest callsOn 15 May 2015 at 22:19, Juan Aguilar <@Juan_Aguilar> wrote:

My workaround to this issue is to modify the output buffer using the
onRequestEnd method.

public void function onRequestEnd() {
if (GetPageContext().getResponse().getStatus() != 200 && !isJSON(
GetPageContext().getOut().getString()) {
var tmpOutput = GetPageContext().getOut().getString();
content reset=“true” type=“application/json”;
echo(’{“status”:“error”,“message”:"#tmpOutput#"}’);
}
return;
}

This also allows me to simulate what onError would do when
GetPageContext().getResponse().getStatus() != 200.

On Thursday, May 14, 2015 at 11:44:59 AM UTC-4, Juan Aguilar wrote:

In his blog (re: ACF,
http://blog.adamcameron.me/2013/07/rest-requests-dont-seem-to-correctly.html)
and group post (re: Railo,
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ), Adam
Cameron raised the issue that REST calls which generate errors do not
call onError. In the latter link, AJ Mercer notes, “There is a separate
servlet for handling ReST calls - maybe it has not implemented
onCfcRequest()???”

As far as I can tell, REST errors do not respond to the settings on the
Administrator : Settings : Error page (for either the server of web
contexts).

I am trying to make sure my results are consistent for all results but
Lucee REST errors are returning an unformatted (text/html) string of the
exception message, whereas I would like to return a {“status”:“error”,
“message”:“The error message goes here”} struct instead.

If this is a bug, has anybody figured out a workaround? It has not been
filed as a bug yet.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/b7737ca0-6803-4167-96da-12950e179d2e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/b7737ca0-6803-4167-96da-12950e179d2e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

AJ Mercer
<webonix:net strength=“Industrial” /> http://webonix.net | <webonix:org
community=“Open” /> http://webonix.org
http://twitter.com/webonix

I get the feeling that REST is the red-headed child on this brown-haired
project.On Saturday, May 16, 2015 at 2:21:30 AM UTC-4, Adam Cameron wrote:

It’s interesting that I asked about this
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ @ the
beginning of last year (back when it was Railo), and never got any feedback
@ all from anyone from the team. Better luck this time, eh?


Adam


what happens with other success status codes like 201
​,202​
and 204?

I don’t think this will handle run time errors the onError would catch

Hopefully someone from the Lucess Dev Team can explain why onError is not
supported for /rest calls

It’s interesting that I asked about this
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ @ the
beginning of last year (back when it was Railo), and never got any feedback
@ all from anyone from the team. Better luck this time, eh?On Saturday, 16 May 2015 00:47:39 UTC+1, AJ Mercer wrote:


Adam

Thank you for sharing your workaroud (I thought not a lot of people have
posted about the REST API) :slight_smile:

Indeed your workaround is the only solution for this case because REST
component methods (i.e CFC with restPath and httpMethod attributes) are
executed after onRequestStart() and their exception are NOT implicitly
dispatched to onError().
Notice that ONLY uncatched exception thrown in REST components initialization
block
(i.e outside its functions) are implicitly dispatched to onError().
Of course this behaviour requires *restSetting.skipCFCWithError set to
FALSE *and these exceptions are thrown after onRequestStart().

In my situation I updated custom keys in the REQUEST scope (something like
REQUEST.errorOccurred and REQUEST.thrownException). Also to avoid checking
for all successful 2xx HTTP status values.
I also have to handle exception occuring before onRequestStart and REST
components (e.g In Application.cfc initialization block) and I use the same
REQUEST scope solution.
But I will try to mix with your workaround too because I’m particularly
interested by the PageContext.getResponse().isCommitted() value.

One of my problem is that the solution implies a design convention between
developpers because they have to be aware that onRequestEnd() will check
for the processing status and may send a server response then.
This means that they should rethrow the exception if they’ve handled it (in
order to have an 5xx HTTP status code). Also they may have to :

  • Provide an access to the exception for onRequestEnd() as
    PageContext.getException() and PageContext.getErrorData() will unlikely
    reflect the CF exception.
  • NOT send an error response from REST components because it may be ignored
    by the cfcontent(reset=true){} in onRequestEnd().
  • In my case, custom key / value in the REQUEST scope must be updated on
    errors…

Even if there’s no perfect solution for this issue, it SHOULD BE taken in
consideration because it is a valuable feature (especially in enterprise).
Of course there are frameworks…but…

And again, thanks for sharing such experience, really appreciated

PS: I’m using Lucee 4.5.x / Tomcat 8.x (didn’t tried 5.x yet…).On Friday, May 15, 2015 at 4:19:12 PM UTC+2, Juan Aguilar wrote:

My workaround to this issue is to modify the output buffer using the
onRequestEnd method.

public void function onRequestEnd() {
if (GetPageContext().getResponse().getStatus() != 200 && !isJSON(
GetPageContext().getOut().getString()) {
var tmpOutput = GetPageContext().getOut().getString();
content reset=“true” type=“application/json”;
echo(’{“status”:“error”,“message”:"#tmpOutput#"}’);
}
return;
}

This also allows me to simulate what onError would do when
GetPageContext().getResponse().getStatus() != 200.

On Thursday, May 14, 2015 at 11:44:59 AM UTC-4, Juan Aguilar wrote:

In his blog (re: ACF,
http://blog.adamcameron.me/2013/07/rest-requests-dont-seem-to-correctly.html)
and group post (re: Railo,
https://groups.google.com/d/msg/railo/GTQZiQNe8vg/IDCOcT_ClUoJ), Adam
Cameron raised the issue that REST calls which generate errors do not
call onError. In the latter link, AJ Mercer notes, “There is a separate
servlet for handling ReST calls - maybe it has not implemented
onCfcRequest()???”

As far as I can tell, REST errors do not respond to the settings on the
Administrator : Settings : Error page (for either the server of web
contexts).

I am trying to make sure my results are consistent for all results but
Lucee REST errors are returning an unformatted (text/html) string of the
exception message, whereas I would like to return a {“status”:“error”,
“message”:“The error message goes here”} struct instead.

If this is a bug, has anybody figured out a workaround? It has not been
filed as a bug yet.