utilizzando asp.net mvc per endpoint basato su REST

Question

Sto cercando di utilizzare ASP.Net MVC come piattaforma per un servizio basato su REST. So che WCF ha costruito supporto per i servizi REST; tuttavia, sto cercando di restituire più tipi di dati a seconda della richiesta.

Desidero che il client richieda il tipo di contenuto. Quindi, se mandassero text/html, ad esempio, renderei il mio modello in Html, se richiedessero text/xml restituirebbe xml. Potremmo anche fare JSON.

Qualcuno vede qualche problema con questo?

Non utilizzare WCF potrebbe aumentare la complessità del client quando si chiama il servizio poiché non sarà in grado di generare automaticamente un proxy; tuttavia, nel mio caso, i client saranno browser che richiede html o librerie client java che elaborano l'xml.

Poiché non si utilizza WCF, è necessario proteggere il servizio; tuttavia, sto pensando che possiamo farlo usando l'autenticazione dei moduli.

Il vantaggio di questo è che non importa che tipo di dati che il client sta richiedendo è tutto sta attraversando gli stessi controllori/modelli ecc ...

Answer 1

Dopo aver letto il post di Haack, sull'uso delle estensioni per indicare il tipo di contenuto, penso che sia meglio disattivare l'intestazione Accetta. Sembra più Rest'ish per me, anche se è un po 'più difficile attivare un browser e testare il tuo URL.

Attraverso un piccolo articolo di blog su come farlo e utilizzando un ModelBinder per astrarre HttpContext dal controller: http://jberke.blogspot.com/2009/03/aspnet-mvc-model-binder.html.

Inoltre, in risposta al commento di opt-in di Troy, stavo usando la vista per il rendering di Xml del mio modello. Questo mi ha permesso di avere diversi formati xml per lo stesso modello. Il che ha senso. Cosa fare se è necessario supportare il controllo delle versioni o formati diversi per diversi client. Non mi piace l'idea del framework che rende automaticamente qualsiasi cosa.

Answer 2

si potrebbe desiderare di dare un'occhiata a questo post del blog e la discussione che segue da Phil Haack:

http://haacked.com/archive/2009/01/06/handling-formats-based-on-url-extension.aspx

suo codice utilizza il file richiesto estensione (.html, .json, .xml) per determinare l'uscita, ma si potrebbe facilmente utilizzare Accept-Encoding (o entrambi).

Nota: Ho lasciato un commento sul post di Phil e sento ancora fortemente che le azioni dovrebbero essere richieste per "opt-in" a quali metodi di rendering supportano. Con il rendering HTML puoi controllare la quantità di viewdata visualizzata all'utente finale. Il rendering XML/JSON probabilmente renderà tutto ciò che si passa nei viewdata, indipendentemente dal fatto che si intenda renderlo pubblicamente visibile o meno.

Answer 3

La soluzione di Haack non è certamente il modo migliore per farlo, sebbene sia un buon punto di partenza.

Per i principianti, se si lavora con Entity Framework (o si decide di passare da Linq a SQL in un secondo momento) JsonResult si interromperà perché non può serializzare i grafici degli oggetti con riferimenti circolari (in genere la maggior parte dei modelli di dati). In secondo luogo, espone più endpoint per la stessa risorsa.

Il modo corretto per eseguire questa operazione è visualizzare l'intestazione HTTP X-Requested-With per determinare se si tratta di una richiesta XHR. Oppure intestazione di richiesta Content-Type: text/xml per XML.

Si consiglia di installare il plug-in per Firefox per REST testing che simula le richieste XHR. Il plug-in Tamper Data e alcuni altri consentono un maggiore controllo per test/debug. WFetch è uno strumento di richiesta HTTP non elaborato che è anche essenziale per il test e il debug.

Ho scritto un JSON/POX action filter per fare proprio questo. Hai solo bisogno di decorare le tue classi o metodi con l'attributo [JsonPox] e saranno automaticamente esposti come JSON o XML a seconda del client.