Utilizzo di WebAPI o MVC per restituire JSON in ASP.NET

Sto creando un'applicazione ASP.NET MVC che è pesante per gli script client, che utilizzerà JSON e jQuery per manipolare il DOM.

La mia comprensione è sia API di controllo Web e MVC controller possono tornare JSON.

Dato il mio scenario, dovrei usare un controller API Web o un controller MVC ?

I controller API Web possono essere creati e ospitati in qualsiasi applicazione ASP.NET, non solo nelle applicazioni MVC. Pertanto, un ovvio motivo per creare un'API Web è se non si dispone di un front-end MVC (ad es. Servizi Web classici e RESTful ospitati dalla propria azienda / organizzazione).

I controller MVC si basano in genere sul framework MVC, se si osservano i modelli predefiniti e la maggior parte del lavoro svolto dalla comunità e dai propri colleghi, si noterà che quasi tutti i controller MVC sono implementati tenendo presente la vista.

Personalmente, utilizzo i controller MVC quando intendo rispondere con una vista () e utilizzerò un'API Web per tutto ciò che non dipende da una vista particolare.

Ci sono avvertimenti, ovviamente, ma in generale se non si richiede il comportamento di Model Binding di MVC, il servizio è incentrato sui dati e le operazioni sono incentrate sui dati (ad es. Operazioni CRUD), quindi probabilmente si desidera un "controller API Web" "anziché un" Controller modello-vista ". Al contrario, se le tue operazioni sono View-centric (ad es. Consegna di una pagina di amministrazione utente all'utente), o hai bisogno del Model Binding di MVC per generare "ajax parziali" (molto improbabile), allora vorrai un controller MVC.

Personalmente, utilizzo i controller API Web per guidare i client RESTful basati su JSON, utilizzo i controller MVC per gestire il routing del browser di base e la consegna della SPA.

WebAPI serve per creare un'API. Se vuoi che qualcuno sia in grado di consumare la tua API in XML, JSON, ecc. Puoi creare un'API Web.

Nel tuo caso devi solo parlare con il cliente in JSON.

Anche se il tuo sito web è principalmente basato su script client, utilizzeresti comunque il controller MVC ASP.NET giusto? E dal momento che potresti aver già diviso logicamente i tuoi controller in base alle entità, allora ha senso aggiungere quei metodi che servono json in esso invece di creare un'altra classe specificamente per API web.

Quindi, per la tua situazione particolare (se ho capito bene), rimarrei con i controller.

La risposta si riduce alla separazione delle preoccupazioni, accelera la creazione di servizi e fa affidamento sulla convenzione piuttosto che sulla configurazione.

La responsabilità principale dei controllori è quella di lavorare come coordinatore tra vista e modello, ma dove la responsabilità principale dell'API è quella di lavorare sui dati. Nel caso delle convenzioni API, è davvero semplice eseguire operazioni CRUD. Di seguito è riportato il mapping tra operazione CRUD e azioni HTTP

• Essere letto
• POST: Crea
• PUT: aggiornamento
• ELIMINA: Elimina

Pertanto, con le API non è necessario creare azioni separate e attribuirle con azioni HTTP.

L'unica preoccupazione che ho con ApiController è che si basa sul sito e non sull'area. Un sito può avere solo una sottocartella apicontroller per poter assegnare un nome ai metodi del controller. Esistono situazioni in cui potresti voler duplicare il nome del controller in diverse aree:

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

Ricordo che ci sono alcune impostazioni di codice personalizzate per poterlo fare ma non funziona di default.

Sono d'accordo con la risposta (risposta migliore) di Shaun Wilson, ma non so perché perché sono solo un po 'confuso e sto ancora cercando di capire con la seguente premonizione (probabilmente errata) -

• Utilizzare il controller WebAPI per fornire i dati JSON al client in modo che il client possa gestire la manipolazione della vista. Questo processo NON richiede una vista ma piuttosto solo una risposta a qualunque cosa abbia chiamato il metodo (cioè una richiesta javascript) in modo che il client possa gestire qualsiasi manipolazione sul lato client.
• Utilizzare il controller MVC quando è necessario utilizzare i dati per manipolare una vista durante o subito dopo page_load (ovvero non per le app SPA).

Vedete, non so come sia sbagliato qui e sono confuso perché l'ultima riga della risposta di Shaun afferma "Uso i controller MVC per gestire il routing del browser di base e la consegna della SPA". - forse non so perfettamente cosa sia un client riposante quando suppongo che potrebbe essere il metodo JavaScript a ricevere una risposta in formato JSON. questo è il post più vicino in StackOverflow che è stato collegato in remoto come risposta alla mia domanda, quindi rispondo a questo post invece di duplicare le domande.

In questo scenario, consiglierei WebApi in quanto è perfetto per il trasferimento di dati come questo basato su richieste Javascript. Di solito svilupperò i miei controller WebApi in modo che restituiscano un oggetto compatibile con JSON che può quindi essere analizzato facilmente dal mio Javascript.

L'unico momento in cui vorresti usare un'azione su un controller MVC per questo genere di cose sarebbe se volessi generare un po 'di HTML e sostituire segmenti della tua pagina con chiamate Javascript.

Per esempio:

Hai un Datepicker dell'interfaccia utente di JQuery che, se selezionato, genera un elenco di pulsanti di opzione che rappresentano gli eventi nel giorno scelto.

In questo scenario, è possibile utilizzare WebApi per restituire un codice JSON e quindi generare l'HTML necessario utilizzando Javascript, ma in genere è una pratica scorretta creare molto HTML utilizzando Javascript. Sarebbe molto meglio che C # costruisse il codice HTML e poi lo restituisse tramite una vista parziale poiché in questo modo è meno probabile che si verifichino errori con l'analisi Javascript. Per non parlare del fatto che l'HTML è molto più semplice da scrivere.