Chi mi conosce sa che non sono un gran simpatizzante di AJAX e riconoscendo che in effetti serve qualcosa di più del buon vecchio HTML, trovo Silverlight decisamente una soluzione migliore. Ma non è di questa moda che voglio parlare, ma bensì di REST e POX.
Con il primo termine si intende il voler sfruttare a pieno le capacità di HTTP, mediante i suoi method, per ampliare l'applicazione web e fornire servizi aggiuntivi usufruibili al di fuori dell'HTML e della semplice navigazione. In pratica, siccome esistono i metodi GET, POST, PUT e DELETE si è pensato di sfruttarli per eseguire le classiche operazioni CRUD, magari aggiugendo dei parametri nell'URI o nel contenuto della richiesta. Tutto questo ovviamente esiste da sempre, ma veniva marginalmente sfruttato e solo ora, e ben venga, siti come Amazon, Google, Live, ecc permettono di interrogare e di usufruire dei loro servizi mediante REST.
POX invece vuol dire Plain Old XML e in pratica vuol dire usare XML semplice senza fronzoli, da utilizzare nelle richieste o risposte REST.
Cosa non mi piace di tutto questo? Il fatto che si sta reinventando la ruota. Per esempio, chi espone operazioni REST si trova a dover fornire della documentazione per spiegare come chiamare le varie operazioni, come dev'essere passato l'XML e spesso in maniera superficiale, limitandosi ad un esempio di XML o ad un esempio di parametro in query string. Beh a tutto questo qualcuno ci aveva già pensato e vedendo che non era sufficiente aveva pensato ai WebService, a SOAP, ai consorzi per renderli i più interoperabili possibili. Per XML esistono gli schema XSD che sono molto più completi, mentre per conoscere quali operazioni espone un servizio c'è WSDL e WS-Metadata Exchange. Senza contare che con framework come WCF basta semplicemente fare un "Add Service reference" e ci si può persino permettere di ignorare questi linguaggi e di esporre della documentazione aggiuntiva.
E' vero che non tutti fanno applicazioni enterprise ed usare WCF/WebService può sembrare un carro armato per uccidere le mosche, ma sono del parere che alcune problematiche sono presenti anche in semplici siti web. Tra questi il già citato, come chiamare un'operazione, ma anche quali errori mi può eventualmente dare e come li gestisco. Poi man mano ci sono altri aspetti, come l'autenticazione, spesso affidata ad un token rilasciato da chi espone il servizio da inserire nella querystring, mentre in WS-* tutto questo è già definito. Sono inoltre definiti come rendere le operazioni sicure, criptate, transazionali, come gestire le policy ed inviare file di grosse dimensioni. Ovviamente se tutto questo non serve basta non abilitarlo e l'XML resta contenuto, senza offenderlo chiamandolo POX :-).
E' per questo che storto un po' il naso e che il diffondersi di questi termini sia più dovuto o ad ignoranza su certe tecnologie (almeno io so il loro nome :-) ) oppure ad una pigrizia nell'affrontarle ed impararle. Detto questo, sicuramente ci sono ambiti in cui una normale richiesta GET basta e avanza; l'importante che vengano valutate anche le altre strade e che non venga coniato qualche nuovo termine o nuova era del web.
Ciao, grazie per la risposta, mi fa piacere potermi confrontare con altre persone con altre esperienze
Il versioning è sicuramente un problema che va gestito fin dalla definizione della prima versione di un servizio. Dal punto di vista degli schema XSD si possono prevedere ulteriori attributi o elementi, in modo che chi consumi la prima versione di un servizio possa tranquillamente ignorare i dati proveniente dalla seconda versione.
In questo modo puoi preparare i client e mantenere la retrocompatibilità senza mantenere in vita due servizi, mentre con REST tutto questo è indefinito e lasciato nelle mani di chi rilascia la documentazione.
Nell'esempio che hai posto di upgrade del tipo, in realtà non capisco il problema. E' vero che lo schema xsd cambierebbe, ma i vecchi client continuerebbero a funzionare, anche con il nuovo servizio, poiché in SOAP non c'è descrizione del tipo, diversamente dal vecchio RPC.
In caso di downgrade ci potrebbe essere un potenziale problema sulla dimensione del tipo, ma questo anche in caso di REST perché dovresti controllare il tipo e comportarti in due modi diversi; non sarebbe comunque molto diverso dal mantenere in vita due servizi.
Io sto solo dicendo di usare soap, wsdl e ws-* che sono metodologie, standard e contratti, ma in fondo quello che si fa e che passa sul cavo è pur sempre un REST+POX
Vorrei poterti dare l'esempio pratico che ci ha fatto impazzire recentemente - purtroppo devo aspettare ancora qualche mese...
Il problema critico di SOAP è il suo strong typing.
Gli standard WS-* sono belli in teoria, ma a parte quelli più semplici, pochi li usano perché le implementazioni sono molto parzialmente compatibili.
Non è l'unico - un altro dei problemi più divertenti che abbiamo avuto nel passato è il supporto nei tool.
Prendi per esempio gli attributi di tipo List in XSD. In VS se usi C# tutto bene. Ma già se usi C++ sei nei guai - la code generation fallisce. Anche xsd.exe rifiuta quel WSDL (valido in teoria).
Per non parlare di tutti i tool in Java o altre piattaforme non MS.
Se vuoi toccare il problema con mano, basta che punti al WSDL della generazione corrente delle Live Search API (http://soap.search.msn.com/webservices.asmx?wsdl e provi direttamente.
C'è un'altra grossa differenza: costruire la chiamata tramite i parametri di un URL è molto più semplice che costruire un'intera struttura in XML in una request. Per non parlare della prolissità - SOAP è inutilizzabile in ogni scenario dove la banda passante sia critica (per esempio i telefonini).
Saluti
--Alessandro
Lunge da me dire che le specifiche siano complete e neanche gli strumenti
E' per questo che io comunque preferisco fare affidamento e partire da certi standard.
Riconosco l'esigenza di poter avere il controllo totale di quello che si sta facendo e REST da questo punto di vista è perfetto. Devi occuparti di ogni aspetto di conversione, sicurezza ecc, però anche in questo caso preferisco usare un framework come WCF perché posso modificare solo parti del messaggio, o gestirlo interamente, oppure non per forza rappresentare l'xml infoset come testo.
In effetti l'xml come testo è prolisso, ma non penso che quella struttura complessa che c'è nel wsdl che hai linkato tu la voglia passare in querystring, sarebbe molto più complicato creare i parametri e inoltre subentrerebbero limiti nella richiesta GET.
Ci tengo a sottolineare che secondo me fare una richiesta al motore di ricerca passando "search?q=cosa cercare" va benissimo, ma nel momento in cui serve qualcosa di più passerei a SOAP.
Questo è un punto sul quale sono completamente d'accordo.
Il problema non è il formato di serializzazione, è l'infrastruttura che lo usa.
WCF è molto versatile perché va al di là del protocollo su cui si basa.
Il problema è che non ci sono troppi framework con quel livello di sofisticazione, e soprattutto quando devi interoperare con sistemi diversi, scegliere oculatamente il formato on the wire diventa importante.
SOAP ha alcuni vantaggi, ma anche grossi problemi, come abbiamo già discusso. REST è un'alternativa di moda e efficace in molti ambiti.
L'ideale per un servizio veramente versatile è offrirli entrambi (magari aggiungendo anche la serializzazione in JSON)
Saluti
--Alessandro
Cristian "Ricciolo" Civera wrote:
l'importante che vengano
valutate anche le altre strade e che non venga coniato qualche nuovo termine o nuova era del web.
io sono lì che aspetto con impazienza il web 4x4 a trazione integrale...
io sono lì che aspetto con impazienza il web 4x4 a trazione integrale...
ma LOL
Io penso che la cosa buona di "reinventare la ruota" sia il fatto che le grandi aziende "ripescando" queste vecchie idee approfondiscono e irrobustiscono queste "tecnologie" consentendoci un loro migliore utilizzo, sia dandoci nuovi strumenti (vedi AJAX) sia dandoci più tempo per digerire queste novità che fioccano alla velocità della luce.
Sotto certi aspetti anche WCF segue un po' questo concetto perchè ha introdotto alcune novità ma soprattutto a livello di metodologia di lavoro più che in tecnologia stessa.
Il fatto è che molte delle innovazioni non sono facili da cogliere e sfruttare sia perchè vengono presentate molto velocemente e quindi sono poco curate, e con i tempi di sviluppo che ci vengono imposti siamo in pochi a voler rischiare di avventurarci in qualcosa che non conosciamo, che è poco documentato e che è anche poco "raffinato" dal produttore perchè anche esso ha voluto distribuire il prima possibile (secondo me fanno la spia anche gli errori criptici di WCF e di LINQ).
Quindi, anche se il principio REST/POX per molti aspetti mi piace molto (mentre per altri mi preoccupa => aka sicurezza), concordo in pieno con le considerazioni che hai fatto.
>secondo me fanno la spia anche gli errori criptici di WCF e di LINQ
Dici??? Come mai??? restituiscono errori perfetti, che ti permettono di capire al volo il problema no?
Spumpetta!
LOG!LOG!LOG!LOG!
(ta' tada' tada' tadatada' tada' tada')
Modificato da novecento il 25 marzo 2008 13.09 -
Per inserire un commento, devi registrarti alla nostra community.





Stampa
Download


Cristian,
il tuo post è eloquente, ma glissa su alcuni aspetti della realtà dei web service che sono di fatto alla radice del declino di SOAP, soprattutto su servizi mainstream.
Le tue considerazioni sono perfettamente condivisibili se ti metti dalla parte del consumatore di un servizio. Soprattutto se hai a disposizione tool evoluti come Visual Studio che generano decine di linee di boilerplate code per te, è molto semplice ridurre l'utilizzo di un web service SOAP a due linee di codice: crea il proxy, istanzia il proxy.
Facciamo un fast-forward e passiamo a cosa succede quando esce la versione 2.0 del servizio, oppure quando semplicemente devi correggere un baco nel servizio stesso.
Supponiamo per esempio che un parametro intero debba passare da 32 a 64 bit. Niente di drammatico - il cambiamento è perfettamente compatibile con la versione passata.
Grazie a SOAP e al suo strong typing però, il WSDL non è più lo stesso, quindi tutti i client che si basavano sull'interfaccia con l'Int32 non possono usare quella nuova (funzionalmente compatibile) con un Int64. L'unica scelta come fornitore del servizio è tenere entrambi i servizi in vita side-by-side, magari con della logica di thunking che almeno unifichi l'esecuzione.
Dal punto di vista del service provider, SOAP è un incubo. Ti trovi a dovere supportare molto rapidamente una miriade di major e minor versions o a dovere fare degli hack orrendi per incastrare in un dato WSDL cose che non erano lontanamente previste.
Tutto questo con REST sparisce - da cui la sua crescente popolarità.
Che poi il Web 2.0 sia una colossale minestra riscaldata (si faceva AJAX già nel 2000 anche se allora non aveva il nome fico, e REST/XML si chiamava XML over HTTP
Saluti
--Alessandro
Continua »»» | Rispondi »»»