Perché utilizzare ASP.Net Web Api invece SignalR per il progetto interno

Question

Lo so, l'API Web ASP.NET è progettata per creare APIS riposante, mentre SignalR è per la comunicazione in tempo reale. Quindi non sono tecnologie concorrenti.

Immagina: stai creando un'applicazione client/server, stai scrivendo un client desktop che si connetterà a un server per eseguire alcune azioni. Le azioni sono avviate dal client, non dal server, quindi entrambe funzionano.

Se si tratta di un'applicazione interna e non si espone l'API, perché utilizzare Asp.Net Web Api invece SignalR?

In entrambi i metodi nel server verranno eseguiti quando il client li chiama. In Web Api come azioni nei controller, nel segnale R negli hub. Entrambi consentono di inviare parametri ai metodi e ottenere il risultato nel client.

Sapendo che il traffico in SignalR è un po 'più basso di un Web Api (perché in websocket la connessione HTTP è stabilita in modo permanente e non crea per ogni richiesta), vorrei andare a SignalR. Mi sto perdendo qualcosa?

Answer 1

La ragione più convincente per andare con un quadro come web api è la convenienza. Un vantaggio è la negoziazione del contenuto basata sull'intestazione della richiesta. Se lo chiedi, JSON ti restituirà automaticamente json. Lo stesso con xml o altri formati standard. Ha anche un ottimo sistema di formattazione che ti consente di supportare le esigenze personalizzate. È anche leggero sulla configurazione e facile da configurare.

Si potrebbe benissimo creare il proprio quadro o anche usare MVC, WebForms o qualsiasi altro modo di esporre un endpoint web, ma si farebbe il codice di solito dura il formato nella risposta (JSON, XML, HTML ecc)

In ogni caso, alla fine della giornata hai solo bisogno di qualcosa che parlerà in termini di http - request -> response.

Answer 2

Nei pro e contro, è necessario aggiungere la limitazione e la scalabilità di ciascuna soluzione. Non ricordo le cifre ma SigalR ha bisogno di molte risorse per mantenere la connessione soprattutto con il vecchio browser (5000 clients is the default limitation on IIS). Mentre con WebApi, ci si concentra su quante richieste si avranno invece di quanti client saranno connessi (anche se non fanno nulla).

WebApi è anche più semplice da scalare. Con SignalR, dovrai configurare uno backplane che possa diventare un collo di bottiglia.

In SignalR, se si mappa lo users and the connection, è consigliabile scegliere una soluzione che soddisfi i requisiti futuri se si prevede di aggiungere più server.

Answer 3

Da SignalR's official page:

ASP.NET SignalR è una libreria per gli sviluppatori ASP.NET che semplifica il processo di aggiunta di tempo reale funzionalità web alle applicazioni. Funzionalità web in tempo reale è la possibilità di disporre del codice del server di inviare il contenuto ai client connessi all'istante non appena disponibili, anziché attendere che un client richieda nuovi dati.

Nel modo in cui descrivi il tuo problema, non hai bisogno di quelle funzioni. Dato che SignalR, per fornire tali funzionalità, ti fa perdere alcune utili caratteristiche HTTP (memorizzazione nella cache, negoziazione del contenuto, ...) che potresti sfruttare per il tuo problema, vorrei andare con WebAPI.

Answer 4

Perché non entrambi?

È possibile utilizzare WebAPI per fornire dati di massa e SignalR come elemento opzionale per fornire aggiornamenti nei dati. Pertanto, forniresti entrambe le funzionalità, il primo REST per consentire ai consumatori di terze parti e offrirai anche una tecnologia push come SignalR o direttamente WebSockets, per consentire ai chiamanti di iscriversi alle modifiche in determinati set di dati.

Si prega di tenere presente che SignalR non è solo WebSocket, anche se, per poter essere utilizzato, è necessario Windows 8 o Windows 2012 come server. Altrimenti, ricadrà su un altro trasporto che potrebbe non funzionare come pensi. Inoltre, come ha sottolineato Daniel, la scalabilità di SignalR è ... gentile o limitata, e persino la propria documentazione afferma che non si dovrebbe usare per scenari in tempo reale o dati molto segmentati. SignalR è solo per le trasmissioni generali, preferisco andare direttamente a WebSockets con l'API di Windows nativa se sei in Windows 8/2012 o un componente di terze parti.

Se il client è sempre l'iniziatore dell'azione e la frequenza delle richieste è irregolare o non elevata, probabilmente l'approccio di richiesta/risposta di REST semplifica molto le cose. Altrimenti, il client fa richieste molto spesso e/o con un tasso costante, quindi usa un WebSocket, ma dovrai lavorare un po 'di più.

Answer 5

SignalR è eccessivo nella maggior parte dei casi per richiesta/risposta, vorrei andare con REST. E quindi utilizzare SignalR per gli aggiornamenti push.

Per gli aggiornamenti push È possibile SignalR astratto con questa libreria (Im l'autore) https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy