Perché dovrei creare operazioni WebAPI asincrone invece di sincronizzare quelle?

Ho la seguente operazione in un'API Web che ho creato:

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public CartTotalsDTO GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
    return delegateHelper.GetProductsWithHistory(CustomerContext.Current.GetContactById(pharmacyId), refresh);
}

La chiamata a questo servizio web viene effettuata tramite una chiamata Ajax Jquery in questo modo:

$.ajax({
      url: "/api/products/pharmacies/<%# Farmacia.PrimaryKeyId.Value.ToString() %>/page/" + vm.currentPage() + "/" + filter,
      type: "GET",
      dataType: "json",
      success: function (result) {
          vm.items([]);
          var data = result.Products;
          vm.totalUnits(result.TotalUnits);
      }          
  });

Ho visto alcuni sviluppatori che implementano l'operazione precedente in questo modo:

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public async Task<CartTotalsDTO> GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
    return await Task.Factory.StartNew(() => delegateHelper.GetProductsWithHistory(CustomerContext.Current.GetContactById(pharmacyId), refresh));
}

Devo dire, però, che GetProductsWithHistory () è un'operazione piuttosto lunga. Dato il mio problema e il contesto, in che modo mi avvantaggia rendere asincrona l'operazione webAPI?

Nel tuo esempio specifico, l'operazione non è affatto asincrona, quindi ciò che stai facendo è asincrono su sincronizzazione. Stai solo rilasciando un thread e bloccandone un altro. Non c'è motivo per questo, perché tutti i thread sono thread del pool di thread (a differenza di un'applicazione GUI).

Nella mia discussione su "async over sync", ho fortemente suggerito che se si dispone di un'API implementata internamente in modo sincrono, non si dovrebbe esporre una controparte asincrona che avvolge semplicemente il metodo sincrono Task.Run.

A partire dal Devo esporre wrapper sincroni per metodi asincroni?

Tuttavia, quando si effettuano chiamate WebAPI async cui è presente un'effettiva operazione asincrona (di solito I / O) invece di bloccare un thread che si trova e attende un risultato, il thread torna al pool di thread e quindi in grado di eseguire qualche altra operazione. Tutto ciò significa che la tua applicazione può fare di più con meno risorse e questo migliora la scalabilità.

Un approccio potrebbe essere (l'ho usato con successo nelle applicazioni dei clienti) avere un servizio Windows che esegue le lunghe operazioni con i thread di lavoro, quindi farlo in IIS per liberare i thread fino al completamento dell'operazione di blocco: Nota, questo presume i risultati vengono memorizzati in una tabella (righe identificate da jobId) e un processo più pulito li ripulisce alcune ore dopo l'uso.

Per rispondere alla domanda: "Dato il mio problema e il contesto, in che modo mi avvantaggia rendere asincrona l'operazione webAPI?" dato che è "un'operazione piuttosto lunga" penso a molti secondi anziché a ms, questo approccio libera i thread IIS. Ovviamente devi anche eseguire un servizio Windows che a sua volta richiede risorse, ma questo approccio potrebbe impedire a un flusso di query lente di rubare thread da altre parti del sistema.

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public async Task<CartTotalsDTO> GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
        var jobID = Guid.NewGuid().ToString()
        var job = new Job
        {
            Id = jobId,
            jobType = "GetProductsWithHistory",
            pharmacyId = pharmacyId,
            page = page,
            filter = filter,
            Created = DateTime.UtcNow,
            Started = null,
            Finished = null,
            User =  {{extract user id in the normal way}}
        };
        jobService.CreateJob(job);

        var timeout = 10*60*1000; //10 minutes
        Stopwatch sw = new Stopwatch();
        sw.Start();
        bool responseReceived = false;
        do
        {
            //wait for the windows service to process the job and build the results in the results table
            if (jobService.GetJob(jobId).Finished == null)
            {
                if (sw.ElapsedMilliseconds > timeout ) throw new TimeoutException();
                await Task.Delay(2000);
            }
            else
            {
                responseReceived = true;
            }
        } while (responseReceived == false);

    //this fetches the results from the temporary results table
    return jobService.GetProductsWithHistory(jobId);
}