Eu quero escrever uma nova API de estilo REST e olhei para o ServiceStack e muito parecido. No entanto, vi que a Microsoft lançou o projeto ASP.Net Web API como parte do novo MVC 4 beta. Alguém já olhou para o novo projeto de API da Web? Você pode dar algum prós / contras de cada sistema?
Respostas:
Eles têm casos de uso muito semelhantes, como mantenedor líder do projeto ServiceStack, tenho uma boa visão das vantagens do ServiceStack e dos muitos benefícios naturais de seu design baseado em mensagens .
O ServiceStack existe desde 2008 como um projeto executado por OSS desde o início, com um único objetivo de promover o design e a implementação corretos de serviços remotos sem atrito.
Em busca da simplicidade máxima, ele é construído em torno de um núcleo simples e elegante - com a maioria dos recursos vinculando-se naturalmente aos seus modelos , não aos controladores - que é o que o MVC, o WebApi faz (assim como todos os outros Web Service Framework que a Microsoft produziu )
A adoção de um design baseado em mensagens oferece uma abordagem superior para serviços remotos, pois eles promovem serviços mais extensíveis e menos frágeis, simplificam os padrões de acesso e chamada e contêm muitos outros benefícios naturais que você obtém gratuitamente .
Como missão principal, combatemos a complexidade em todas as etapas, com o objetivo de manter uma API invisível e não intrusiva e evitar a introdução de novos conceitos ou construções artificiais que ainda não sejam familiares aos desenvolvedores de .NET ou de serviços da Web atualmente.
Como exemplo, sua IService<T>implementação de serviço é apenas uma classe C # padrão com dependências com fio automáticas. Wrappers finos e leves são usados para fornecer uma API consistente e unificada em torno dos tipos principais de tempo de execução IHttpRequest e IHttpResponse . Eles também permitem o acesso às classes subjacentes de solicitação e resposta do ASP.NET ou HttpListener, para que você nunca fique restrito ao usar o ServiceStack.
Aqui está uma breve visão geral dos estilos de API contrastantes que o ServiceStack e o WCF promovem . O WebApi é diferente do WCF, pois incentiva o design da API REST-cheia. Quanto aos exemplos entre os 2, este é o único exemplo conhecido que tenho com o mesmo serviço escrito no ServiceStack e no WebApi .
O ServiceStack tem como foco principal a simplicidade, o desempenho e a promoção das práticas recomendadas de serviço web / remoto, centradas na adoção de padrões de design de serviço remoto Martin Fowlers no C # idiomático possível:
O padrão de fachada - o que sugere o uso de interfaces granulares e granulares quando você se comunica através dos limites do processo.
O padrão DTO ( MSDN ) - Ditando o uso de POCOs para fins especiais para gerar o formato de conexão de suas respostas de serviços da web.
O padrão de gateway ( MSDN ) para encapsular as comunicações de cliente e servidor entre os modelos de gateway de cliente / DTO e as camadas da interface de serviço.
Esses padrões garantem uma separação clara de preocupações e uma experiência de desenvolvedor iterativa sem atrito.
Um serviço Web ServiceStack em sua essência é centrado em uma IService<T>interface C # pura, livre de dependência e com conexão automática, que oferece total liberdade para definir seu contrato de serviço web com seus próprios DTOs de solicitação e resposta usando POCOs limpos - tornando a API do ServiceStack praticamente invisível e não invasivo, ou seja, é trivial extrair sua lógica de serviços em C # e executá-la fora de um host do ServiceStack.
Esta essência é um bom exemplo do que você obtém com apenas 1 classe C # .cs no ServiceStack :
As classes RestServiceBase e ServiceBase destinam-se a hospedar sua lógica C # personalizada para o máximo potencial de reutilização possível, por exemplo, seu design DTO primeiro permite trivialmente a execução adiada e em proxy, onde seu mesmo serviço C # também pode ser hospedado e executado em um host MQ que é o que acontece quando você se registra um IMessageServicecomo o anfitrião RedisMQ e chame o serviço através do /asynconewayponto final (ou seja, client.SendOneWay()em C # Clients)
Você também pode delegar e criar facilmente serviços compostos usando o base.ResolveService<T>()método que retorna uma instância com fio automática do serviço selecionado, como visto no exemplo do Serviço Nortwind CustomerDetails :
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
Na maioria das vezes, o ServiceStack serializa a maioria dos objetos C # conforme o esperado - aqui está uma lista dos possíveis tipos de retorno ( desta resposta ):
Os seguintes tipos não são convertidos e são gravados diretamente no fluxo de resposta:
Um exemplo do suporte a cabeçalhos HTTP personalizados pode ser visto neste exemplo do CORS, em que você pode configurar os cabeçalhos HTTP globalmente ou por serviço.
Existem várias opções para retornar HTML no ServiceStack, explicadas em detalhes aqui .
Serializadores rápidos e resilientes são de importância primordial em uma API para garantir tempos de resposta rápidos e uma API com versão que não interrompa os clientes existentes. Por isso, o ServiceStack inclui os serializadores de texto mais rápidos para .NET com uma opção NuGet para ativar o Protocolo de @marcgravell Buffers (serializador binário mais rápido do .NET).
Os serializadores de texto do ServiceStack são muito resistentes e podem suportar versões extremas sem erros.
A natureza opinativa do ServiceStack permite uma API de serviço da Web concisa, rápida e tipada, ponta a ponta, com suporte interno para clientes Sync / Async C # / .NET e Async Silverlight sem nenhum código de geração:
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; });
Como ele retorna JSON puro, também é consumido trivialmente com outros clientes HTTP, por exemplo, exemplo de cliente JS usando jQuery :
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Todos os C # / .NET ServiceClients compartilham as mesmas interfaces que os tornam altamente testáveis e trocáveis até o ponto em que você pode ter o mesmo teste de unidade e também serve como um teste de integração XML, JSON, JSV, SOAP .
Em sua missão de fornecer uma experiência de desenvolvedor limpa e sem fricção, o ServiceStack também inclui validação digitada e tratamento de erros embutidos, onde lançar uma exceção C # ou usar sua validação Fluente incorporada fornece aos clientes erros estruturados e tipados facilmente acessíveis em clientes de serviços da Web , por exemplo:
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)
*/
}
Para facilitar o consumo de erros no JavaScript, você pode usar a biblioteca JavaScript leve ss-validation.js para vincular trivialmente seus erros de resposta aos campos do formulário HTML com uma única linha de código. O projeto de exemplo SocialBootstrapApi fornece uma boa demonstração disso.
O ServiceStack MVC PowerPack reescreve e corrige muitos problemas do ASP.NET e MVC, com substituições para seus provedores de ASP.NET sobrecarregados por Session e Caching XML com cache com sua própria implementação limpa e sem dependência das APIs ICacheClient e ISession.
O ServiceStack também inclui um modelo de provedor de autenticação e autorização mais novo e limpo, com vários AuthProviders diferentes incorporados:
O módulo Autenticação é totalmente opcional e é integrado às APIs ICacheClient / ISession e OrmLite limpas, que permitem que suas sessões sejam armazenadas na memória, Redis ou Memcached e suas informações de UserAuth persistem nos RDBMSs suportados do OrmLite do SQLServer, MySql, PostgreSQL, Sqlite como RDBMSs suportados do OrmLite. bem como armazenamento de dados Redis ou InMemory (útil para desenvolvimento / teste).
O ServiceStack está muito bem documentado, onde a maioria das informações sobre a estrutura está hospedada no wiki do GitHub . A documentação para outras partes da estrutura (por exemplo, Serializers, Redis, OrmLite) pode ser encontrada em servicestack.net/docs/
O projeto ServiceStack.Examples fornece o código-fonte para todas as demos ao vivo e modelos iniciais do ServiceStack, enquanto o projeto SocialBoostsrapApi fornece um excelente ponto de partida para o desenvolvimento de um aplicativo de página única do Backbone.js com ServiceStack e MVC baseado no modelo do Twitters Bootstrap.
Além do exposto acima, há um tesouro de informações no Grupo Google, que se expandiu consideravelmente nos últimos anos.
O ServiceStack é uma estrutura do .NET 3.5 que roda nos hosts ASP.NET e HttpListener e pode ser hospedada no .NET ou Mono (trivialidade: www.servicestack.net é alimentado por CentOS / Mono). Isso permite que seus serviços web ServiceStack sejam hospedados em:
O ServiceStack acredita firmemente no modelo de desenvolvimento de código aberto, onde ele é desenvolvido ativamente em ambiente aberto e sempre foi hospedado sob uma licença OSS liberal (New BSD) desde o seu início. Atualmente, recebeu contribuições de mais de 47 desenvolvedores e atualmente está no terceiro projeto C # mais assistido no GitHub .
Acredito que a maior desvantagem é a mesma para a maioria dos outros projetos OSS .NET onde não foi desenvolvido (ou mesmo listado como uma opção disponível) pela Microsoft. Isso significa que raramente é a primeira escolha ao avaliar uma estrutura. A maioria dos adotantes avalia apenas o ServiceStack como último recurso, onde fica frustrada com a fricção e fragilidade impostas pelo WCF ou com o desempenho do Microsoft Stack preferido.
O ServiceStack foi muito bem recebido com feedback positivo fornecido pela maioria das pessoas que o avaliaram como visível pelo sentimento positivo no grupo de correspondência . A partir deste ano, a conta do Twitter do @ServiceStack acompanhava as menções e comentários nos seus favoritos .
A página da wiki Recursos da comunidade é um bom lugar para descobrir mais sobre o ServiceStack em estado selvagem, com links para postagens de blog, podcasts, apresentações, Gists e muito mais.
Há uma nova diferença principal que precisa ser levada em consideração - o ServiceStack não é mais gratuito para uso a partir da v4. Como existe uma resposta bastante definitiva nos profissionais da SS, eu queria lançar algumas para a API da Web
Profissionais:
Contras:
Benefícios Auxiliares
(Por favor, não hesite em deixar comentários abaixo, explicando por que a API da Web tem benefícios ou tem prós / contras que posso adicionar)
Não posso dizer muito sobre o ServiceStack, mas a API da Web tem muitos recursos excelentes e está atualmente na versão 2.
Algumas das ações que você pode fazer com a API da Web:
asynce await.Como cliente do ServiceStack, aqui é o profissional do ServiceStack mais importante para mim.
https://github.com/ServiceStack/Issues/issues/606
Assim. Bug encontrado, bug identificado, bug corrigido. Mesmo dia. Suporte extraordinário!
Faz um ano que eu uso SS e está tudo ótimo. ORMLite é pura magia. Consegui remapear um banco de dados MySQL horrível para integrar aplicativos móveis. Nenhuma alteração no banco de dados, pois é usada com um back-end php com outros aplicativos ...
Mythz é um exemplo sobre suporte e explicação. Ele atualizou meu conhecimento sobre o design de aplicativos e a simplicidade na manutenção. Por favor, tente e você entenderá.
Além disso, não compare SS com WebAPI. Não basta, os SS trazem muito mais à sua caixa de ferramentas. O ServiceStack.Text também é um excelente Automapper.