tracker issue : CF-3546047

select a category, or use search below
(searches all categories and all time range)
Title:

Why is it restSetResponse()? Why is it not just setResponse()?

| View in Tracker

Status/Resolution/Reason: To Fix//

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 04/19/2013

Components: REST Services

Versions: 2016,11.0,10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Windows 7 64-bit

Vote Count: 0

Why is it restSetResponse()? Why is it not just setResponse()? If there's a rationale for this functionality in the response from a REST request, then the same rationale exists for any other sort of request response. This function deals with HTTP, it's nothing specific to REST.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3546047

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

We have added few APIs for restfull web services like restInitApplication, restDeleteApplication etc., so we are following the same convention here aswell. All the rest APIs are starting with "rest" and this restSetResponse() can only be used in rest services.
Comment by HariKrishna K.
15594 | May 29, 2013 05:58:16 AM GMT
This is the second instance in 24h of you lot not reading the ticket. Can I draw your attn to this: " If there's a rationale for this functionality in the response from a REST request, then the same rationale exists for any other sort of request response. This function deals with HTTP, it's nothing specific to REST." You seem to be missing the point I'm trying to make: this function *could* be used - and ben quite useful for - for non-REST responses too. So why make the artificial limitation? -- Adam
Comment by External U.
15595 | December 13, 2013 06:18:45 PM GMT
@Adam, your question is very valid and a quite logical one. REST framework uses Jersey underneath and doesn't deal with HTTP request and response directly. This is why we added a separate method for setting the response which Jersey uses to write to the http response. The same functionality can be useful for non-REST request as well and therefore I would mark this as enhancement to be taken up later. This is not critical since for non-REST requests, we anyway have cfheader and cfcontent to work with http response directly.
Comment by Rupesh K.
15596 | January 02, 2014 02:07:36 AM GMT
Yep, fair enough. Glad someone took time to actually read what I said. Cheers Rupesh. -- Adam
Comment by External U.
15597 | January 02, 2014 05:32:25 AM GMT