È tipico che un fornitore di servizi web fornisca anche librerie client?

Non utilizzare GWT-RPC per "API aperte": un client si romperà non appena cambierai una classe sul tuo server.

RequestFactory potrebbe essere un'opzione, dato che è possibile utilizzare ServiceLayerDecorator per fornire un "percorso di migrazione" per i vecchi client quando si aggiorna il server (in più, non si romperà un client se si cambiano le classi del server ma non i proxy e anche se si cambiano i propri contesti o proxy, si interromperanno solo i client se si apportano, er, interrompendo le modifiche ad essi) e un client Java è incorporato (RequestFactorySource con UrlRequestTransport)

Detto questo, se vuoi davvero una "API aperta", vai sulla strada "REST". Usando cose come JAX-RS o Restlet, puoi sfruttare il codice che hai scritto per la tua app GWT (usando GWT-RPC o RequestFactory).

Dipende dalle esigenze dei clienti per l'app web. Due scenari comuni sono i clienti con risorse IT ridotte o assenti e i clienti con team IT che lavorano su un progetto complessivo più ampio.

Fornire le librerie client aiuta nell'adozione. In genere, un team IT più capace sviluppa qualcosa, un'applicazione web in questo caso, per impedire ai propri clienti di mettere le risorse per svilupparlo. Ma questo implica che potrebbero non avere le risorse per costruire anche il codice lato client.

Poi ci sono alcuni clienti che avranno risorse e potrebbero voler integrare la tua web-app in qualcosa di più completo. È qui che SOAP o REST possono renderlo più facile per loro.

Oltre ai punti eccellenti che fa Chris, l'adozione di un'API basata su standard aperti significa che anche se puoi creare librerie per aiutare i clienti che utilizzano una particolare piattaforma (.NET, Java , ecc.), sei ancora aperto alle persone che intendono utilizzare la tua API da altre piattaforme.

Inoltre, solo perché ora sei disposto a creare una libreria client non significa che vorrai impegnarti a mantenerlo per gli anni a venire. Amazon ha messo insieme alcune librerie client per le loro API, ma quando ho provato a utilizzarle erano irrimediabilmente obsolete e Amazon non sembrava avere alcun interesse nel risolverle. Questo è, purtroppo, il modo in cui funziona l'azienda. Avere uno standard aperto consente alle persone di continuare a utilizzare il servizio anche se la tua azienda non riesce a mettere le risorse nel mantenimento delle librerie client.

È una questione di opinione ... Penso che SOAP e REST siano standard così che non ha molto senso fornire librerie client. La generazione di stub client dal WSDL dovrebbe essere banale e consentire la massima flessibilità, quindi perché i clienti non dovrebbero farlo da soli?

A meno che, naturalmente, i clienti non siano non banali - se stai facendo qualcosa di complicato o non standard, allora avrebbe senso fornire le librerie client per il tuo servizio.

Penso che se fornisci o meno dei clienti, la cosa più importante è pubblicare una documentazione completa del tuo servizio.