Voglio scrivere una nuova API in stile REST e ho guardato ServiceStack e abbastanza simile. Tuttavia, ho visto che Microsoft ha rilasciato il progetto API Web ASP.Net come parte della nuova versione beta di MVC 4. Qualcuno ha esaminato il nuovo progetto API Web? Puoi dare dei pro / contro di ciascun sistema?
Risposte:
Hanno casi d'uso molto simili, in quanto responsabile principale del progetto ServiceStack. Ho una buona conoscenza dei vantaggi di ServiceStack e dei numerosi vantaggi naturali della sua progettazione basata sui messaggi .
ServiceStack esiste fin dal 2008 come progetto gestito da OSS sin dall'inizio con un unico obiettivo di promuovere la progettazione e l'implementazione corrette di servizi remoti senza attrito.
Alla ricerca della massima semplicità, è costruito attorno a un nucleo semplice ed elegante - con la maggior parte delle sue caratteristiche naturalmente vincolanti per i tuoi modelli , non per i tuoi controller - che è ciò che MVC, WebApi fa (così come ogni altro Web Service Framework che Microsoft ha prodotto ).
L'adozione di un design basato su messaggi offre un approccio superiore per i servizi remoti, in quanto promuovono servizi più estensibili e meno fragili, semplificano gli schemi di accesso e di chiamata e contengono molti altri vantaggi naturali che ottieni gratuitamente .
Come missione principale, combattiamo la complessità in ogni fase, con l'obiettivo di mantenere un'API invisibile e non intrusiva ed evitare di introdurre nuovi concetti o costrutti artificiali che non sono già familiari agli sviluppatori di servizi Web o Web oggi.
Ad esempio, l' IService<T>implementazione del servizio è solo una classe C # standard con dipendenze cablate automaticamente. I wrapper sottili e leggeri vengono utilizzati per fornire un'API coerente e unificata attorno ai tipi IHttpRequest e IHttpResponse di runtime core . Consentono inoltre l'accesso alle classi di richiesta e risposta ASP.NET o HttpListener sottostanti in modo da non essere mai limitato quando si utilizza ServiceStack.
Ecco una breve panoramica degli stili API contrastanti promossi da ServiceStack e WCF . WebApi è diverso da WCF in quanto incoraggia la progettazione di API REST-ful. Per quanto riguarda gli esempi tra i 2, questo è l'unico esempio noto che ho con lo stesso servizio scritto in ServiceStack e WebApi .
ServiceStack si concentra principalmente sulla semplicità, sulle prestazioni e nella promozione delle migliori pratiche di servizi web / remoti incentrati sull'abbraccio dei modelli di progettazione dei servizi remoti Martin Fowlers nel modo più idiomatico possibile:
Il modello di facciata - che suggerisce l'uso di interfacce batch e a grana grossa quando si comunica attraverso i limiti del processo.
Il modello DTO ( MSDN ): dettare l'uso di POCO speciali per generare il formato wire delle risposte dei servizi Web.
Il modello di gateway ( MSDN ) per incapsulare le comunicazioni client e server tra i modelli client Gateway / DTO e livelli di servizio di interfaccia.
Questi schemi assicurano una netta separazione delle preoccupazioni e un'esperienza di sviluppo iterativa priva di attrito.
Un servizio Web ServiceStack al suo centro è incentrato su un'interfaccia C # pura priva di dipendenze e cablata automaticamente IService<T>che ti dà la completa libertà di definire il tuo contratto di servizio web con i tuoi DTO di richiesta e risposta usando POCO puliti - rendendo l'API di ServiceStack praticamente invisibile e non -invasivo, ovvero è banale estrarre la logica dei servizi C # ed eseguirla al di fuori di un host ServiceStack.
Questa sintesi è un buon esempio di ciò che ottieni con solo 1 classe C # .cs in ServiceStack :
Le classi RestServiceBase e ServiceBase hanno lo scopo di ospitare la tua logica C # personalizzata per il massimo riutilizzo potenziale possibile, ad es. Il suo design DTO-first consente banalmente l'esecuzione differita e proxy in cui il tuo stesso servizio C # può anche essere ospitato ed eseguito in un host MQ che è ciò che accade quando si registra un host RedisMQIMessageService simile e si chiama il servizio tramite l' endpoint (ad es/asynconewayclient.SendOneWay() nei client C #)
È inoltre possibile delegare e creare facilmente servizi compositi utilizzando il base.ResolveService<T>()metodo che restituisce un'istanza cablata automaticamente del servizio selezionato, come mostrato nell'esempio del servizio clienti Nortwind :
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
Per la maggior parte ServiceStack serializzerà la maggior parte degli oggetti C # come previsto: ecco un elenco di possibili tipi di restituzione ( da questa risposta ):
I seguenti tipi non vengono convertiti e vengono scritti direttamente nel flusso di risposta:
Un esempio del supporto delle intestazioni HTTP personalizzate può essere visto da questo esempio CORS in cui è possibile configurare le intestazioni HTTP a livello globale o in base al servizio.
Esistono più opzioni per la restituzione di HTML in ServiceStack che è spiegato in dettaglio qui .
I serializzatori veloci e resilienti sono di primaria importanza in un'API per garantire tempi di risposta rapidi e un'API versionabile che non rompe i client esistenti, motivo per cui ServiceStack include i serializzatori di testo più veloci per .NET con un'opzione NuGet per abilitare il protocollo di @marcgravell Buffer (il serializzatore binario più veloce di .NET).
I serializzatori di testo di ServiceStack sono molto resilienti e possono resistere a versioni estreme senza errori.
La natura supponente di ServiceStack consente un'API di servizio web veloce, tipizzata e concisa end-to-end con supporto integrato per i client Sync / Async C # /. NET e Async Silverlight senza code-gen:
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });
Dato che restituisce JSON puro, viene anche banalmente consumato con altri client HTTP, ad esempio un esempio di client JS usando jQuery :
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Tutti i client di servizio C # /. NET condividono le stesse interfacce che li rendono altamente testabili e scambiabili al punto in cui è possibile avere lo stesso test unit che fungono anche da XML, JSON, JSV, SOAP Integration Test .
Nella sua missione di fornire un'esperienza di sviluppo pulita e priva di friciton, ServiceStack include anche la convalida tipizzata e la gestione degli errori incorporata in cui il lancio di un'eccezione C # o l'utilizzo della convalida Fluent integrata fornisce ai clienti errori strutturati e tipizzati facilmente accessibili sui client dei servizi web , per esempio:
try {
var client = new JsonServiceClient(BaseUri);
var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
/*
webEx.StatusCode = 400
webEx.ErrorCode = ArgumentNullException
webEx.Message = Value cannot be null. Parameter name: Name
webEx.StackTrace = (your Server Exception StackTrace - if DebugMode is enabled)
webEx.ResponseDto = (your populated Response DTO)
webEx.ResponseStatus = (your populated Response Status DTO)
webEx.GetFieldErrors() = (individual errors for each field if any)
*/
}
Per rendere banale il consumo di errori in JavaScript, è possibile utilizzare la libreria JavaScript leggera ss-validation.js per associare banalmente gli errori di risposta ai campi del modulo HTML con una singola riga di codice. Il progetto di esempio SocialBootstrapApi fornisce una buona demo di questo.
I ServiceStack MVC PowerPack riscritture e correzioni di un sacco di indispone di ASP.NET MVC e con sostituzioni per la sua paralizzante sessione e provider ASP.NET XML-gravati caching con la propria implementazione pulito e privo di dipendenza ICacheClient e le API ISession.
ServiceStack include anche un modello di provider di autenticazione e autorizzazione più recente e più pulito con un numero di diversi AuthProvider integrati:
Il modulo di autenticazione è completamente opzionale ed è integrato nelle API pulite di ICacheClient / ISession e OrmLite che consente di archiviare le sessioni in memoria, Redis o Memcached e le informazioni di UserAuth persistono nei RDBMS supportati da OrmLite di SQLServer, MySql, PostgreSQL, Sqlite as così come Redis data-store o InMemory (utile per sviluppo / test).
ServiceStack è ben documentato in cui la maggior parte delle informazioni sul framework è ospitata sul wiki di GitHub . La documentazione per altre parti del framework (ad es. Serializzatori, Redis, OrmLite) è disponibile su servicestack.net/docs/
Il progetto ServiceStack.Examples fornisce il codice sorgente per tutte le demo live e i modelli di avvio di ServiceStack, mentre il progetto SocialBoostsrapApi fornisce un ottimo punto di partenza per lo sviluppo di un'app a pagina singola Backbone.js con ServiceStack e MVC basata sul modello Bootstrap di Twitter.
Oltre a quanto sopra, all'interno del Gruppo Google è contenuta una miniera di informazioni che si è notevolmente ampliata negli ultimi anni.
ServiceStack è un framework .NET 3.5 che funziona su host ASP.NET e HttpListener e può essere ospitato su .NET o Mono (curiosità: www.servicestack.net è alimentato da CentOS / Mono). Ciò consente di ospitare i servizi Web di ServiceStack su:
ServiceStack crede fermamente nel modello di sviluppo Open Source in cui è attivamente sviluppato all'aperto ed è sempre stato ospitato con una licenza OSS liberale (New BSD) sin dal suo inizio. Ad oggi ha ricevuto contributi da oltre 47 sviluppatori e attualmente si trova al 3 ° progetto C # più visto su GitHub .
Credo che il più grande svantaggio sia lo stesso per la maggior parte degli altri progetti OSS .NET in cui non è stato sviluppato (o addirittura elencato come opzione disponibile) da Microsoft. Ciò significa che raramente è la prima scelta quando si valuta un framework. La maggior parte degli adottanti valuterà ServiceStack solo come ultima risorsa, dove sono frustrati dall'attrito e dalla fragilità imposti di WCF o dalle prestazioni dello stack Microsoft preferito.
ServiceStack è stato accolto molto bene con feedback positivi forniti dalla maggior parte delle persone che lo hanno valutato come visibile dal sentimento positivo nel gruppo di posta . Da quest'anno l' account twitter @ServiceStack tiene traccia delle menzioni e dei feedback nei suoi preferiti .
La pagina wiki delle risorse della community è un buon posto per scoprire di più su ServiceStack in natura con collegamenti a post di blog, podcast, presentazioni, sintesi e altro.
C'è una nuova differenza principale che deve essere presa in considerazione: ServiceStack non è più gratuito da utilizzare a partire dalla v4. Dato che c'è una risposta abbastanza definitiva sui professionisti delle SS, ho voluto buttarne fuori un paio per l'API Web
Professionisti :
Con:
Vantaggi accessori
(Non esitate a lasciare commenti qui sotto aggiungendo al motivo per cui l'API Web ha vantaggi o vantaggi / svantaggi che posso aggiungere)
Non posso davvero dire molto su ServiceStack, ma l'API Web ha molte ottime funzionalità ed è attualmente alla versione 2.
Alcune delle cose che puoi fare con l'API Web:
asynceawait .Come cliente di ServiceStack ecco il pro di ServiceStack più importante per me.
https://github.com/ServiceStack/Issues/issues/606
Così. Bug trovato, bug identificato, bug risolto. Stesso giorno. Supporto straordinario!
È stato un anno che uso SS ed è tutto fantastico. ORMLite è pura magia. Sono stato in grado di rimappare un terribile DB MySQL da integrare in un'app mobile. Nessuna modifica sul database causa l'utilizzo con un back-end php con un'altra app ...
Mythz è un esempio di supporto e spiegazione. Ha migliorato le mie conoscenze relative al design delle app e alla semplicità di manutenzione. Per favore, provalo e capirai.
Inoltre, non confrontare SS con WebAPI. Non è abbastanza, le SS portano molto di più nella tua cassetta degli attrezzi. ServiceStack.Text è anche un ottimo Automapper.