REST requests do not call standard Application.cfc methods

[Juan Aguilar]

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.

[Juan Aguilar]

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.

[AJ Mercer]

​

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

--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/b7737ca0-6803-4167-96da-12950e179d2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

[Adam Cameron]

On Saturday, 16 May 2015 00:47:39 UTC+1, AJ Mercer wrote:

​

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 @ 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 

[Juan Aguilar]

I get the feeling that REST is the red-headed child on this brown-haired project.

[Desmond Miles]

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

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...).