Come probabilmente presumi già, la risposta è che dipende. Dipende da cosa vuoi fare.
I tuoi clienti non si preoccupano di quale sia l'implementazione dell'API REST, se si tratta di JAX-RS, servlet semplici o altro. Si preoccupano delle risorse che il tuo servizio espone e di come interagire con le loro rappresentazioni (che sono per lo più fatte con JSON o XML).
Scegliamo su JSON, che è quello che probabilmente usi poiché la maggior parte delle esercitazioni JAX-RS là fuori usano Jackson per la serializzazione. Una libreria come Jackson - per impostazione predefinita - esamina l'oggetto reale quando esegue la serializzazione, i suoi getter e setter pubblici e non le interfacce dell'oggetto. Quindi, non importa se il tuo metodo annotato @GET restituisce un'interfaccia o un metodo. Questo è importante solo per come stai implementando il servizio. Non per i tuoi clienti. Per te!
L'utilizzo di un'interfaccia invece di un'implementazione offre alcuni vantaggi. Leggi qui per esempio: link
Ma ancora una volta, questi sono i vantaggi per te come sviluppatore del servizio, il tuo cliente non è a conoscenza dell'implementazione del servizio, solo sui dati che scambia con esso.
Ci sono anche degli svantaggi. Se i tuoi controller restituiscono tutte le interfacce, come fai a sapere quali restituiscono, ad esempio, un Customer e quali restituiscono un Invoice . Non lo fai, perché hai deciso che tutti restituiscono un Entity (o qualsiasi altra cosa sia l'interfaccia comune), e ora devi cercare nel codice per vedere cosa restituisce ciascun metodo. Inoltre, alcuni sviluppatori che lavorano con te sul servizio potrebbero decidere che a un certo punto lo stesso metodo può restituire sia un Customer che un Invoice solo perché il tipo restituito gli consente di essere qualsiasi Entity . E ora hai un'API REST che si comporta in modo strano.
Come ho detto, dipende da cosa vuoi fare. Non c'è solo una cosa "di solito fatta in casi di uso reale".