44 messaggi dal 27 novembre 2010
Ciao a tutti,

mi servirebbe un consiglio.

Devo realizzare una serie di servizi che permettano principalmente di eseguire query di inserimento, update e select su un database remoto ( sicuramente Azure Sql).
Tali servizi dovranno essere accessibili da diversi dispositivi, come smartphone, terminali con wince o android e da normali PC.

Per farvi un esempio pratico, gli smartphone leggeranno un TAG RFid e dovranno far visualizzare a schermo delle informazioni che sono residenti su Azure (a seconda del terminale vorrei creare una webapp o un'app nativa)quindi faranno solo una select , i terminali wince o android potranno sia leggere che scrivere sul Database remoto (select, insert, update), per i PC invece creerò un sito web che si interfaccerà direttamente sul DB.

Come tecnologia al momento ho sempre utilizzato WCF, ma visto che si tratta di interfacciare hardware con diverse tecnologie e visto che la mole di dati da scambiare è esigua (sia per le insert, update e select) sarei quasi intenzionato a buttarmi sull'utilizzo delle Web API 2.

Quali sono i pro e i contro nell'utilizzo di questo approccio?

Marco Morgia
11.885 messaggi dal 09 febbraio 2002
Contributi
ciao Marco,

marco.morgia ha scritto:

sarei quasi intenzionato a buttarmi sull'utilizzo delle Web API 2.

Hai ragione, Web API 2 è abbastanza semplice da consumare, anche da client non .NET. L'essenziale è che un dispostivo riesca ad inviare delle richieste web, perché poi il contenuto di richiesta e risposta è del banale JSON, quindi molto succinto e facile da comprendere.

Anche un WCF Data Service sarebbe indicato e semplice da consumare, ma credo che con Web API ti troverai abbastanza bene perché è più facile da configurare ed estendere. Eventualmente puoi usare Web API in un Azure Mobile Service, che è pensato proprio per realizzare backend di applicazioni mobile e ti costerà meno rispetto ad un normale WebRole.

Se vuoi saperne di più, il prossimo 23 aprile ci sarà un evento dedicato ad Azure in varie città d'Italia in cui si parlerà anche di Mobile services e, in generale, di accesso ai dati su Azure.
http://www.communitydays.it/events/azure-2015/


marco.morgia ha scritto:

Quali sono i pro e i contro nell'utilizzo di questo approccio?

I pro di ASP.NET Web API sono:
  • La API risulta facile da consumare da tutti i dispositivi
  • Puoi contare sulla sintassi di interrogazione OData, che ti permette di creare elenchi filtrabili, ordinabili e paginabili col minimo sforzo
  • Puoi proteggere la tua API con vari tipi di autenticazione, compresi quelli basati su login provider esterni
  • I messaggi sono succinti, quindi le comunicazioni richiedono poca banda
  • Se scegli di usare un Azure Mobile Service, hai anche altre possibilità, tipo sfruttare le push notifications verso gli smartphone.


I contro sono:
  • Non supporta tutte le funzionalità avanzate di WCF, tipo crittografia a livello di messaggio (dovrai invece proteggere le comunicazioni a livello di trasporto, con un certificato SSL);
  • Nonostante supporti il batching, le transazioni non sono supportate quindi molteplici richieste POST/PUT/DELETE non potranno essere eseguite in maniera atomica.


ciao,
Moreno

Enjoy learning and just keep making
44 messaggi dal 27 novembre 2010
Ciao,

grazie per la risposta. Ok... mi hai convinto.. userò Web Api 2

Marco Morgia
44 messaggi dal 27 novembre 2010
BrightSoul ha scritto:
ciao Marco,

marco.morgia ha scritto:

I contro sono:
  • Non supporta tutte le funzionalità avanzate di WCF, tipo crittografia a livello di messaggio (dovrai invece proteggere le comunicazioni a livello di trasporto, con un certificato SSL);
  • Nonostante supporti il batching, le transazioni non sono supportate quindi molteplici richieste POST/PUT/DELETE non potranno essere eseguite in maniera atomica.


ciao,
Moreno



Ciao, continuo sempre su questo post anche se l'argomento è leggermente diverso (comunque sia è sempre legato all'utilizzo delle web api ).

Proprio per quanto riguarda rendere "sicuro" il mio servizio, oltre ad utilizzare un certificato HTTPS, volendo rendere alcuni metodi accessibili solo agli utenti che sono autorizzati, come posso procedere?
Utilizzo le membership ?
Utilizzo ASP.NET Idendity?
Controllo personalizzato?

Considera che sto parlando di un'applicazione dove difficilmente mi servirà una cosa tipo il "social login".

Grazie
Modificato da BrightSoul il 11 aprile 2015 01.46 -

Marco Morgia
11.885 messaggi dal 09 febbraio 2002
Contributi
Ciao Marco,
dipende da chi sono i tuoi client.

Se sono applicazioni web che girano nel browser, allora puoi emettere un cookie di autenticazione. Quello sarà il titolo che il client ripresenterà al server in tutte le successive richieste.

Per emettere un cookie di autenticazione puoi usare ASP.NET Identity, che ti offre anche un sistema di membership e roles completo, oppure puoi usare FormsAuthentication nuda e cruda (ovvero il metodo FormsAuthentication.SetAuthcookie) e gestire gli utenti nel modo che preferisci.

Ti consiglio di dare un'occhiata ad ASP.NET Identity, che diventerà il sistema canonico per gestire gli utenti. Occhio però, se vai in hosting condiviso probabilmente non riuscirai ad usarlo perché richiede che la tua applicazione giri in full trust. In quel caso puoi usare un sistema personalizzato per controllare le credenziali di login, e poi emetti un cookie via FormsAuthentication.

Se invece i tuoi client sono applicazioni server o dispositivi per l'IoT, allora puoi valutare anche altri meccanismi, tipo introdurre una API Key, come descritto in questo articolo di Marco De Sanctis.
http://www.aspitalia.com/script/1134/Proteggere-Chiave-Servizio-ASP.NET-Web-API.aspx

ciao,
Moreno
Modificato da BrightSoul il 11 aprile 2015 01.53 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.