Nell'articolo si fa confusione tra REST e WebServices.
REST è una linea guida per sviluppare correttamente servizi internet. Detto questo, si dovrebbero seguire i principi rest per sviluppare bene siti web e web services. Non c'e' invece una differenza tra Rest e WebServices proprio perchè Rest non è uno standard come invece sono gli standard WS-*. Quando si progetta un WebServices seguendo le linee guide Rest, è sempre consigliabile definire contratti, schemi e descrizioni. L'articolo invece suggerisce una vaga differenza tra un servizio Rest (che comunque non esiste proprio perchè non esiste uno standard rest) e un "normale" web services dicendo erratamente che quest'ultimo è più rigoroso. Articolo da rivedere.

infatti non intendevo parlare di standard, quanto di differenti scelte implementative (ed architeturali). se è vero che utilizzando un servizio (WCF o web services asmx che siano, rimanendo nell'ambito del .NET Framework) puoi scegliere di sfruttarlo in chiave REST, è pur vero che non è necessario per forza, in un'ottica REST, sviluppare con un servizio. ne sono un esempio le mille mila API che si trovano in giro sui sistemi di social networking che utilizzano POX RESTful, non hanno schemi, contratti o WSDL, ma semplicemente una documentazione a corredo. ed a scanso di equivoci, ho inteso, come comunemente si fa, con il termine web service quei servizi basati su SOAP.

infine, non è detto che bisogna seguire per forza REST per fare un sito web o un servizio in maniera corretta e soprattutto non è detto che un servizio debba per forza usare REST. quello che ci si dimentica è che il binding di un servizio non è per forza HTTP, anzi spesso in ottica SOA non lo è affatto, se le performance contano.

infine, in chiave Windows Live questo fa ancora meno differenza, perchè di fatto nella maggior parte dei casi le API sono fornite con REST/POX. quello che si intedeva sottolineare è che nella maggior parte dei casi non si userà SOAP, quindi non si sfrutterà un servizio come si è abituati a fare usando un web service, ma lo si dovrà fare andando a recuperare nella documentazione.
se ne è già discuso tempo, ti invito a leggere i commenti di Alessandro Catorcini, Lead Architect in Live Search, a questo post.

Daniele Bochicchio ha scritto:

se ne è già discuso tempo, ti invito a leggere i commenti di Alessandro Catorcini, Lead Architect in Live Search, a questo post.

Lo farò grazie.
Per il resto, prendi il mio intervento come un feedback che non sempre deve essere positivo. L'impressione che ho avuto io è quella che ho ribadito anche nel mio ultimo intervento. Ci mancherebbe che si debbano per forza usare WS per rendere fruibili i contenuti, quindi ben venga REST per semplificare la vita allo sviluppatore quando non è necessario un WS. Quando invece è necessario (vedi sicurezza e altri servizi offerti dai vari WS-*) meglio imparare a disegnare il WS seguendo l'architettura REST.