In JAX-RS 2.0 you can always modify response headers in e.g. name-bound response filters <
https://jersey.java.net/documentation/2.16/filters-and-interceptors.html#d0e9848>… And since these are name-bound, you can do it selectively per resource method.
Marek
> On 25 Feb 2015, at 10:37, Mikael Ståldal <mikael.staldal_at_appearnetworks.com> wrote:
>
> In my experience it usually makes sense to return plain business objects from GET methods, but Response from PUT/POST/DELETE, since you often want to add headers and/or set status code for PUT/POST/DELETE.
>
> On Tue, Feb 24, 2015 at 10:00 PM, Martynas Jusevičius <martynas_at_graphity.org <mailto:martynas_at_graphity.org>> wrote:
> You're right. In my case, I'm anticipating people extending my code
> will/might have to add headers etc, therefore I chose the more general
> Response to spare them the trouble.
>
> On Tue, Feb 24, 2015 at 5:28 PM, Marek Potociar
> <marek.potociar_at_oracle.com <mailto:marek.potociar_at_oracle.com>> wrote:
> > Martynas,
> >
> > I don’t think you are right. Loose coupling is achieved by ability to define
> > and plug in entity providers (MBR, MBW) as a separate cross-cutting concern.
> > Unless you need to specifically modify your response (e.g. set a custom
> > status code other than 200/204, set additional headers etc.), you may just
> > want to return the POJO from your resource method and spare yourself of
> > polluting your business logic with an unnecessary boiler-plate code that
> > creates a new Response instance.
> >
> > So I would say that this is definitely preferred, if possible:
> >
> > @GET
> > @Produces(APPLICATION_JSON)
> > public Customer getCustomer() { … }
> >
> > Cheers,
> > Marek
> >
> > On 20 Feb 2015, at 16:27, Martynas Jusevičius <martynas_at_graphity.org <mailto:martynas_at_graphity.org>> wrote:
> >
> > In my opinion Response is more generic, and that is an advantage. Your
> > domain classes such as Customer are likely to change over time. Using
> > Response allows you to avoid coupling those with your HTTP-level code.
> >
> > On Fri, Feb 20, 2015 at 3:47 PM, Mikael Ståldal
> > <mikael.staldal_at_appearnetworks.com <mailto:mikael.staldal_at_appearnetworks.com>> wrote:
> >
> > I would recommend to return a plain custom object, unless you need to set
> > any response metadata (HTTP response status or headers).
> >
> > On Fri, Feb 20, 2015 at 3:08 PM, Paul Blakeley
> > <Paul.Blakeley_at_lifestylegroup.co.uk <mailto:Paul.Blakeley_at_lifestylegroup.co.uk>> wrote:
> >
> >
> > Hi,
> >
> > I use restful services quite a lot these days. But one of
> > my colleges was questioning whether when returning a response from a service
> > should you return a custom object or wrap the object in the Response. I
> > thought wrapping any custom object in a Response was the right thing to do.
> > He seemed to think otherwise! It would be good to get some idea on what is
> > the right way, if there is one? Or to get the advantages/disadvantages of
> > either way? I have provided examples below of either way just to clarify.
> >
> >
> >
> > @GET
> >
> > @Produces({ MediaType.APPLICATION_JSON })
> >
> > public Response getCustomers() {
> >
> > ...
> >
> > }
> >
> >
> >
> > @GET
> >
> > @Produces({ MediaType.APPLICATION_JSON })
> >
> > public List<Customer> getCustomers() {
> >
> > ...
> >
> > }
> >
> > Assurant Solutions - The new name for Lifestyle Services Group.
> >
> > This e-mail message and all attachments transmitted with it may contain
> > legally privileged and/or confidential information intended solely for the
> > use of the addressee(s). If the reader of this message is not the intended
> > recipient, you are hereby notified that any reading, dissemination,
> > distribution, copying, forwarding or other use of this message or its
> > attachments is strictly prohibited. If you have received this message in
> > error, please notify the sender immediately and delete this message and all
> > copies and backups thereof.
> >
> > In the UK, Assurant Solutions is a trading name for each of the following
> > companies: Assurant Group Limited, registered in England no. 3264846;
> > Lifestyle Services Group Limited, registered in England no. 5114385;
> > Assurant General Insurance Limited, registered in England No. 2341082;
> > Assurant Life Limited, registered in England no. 3264844; Assurant Services
> > (UK) Limited, registered in England no. 2515130; Assurant Direct Limited,
> > registered in England no. 5399683; Assurant Intermediary Limited, registered
> > in England no. 4019801 The UK branch of Assurant Services Limited,
> > registered in England no. FC028217.
> >
> > The registered office for all the companies noted above is Assurant House,
> > 6-12 Victoria Street, Windsor, Berkshire, SL4 1EN.
> >
> > Lifestyle Services Group Limited is authorised and regulated by the
> > Financial Conduct Authority under register number 315245. Assurant General
> > Insurance Limited is authorised by the Prudential Regulation Authority and
> > regulated by the Financial Conduct Authority and the Prudential Regulation
> > Authority under register number 202735. Assurant Life Limited is authorised
> > by the Prudential Regulation Authority and regulated by the Financial
> > Conduct Authority and the Prudential Regulation Authority under register
> > number 203060. Assurant Direct Limited is an appointed representative of
> > Assurant Intermediary Limited, which is authorised and regulated by the
> > Financial Conduct Authority under register number 311243.
> >
> > You can check this information on the Financial Services Register at
> > http://www.fca.org.uk/register <http://www.fca.org.uk/register> or by calling 0800 111 6768.
> >
> >
> >
> >
> >
> > --
> > Mikael Ståldal
> > Chief Software Architect
> > Appear
> > Phone: +46 8 545 91 572 <tel:%2B46%208%20545%2091%20572>
> > Email: mikael.staldal_at_appearnetworks.com <mailto:mikael.staldal_at_appearnetworks.com>
> >
> >
>
>
>
> --
> Mikael Ståldal
> Chief Software Architect
> Appear
> Phone: +46 8 545 91 572 <>
> Email: mikael.staldal_at_appearnetworks.com <mailto:mikael.staldal_at_appearnetworks.com>