Newsgroup: it.comp.www.php
Titolo: E' necessario un Web Service?

Vorrei inviare dati da una app Android a un database remoto (per esempio 
MySQL).
E' necessario che sul server MySQL sia installato un Web Service?
Il Web Service puo' essere scritto in PHP?
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 
 
No, basta configurare il server MySQL per essere accessibile da remoto.
 
Ciao!

 Il Web Service puo' essere scritto in PHP?
 
si, prova a dare un occhiata a ZF apigility, è un Framework/RAD per 
scrivere velocemente ed in modo organizzato ed organico web service, sia 
RPC che REST
 
Ciao
 

 Ciao!
 
 
Puoi spiegarmi per favore come si fa a configurare il server MySQL ad 
essere accessibile da remoto?
 
Considera che l'app Android invia i dati come GET o POST.
Ciao.


 
 
Perché mai?
 
Ciao!

 Ciao
 
 
Non ho le idee chiare:
 
prima di tutto mi spieghi cos'e' un Web Server?
Poi mi spieghi la differenza tra RPC e REST e, soprattutto, cos'e' REST?
 
Ciao e grazie.


 
 
Se si può connettere ad un DB locale, si può anche connettere ad un DB remoto.
 
Ciao!

 Ciao e grazie.
 
 
ERRORE, invece di "Web Server" volevo dire "Web Service", scusate.


 
 
Tu mi spieghi invece come puoi anche solo immaginare di poter scrivere una app
senza sapere questa roba? :|
Nessuno nasce imparato, posso capire che uno non c'ha voglia di studiare, ma
per decenza almeno cerca su wikipedia al volo e fai finta, così fa proprio
cascare le braccia..
 
Ciao!


per diversi motivi.
 
il primo è la sicurezza, non esponi direttamente il DBMS a possibili 
attacchi.
 
inserendo un layer di separazione tra la presentazione e i dati, puoi 
meglio organizzare la logica di business.
 
non ti costringe ad avere tutta la business logic nel client.
 
le password del dbms rimangono sul server, se invece accedi direttamente 
sul server dal client, immagina un malintenzionato che effettua lo 
spoofing dei dati, ecco che si ritrova user e pass del dbms.
 
per effettuare qualsiasi modifca al db o business logic, non devi per 
forza modificare il client (pensa agli aggiornamenti non tutti li fanno 
e li fanno nella stesso momento).
 
la possibilità di versionare il web services in modo tale che un 
eventuale modifca sostanziale della BL o del db, continua a funzionare 
anche a chi non ha aggiornato l'app.
 
e tanti altri
 
Ciao
 
 
 
 
 

 Ciao!
 
 
Per favore mi spieghi cos'e' REST?
Anche su Wikipedia se clicci su "Discussione" c'è scritto che la 
spiegazione NON e' per niente chiara.
 
L'app Android che vorrei scrivere invia i dati come GET o POST, io 
vorrei creare un programmino in PHP (quello che
io ho chiamato - forse sbagliando - "Web Service") che con $_GET[] o 
$_POST[] intercetta i dati inviati e li
scrive sul database MySQL.
 
Ciao.



Fai parte dell'UCAS? :)
Scherzo, sono in molti che la pensano come te, ma secondo me è chiaramente
overengineering.
 
Vediamolo punto per punto.
 
Per quanto riguarda la sicurezza: meglio la sicurezza fornita dal server MySQL
che quella costruita custom per un webservice o una app (cosa vera in generale,
fatta poi da chi non sa cos'è un webservice, immagina te). Vorrei vedere chi
riesce a tirare su un sistema più sicuro di quello fornito di default da MySQL.
Che poi, parli di password: ma le password per accedere al webservice? Non è
esattamente la stessa cosa? :)
 
Per la cosa della business logic sul client: a livello architetturale la cosa
migliore è avere la BL in *un solo* posto. Se non vuoi metterla sul client
(quello che si chiamava "fat client" tempo fa) è giusto, son d'accordo anch'io,
ma allora va messa in un servizio su un server apposito, e crei un thin-client.
Altrimenti con un web-service d'interfaccia dividi la tua BL tra lui e client,
o peggio tra lui, client e server.
 
Mi potresti dire che si parla solo della parte di BL relativa ai dati: anche
in questo caso basta integrarla nel DBMS, con views o stored procedures. Fai
anche le cose più pulite.
 
Per lo sversionamento, tutto quello che fai in codice lo puoi fare anche con
i DB, non è un problema.
 
Per i "tanti altri", aspetto :)
 
A stringere: non bisogna mai aggiungere un layer se non è strettamente
necessario.
 
Ciao!

 
 
Di solito si pensa al problema e si trovano le possibili soluzioni, te stai
cercando di risolvere una soluzione. Non mi pare una buona strada.
Ma se vuoi farlo così fallo così, che ti devo dire? :)
 
Ciao!


per web service si intende un servizio esposto tramite protocollo HTTP 
(web appunto).
per servizio si intende un programma che si trova in attesa di ricevere 
deile istruzioni, a seconda del tipo di istruzioni effettua determinate 
operazioni e risponde con i risultati.
 
RPC (remote procedure call) in genere è una chiamata ad una procedura in 
remoto al quale in genere si passano dei parametri e proprio questi 
parametri stabiliscono come la procedura si deve comportare.
 
http://miaapi.com/cliente?tipo=edit&id=12
 
http://miaapi.com/cliente?tipo=delete&id=55
 
 
in questo caso la procedura 
http://miaapi.com/cliente
 
e i paramentri (tipo, id) stabiliscono cosa deve fare
 
in REST si chiama una risorsa
 
http://miaapi.com/cliente/edit/12
 
http://miaapi.com/cliente/delete/55
 
 
questo a grandi linee e nell'eccezione comune di RPC in ambito web.
 
 
per REST o RESTfull (stessa identica cosa)
si identifica una risorsa URI univoca.
 
la correttenza nell'utilizzo del paradigma REST si trova nella singola 
chiamata alla risorsa che deve contenere lo stato, poiche questo non si 
deve trovare nel server.
 
ti faccio un esempio per capire meglio.
quando in una normale applicazione viene effettuato il login lo stato di 
avvenuto login viene generalmemte salvato sul server (tramite sessione), 
e le operazioni che vengono successivamente effettuate, fanno 
semplicemente un controllo se esiste lato server la sessione, in questo 
caso lo stato (l'essere loggato) si trova sul server.
 
nel paradigma REST questo non deve avvenire.
 
Ciao


Non voglio entrare nella diatriba "mysql diretto vs REST". Per ora. :P
 
Il problema grosso è che Android non ha un client MySQL, e per usare MySQL 
direttamente bisogna trovare una libreria Java e cercare di infilarla in 
un'app Android.
 
Per me è più semplice scrivere un servizio REST. :D
 
Magari per uno sviluppatore Java o Android esperto è più facile adattare 
la libreria.
 
C'è poi da considerare la configurazione di MySQL con SSL.
 
Insomma, per rispondere a Bracco Baldo: se è per fare esperimenti per 
conto tuo, prova entrambe le soluzioni.
Se lo fai per lavoro: fallo fare a qualcun altro.
 
Bye.

 che quella costruita custom per un webservice o una ap
 
Inoltre così facendo hai anche introdotto altri livelli suscettibili di 
vulenrabilità: server web, interprete php, il programma scritto ad hoc.
 
È un po' come quel vecchio scherzo informatico: hai un problema, 
aggiungi un livello di astrazione, ora hai due problemi.
 
-- 
Andrea
 

 Ciao
 
 
GRAZIE bramante per la spiegazione.
Credo di aver capito cos'e' un Web Service (il mio programmino PHP che 
intercetta i dati inviati dall'app e li
scrive sul database MySQL e' un Web Service, giusto?), pero' NON ho 
capito cos'e' REST, potresti spiegarti
meglio per favore?


Il giorno venerdì 25 marzo 2016 09:28:54 UTC+1, Andrea D'Amore ha scritto:

Hehe pensavo che ci vuole un bel coraggio parlare male di astrazioni e 
livelli nel ng di un linguaggio interpretato, utilizzato principalmente 
come middleware.
Se davvero le astrazioni sono una cattiva idea perché non scrivi direttamente 
in assembler senza appoggiarti a un kernel? i tuoi programmi 
miglioreranno, specie in sicurezza :)
 
Scherzi a parte, io lo devo trovare un sistemista che mi esponga la porta di un 
database all'esterno di una rete, ma forse sono all'antica.
 
 
 


 
Al contrario, se fosse "all'antica" il DB sarebbe probabilmente accessibile,
la moda di tirare su middleware per ogni cosa è abbastanza recente :)
 
Ciao!
 
 
P.S. Comunque, tanto per far più chiarezza su quello che penso, non dico
che scrivere un WS sia un'idea sbagliata in generale, ha senso se si sposta
tutta la logica dentro e i client comunicano solo con lui; ha senso se si
sceglie questo tipo di architettura per tutta l'applicazione. Ma farne uno
solo per interagire con un DB invece è stupido, visto che il DBMS ha già di
suo questa funzionalità.
La domanda dell'OP era "ho bisogno di un WS per parlare con MySQL?" e la
risposta è ovviamente "no, non c'è bisogno" :)
 

 porta di undatabase all'esterno di una rete, ma forse sono all'antica.
 
Mah, in effetti esporre mysql non piace molto nemmeno a me come idea, 
ma d'altro canto è un servizio che va su rete, quindi pur di 
configurare bene l'utenza (ad esempio dandogli solo il grant per la 
insert su quella specifica tabella) potrebbe non essere un'idea balzana.
 
Semmai il problema è quello sollevato che non c'è una libreria mysql 
direttamente sulla piattaforma, quindi la deve includere 
nell'applicazione. A quel punto è molto meglio parlare HTTP che è la 
lingua franca di oggi.
 
-- 
Andrea
 

 
 
Questo è ovvio, se non si può connettere né in locale né in remoto non c'è
molto altro da fare! :D
 
Ciao!

vulenrabilità: server web, interprete php, il programma scritto ad hoc.
 
Da un lato è vero. Dall'altro hai anche sostituito una architettura generalista con
una serie di strati specialistici.
 
Una app Android che mantenga una comunicazione con un server MySQL mi sembra una di
quelle situazioni a cui sia gli sviluppatori Android che quelli MySQL hanno pensato
poco.
 
 
http://labs.mysql.com/?id=3
 
 
Tant'è che scrivono "NOT FIT FOR PRODUCTION".
 
L'altra possibilità, che Android parli tcp/3306, è ugualmente irta di problemi. Per
dire, tcp/3306 è parecchio meno ubiqua di HTTP, specie su sistemi captive o che per
ennemila motivi fanno proxying e/o addirittura rewriting. Sicché si rischia di fare
una app che però poi ti funziona solo (esempio estremo) da casa tua.
 
O si introducono comunque ulteriori strati tipo SOCKS/VPN - il che però nega un po'
il concetto di non introdurre strati, oltre a non risolvere problemi tipo latenza e
ripristino.
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 risposta è ovviamente "no, non c'è bisogno" :)
 
 
Io all'OP gli consiglierei di farsi un bello stratolino lato server, probabilmente 
con il tuo consiglio consegnerebbe prima e il suo programma sarebbe anche 
più veloce, ma io non sarei tranquillo.
 

 insert su quella specifica tabella) potrebbe non essere un'idea balzana.
 
Ho già espresso nel commento a fma la mia opinione, ovvero
se i privilegi d'accesso sono nel client li rendi accessibili a 
chiunque, a quel punto i dati dell'insert non sono più moderati dal tuo 
codice lato client. Ti faccio un programmino php che ti tempesta di insert 
con id casuali e la tua base dati diventa inutilizzabile.


 spiegarti meglio per favore?
 
REST non è facile da spiegare. Nemmeno il suo creatore è riuscito a 
spiegarlo bene, e infatti continua a lamentarsi che la gente chiama REST 
quello che REST non è. :)
 
REST (o meglio, RESTful) significa sul server non deve essere tracciato lo 
stato della connessione.
 
Per esempio, se stai facendo un ecommerce, il carrello non deve essere 
salvato sul server, ma passato a ogni richiesta.
 
Esempio di sequenza di chiamate normali:
 
GET /prodotti/?id=123
 
Ritorna { prodotti: [ {id: 123, nome: 'Nome prodotto'}, {...} ]
 
 
POST /carrello/
{id: 123}
 
Ritorna un redirect a GET /carrello/
 
(chiamata automatica del browser): GET /carrello
 
Ritorna { carrello: [ 123 ] }
 
 
POST /carrello/
{id: 987 }
 
Ritorna un redirect a GET /carrello/
 
(chiamata automatica del browser): GET /carrello
 
Ritorna { carrello: [ 123, 987 ] }
 
 
E continua così finchè hai riempito il carrello.
 
In un'ambiente REST, se fai la sequenza
 
POST /carrello/
{id: 123}
 
POST /carrello/
{id: 987 }
 
Questa seconda chiamata ti torna { carrello: [ 987 ] }
 
Come vedi manca l'123, perché lo stato non viene mantenuto sul server.
 
Per ottenere lo stesso risultato, devi fare
 
POST /carrello/
[{id: 123}, {id: 987}]
 
E quindi elencare tutti i prodotti ad ogni chiamata.
 
 
Per essere pignoli, quello del login non è un esempio perfettamente 
valido, perchè in una situazione non-RESTful fai login e ti viene 
assegnato un session-id, mentre in una situazione RESTful devi comunque 
fare login e ti viene assegnato un token, una API key o una coppia token
+key per HMAC (o simile) che poi dovrai passare (come il session-id) a 
ogni chiamata.
 
Sono sicuro che ancora non è chiarissimo. Devi sbatterci la testa per 
capirlo. :)
 
Bye.
 
 
 

 ...
 
 
GRAZIE Alessandro per la spiegazione.
 
Il programmino PHP che con $_GET[] o $_POST[] intercetta i dati inviati 
dall'app Android e li scrive sul
database remoto MySQL e' un Web Service vero?


 vero?
 
Tecnicamente un WebService è qualsiasi software che usi il protocollo HTTP 
e che sia progettato per far comunicare due macchine, senza 
necessariamente l'intervento umano.
 
Di solito per WebService si intende un server che supporti SOAP o REST, ma 
ogni tanto qualcuno si inventa un protocollo nuovo. :)
 
Bye.

 Bye.
 
 
GRAZIE Alessandro.
Potresti consigliarmi dei tutorial (meglio se in italiano ma vanno bene 
anche in inglese) che spieghino
chiaramente cos'e' SOAP, REST e compagnia bella?



nb.. ricorda il firewall devi aprire l'apposita porta 
 
enrico