2013-05-12 13 views
12

Usiamo Primavera di implementare controller di REST, per esempio:Come generare un proxy client Java per il servizio RESTful implementato con Spring?

@Controller 
@RequestMapping("/myservice") 
public class MyController { 
    @RequestMapping(value = "foo", method = RequestMethod.GET) 
    public @ResponseBody string foo() {...} 
} 

posso chiamare questo servizio utilizzando primavera RestTemplate, e funziona benissimo, ma io preferirei richiamare utilizzando un proxy, invece di typeless invocazione utilizzando stringa:

Quindi l'input per la generazione del proxy è l'interfaccia java con annotazioni che descrivono i dettagli REST. Ho letto this article e sembra che tutti i tipi di chiamate remote abbiano proxy, e tutto ciò di cui ho bisogno per REST è qualcosa come RestProxyFactoryBean, che richiederebbe la mia interfaccia java REST e restituire il proxy sicuro dal tipo che utilizza RestTemplate come implementazione.

La soluzione più vicina che ho trovato è JBoss RESTEasy.

Ma sembra che utilizzi diverse serie di annotazioni, quindi non sono sicuro che funzionerà con le annotazioni che ho già: @Controller, @RequestMapping. Ci sono altre opzioni o RESTEasy è l'unico? Nota, sono un principiante della primavera, quindi alcune ovvie cose primaverili sono piuttosto nuove per me.

Grazie.
Dima

+0

hai trovato qualche soluzione? – Suraj

+0

Personalmente, trovo che il framework di prova MVC di Spring sia lo strumento giusto. I test in modalità RESTful possono eliminare molte sorprese. Vedi http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/testing.html#spring-mvc-test-framework –

+0

Cosa dovresti fare esattamente il proxy? Se stai cercando un'altra implementazione del protocollo REST, c'è anche il progetto cxf. – Patouche

risposta

1

Uno dei motivi del paradigma REST è stato inventato era perché expirience con altre tecnologie di comunicazione remota (RMI, CORBA, SOAP) ci mostra che spesso, l'approccio basato su proxy crea più problemi di quanti ne risolva.

In teoria, un proxy rende il fatto che una chiamata di funzione è remota e trasparente ai propri utenti, in modo che possano utilizzare la funzione esattamente allo stesso modo di una chiamata di funzione locale.

In pratica, tuttavia, questa promessa non può essere soddisfatta, poiché le chiamate a funzioni remote hanno semplicemente proprietà diverse dalle chiamate locali. Interruzioni di rete, congestione, timeout, problemi di carico per citarne solo alcuni. Se si sceglie di ignorare tutte queste cose che possono andare storte con le chiamate remote, il codice probabilmente non sarà molto stabile.

TL; DR: Probabilmente non dovresti lavorare con un proxy, non è più all'avanguardia. Basta usare RestTemplate.

+3

Le preoccupazioni sulla natura remota della chiamata proxy possono essere risolte con parametri aggiuntivi come timeout, numero di tentativi, gestori di errori di rete, denominazione dei metodi remoti. Sto cercando di risolvere il problema della discrepanza semplice e stupida tra client e server (succede molto), e usando la potenza del compilatore per cogliere i miei refusi. – Dima

+0

Questa sembra essere la saggezza convenzionale, ma faccio fatica a come la costruzione di chiamate http elimina questi problemi. Non stai ancora ottenendo le stesse eccezioni se usi un client proxy o RestTemplate? Penso che sarebbe abbastanza facile per uno sviluppatore vedere un'interfaccia piena di annotazioni REST e rendersi conto che è una chiamata remota. Sembra semplicemente che le ragioni contro i proxy siano alquanto vaghe, mentre il dolore di non usarle è molto concreto (codice standard, potenziale divergenza dalla versione server, procedurale rispetto alla codifica dichiarativa, ecc ...) –

+0

@MichaelHaefele: Sì, naturalmente, il i problemi sono sempre gli stessi, non è questo il punto. Ma quando leggo il codice, è ovvio per me che questi problemi possono verificarsi, mentre un proxy nasconde il fatto al lettore. –

1

Ecco un progetto che tenta di generare proxy di runtime dalle annotazioni del controller (utilizzando RestTemplate in background per gestire le chiamate proxy): spring-rest-proxy-client Tuttavia, molto presto nell'implementazione.

3

È possibile provare Feign da Netflix, un client REST leggero basato su proxy. Funziona in modo dichiarativo attraverso le annotazioni ed è utilizzato dai progetti Spring Cloud per interagire con Netflix Eureka.

+0

Mi chiedo se Feign fosse pronto per la produzione nel 2013, quando ne avevo bisogno. Il commit iniziale per Feign è avvenuto nella primavera del 2012 e il primo numero è stato registrato nell'estate 2013. – Dima

+0

Hmm .. Non so se Feign è stato pronto per la produzione nel 2013, ma di sicuro so che molti progetti Netflix già esistenti sono stati aperti in quel periodo ... forse Feign era uno di loro? ma non sono sicuro di questo ovviamente :) – pcan