Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I want to write a new REST style API and have looked at ServiceStack and quite like it. However, I have seen that Microsoft has released the ASP.Net Web API project as part of the new MVC 4 beta. Has anyone looked at the new Web API project? Can you give any pros/cons of each system?
They have very similar use-cases, as the lead maintainer for the ServiceStack project I have a good insight into ServiceStack's advantages and the many natural benefits of its message-based design.
ServiceStack has been around since 2008 as an OSS-run project from its inception with a single goal of promoting the correct design and implementation of friction-free remote services.
Simple and Elegant Design
In its pursuit for ultimate simplicity, it's built around a simple and elegant core - with most of its features naturally binding to your models, not your controllers - which is what MVC, WebApi does (as well as every other Web Service Framework Microsoft has produced).
Adopting a message-based design offers a superior approach for remote services, in that they promote more extensible and less brittle services, simplifies access and calling patterns, and contain many other natural benefits you get for free.
As a core mission, we fight complexity at every stage, aiming to keep an invisible and non-intrusive API and avoid introducing any new concepts or artificial constructs that aren't already familiar to .NET or web service developers today.
As an example your IService<T> service implementation is just a standard C# class with auto-wired dependencies. Thin and lightweight wrappers are used to provide a consistent and unified API around the core run-time IHttpRequest and IHttpResponse types. They also allow access to underlying ASP.NET or HttpListener's Request and Response classes so you're never restricted when using ServiceStack.
Contrasted with WCF and WebApi
Here's a brief overview of the contrasting API styles that ServiceStack and WCF promote. WebApi is different to WCF in that it encourages REST-ful API design. As for examples between the 2, this is the only known example I have with the same service written in both ServiceStack and WebApi.
Best Practices remote services
ServiceStack has a primary focus on simplicity, performance and in promoting web/remote service best-practices centered around embracing Martin Fowlers remote-service design patterns in as idiomatic C# as possible:
The Facade Pattern - Which suggests the usage of batchful, coarse-grained interfaces when ever you communicate across process boundaries.
The DTO pattern (MSDN) - Dictating the use of special-purpose POCOs to generate the wire format of your web services responses.
The Gateway Pattern (MSDN) to encapsulate your client and server communications between the Client Gateway / DTO models and Service Interface tiers.
These patterns ensure a clean separation of concerns and a friction-free iterative dev experience.
Empowering your services
A ServiceStack web service at its core is centered around a dependency-free and auto-wired pure C# IService<T> interface that gives you complete freedom to define your web service contract with your own Request and Response DTOs using clean POCOs - rendering ServiceStack's API practically invisible and non-invasive, i.e. it's trivial to extract your C# services logic and run it outside of a ServiceStack host.
This gist is a good example of what you get with just 1 C# .cs class in ServiceStack:
Metadata pages for all registered formats
With links to WSDLs, XSDs and C# client examples
Human friendly HTML report view
A single self-contained html page snapshot (i.e. no external refs). Includes embedded JSON web service response - allows programmatic access to data snapshots.
Built-in Mini Profiler (port of the excellent MVC Mini Profiler)
Includes Sql Profiling
JSON/JSONP, XML, JSV, CSV and SOAP end-points
The RestServiceBase and ServiceBase classes are intended to host your custom C# logic for maximum potential re-use as possible, e.g. Its DTO-first design trivially allows for deferred and proxied execution where your same C# Service can also be hosted and executed in an MQ Host which is what happens when you register an IMessageService like the RedisMQ host and call your service via the /asynconeway endpoint (i.e. client.SendOneWay() in C# Clients)
You can also easily delegate and create composite services using the base.ResolveService<T>() method which returns an auto-wired instance of the selected service as seen in the Nortwind CustomerDetails Service example:
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
Return plain C# objects
For the most part ServiceStack will serialize most C# objects as expected - here's a list of possible return types (from this answer):
Any DTO object -> serialized to Response ContentType
HttpResult, HttpError, CompressedResult (IHttpResult) for Customized HTTP response
The following types are not converted and get written directly to the Response Stream:
String
Stream
IStreamWriter
byte[] - with the application/octet-stream Content Type.
An example of the Custom HTTP headers support can be seen by this CORS example where you can configure HTTP Headers globally or on a per-service basis.
HTML Support
There are multiple options for returning HTML in ServiceStack that is explained in detail here.
Includes fastest text and binary serializers for .NET
Resilient and fast serializers are of primary importance in an API to ensure fast response times and a versionable API which doesn't break existing clients which is why ServiceStack includes the fastest text serializers for .NET with a NuGet option to enable #marcgravell's Protocol Buffers (.NET's fastest binary serializer).
ServiceStack's text serializers are very resilient and can withstand extreme versioning without error.
Friction-free dev experience End-to-End
ServiceStack's opinionated nature allows for a fast, typed, terse web service API end-to-end with built-in support for Sync/Async C#/.NET and Async Silverlight clients without any code-gen:
Sync C# Example
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
Async C# Example
client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });
As it just returns pure JSON it's also trivially consumed with other HTTP Clients, e.g. JS client example using jQuery:
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Highly testable
All C#/.NET ServiceClients share the same interfaces which make them highly testable and swappable to the point where you can have the same unit test also serve as an XML, JSON, JSV, SOAP Integration Test.
Rich Validation and Error Handling built-in
In its mission to provide a friciton-free and clean dev experience, ServiceStack also includes typed validation and error handling built-in where throwing an C# Exception or using its built-in Fluent validation provides clients structured, typed errors easily accessible on web service clients, e.g:
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)
*/
}
To make it trivial to consume errors in JavaScript, you can use the lightweight ss-validation.js JavaScript library to trivially bind your response errors to your HTML form fields with a single line of code. The SocialBootstrapApi example project provides a good demo of this.
Rich Integration with ASP.NET and MVC
The ServiceStack MVC PowerPack re-writes and fixes a lot of the ails of ASP.NET and MVC with replacements for its crippling Session and Caching XML-encumbered ASP.NET providers with its own clean and dependency-free implementation of ICacheClient and ISession APIs.
ServiceStack also includes a newer and cleaner authentication and autorization provider model with a number of different AuthProviders in-built:
Credentials - For authenticating with username/password credentials by posting to the /auth/credentials service
Basic Auth - Allowing users to authenticate with Basic Authentication
Twitter OAuth - Allow users to Register and Authenticate with Twitter
Facebook OAuth - Allow users to Register and Authenticate with Facebook
The Authentication module is entirely optional and is built-on the clean ICacheClient / ISession APIs and OrmLite which allows your Sessions to be stored in Memory, Redis or Memcached and your UserAuth info persisted in OrmLite's supported RDBMS's of SQLServer, MySql, PostgreSQL, Sqlite as well as Redis data-store or InMemory (useful for dev/testing).
Great Documentation
ServiceStack is very well documented where most of the information about the framework is hosted on the GitHub wiki. Documentation for other parts of the framework (e.g. Serializers, Redis, OrmLite) can be found on servicestack.net/docs/
The ServiceStack.Examples Project provides the source code for all of ServiceStack's live demos and Starter Templates whilst the SocialBoostsrapApi project provides a great starting point of developing a Backbone.js Single Page App with ServiceStack and MVC based on Twitters Bootstrap template.
In addition to the above a treasure trove of information is contained within the Google Group which has expanded quite considerably in recent years.
Runs Everywhere
ServiceStack is a .NET 3.5 framework that runs on ASP.NET and HttpListener hosts and can be hosted on either .NET or Mono (trivia: www.servicestack.net is powered by CentOS/Mono). This allows your ServiceStack web services to be hosted on either:
Windows with .NET 3.5 & 4.0
IIS 5/6/7 (uses IHttpHandler)
VS.NET WebDevServer
Console App or Windows GUI
Windows Service
Linux/OSX with Mono
Apache + mod_mono
Nginx + MonoFastCGI
XSP
Console App
Developed with the Open Source development model
ServiceStack is a strong believer of the Open Source development model where it is actively developed in the open and has always been hosted under a liberal OSS licence (New BSD) since its inception. As of today it has received contributions from more than 47 developers and it currently stands at the 3rd most watched C# project on GitHub.
Disadvantages
I believe the biggest disadvantage is the same for most other OSS .NET projects where it wasn't developed (or even listed as an available option) by Microsoft. This means it's rarely ever the first choice when evaluating a framework. Most adopters will only evaluate ServiceStack as a last resort, where they're either frustrated with the imposed friction and brittleness of WCF or the performance of the preferred Microsoft Stack.
Feedback and Community Resources
ServiceStack has been very well received with positive feedback provided by most people who have evaluated it as visible by the positive sentiment in the mailing group. As of this year the #ServiceStack twitter account has been tracking mentions and feedback in its favorites.
The Community Resources wiki page is a good place to find out more about ServiceStack in the wild with links to Blog Posts, Pod Casts, Presentations, Gists and more.
There is a new main difference that needs to be accounted for - ServiceStack is no longer free to use as of v4. Since there is a pretty definitive answer on the SS pro's I wanted to throw a couple out for Web API
Web API
Pro's :
Free to use in your project (provided you have a VS license that allows commercial use)
Extraordinarily high level of free support available from Microsoft and all over the web, including here on StackOverflow.com.
Quickly integrates with other Microsoft technology stacks like ASP.NET MVC which is extremely popular in Microsoft shops
Built in support for RESTful authentication and authorization in your Microsoft stack
Con's :
Doesn't support SOAP
Ancillary Benefits
(Please feel free to leave comments below adding to why Web API has benefits or has pros / cons I can add)
I can't really say much about ServiceStack, but Web API has a lot of great features and is currently at version 2.
Some of the things you can do with Web API:
Self host in an OWIN application (i.e. runs anywhere).
Full support for async and await.
Good default Templates and tons of open source examples.
Used great Json.Net JSON serializer.
Rest-ish by default (you'll have to do hypermedia yourself).
and more...
As a customer of ServiceStack here is the pro for ServiceStack most important for me.
https://github.com/ServiceStack/Issues/issues/606
So. Bug found, bug identified, bug fixed. Same day. Extraordinary support!
It's been one year that I use SS and it's all great.
ORMLite is pure magic. I was able to remap an awfull MySQL DB to integrate in a mobile apps. No change on the database cause it's use with a php backend with another apps...
Mythz is an example regarding support and explanation. It upgraded my knowledge regarding apps design and simplicity on maintenance. Please try it and you will understand.
Also, don't compare SS with WebAPI. It's not enough, SS bring much more to your toolbox. ServiceStack.Text is a great Automapper too.
Related
I want to connect mongodb server to android application so that i can send data( which is stored online on mongodb ,not locally) to android user. I want to do it through REST api using node.js but couldn't find a way to do it.
Please help.
First of all it's a bad idea to connect to the Database directly. It is possible, but it'a a bad idea.
It's a much better practice to create a web service backend that your app can connect to. This will allow you to implement the business logic on the server. And additionally, you will be able to use not only Android, but iOS, AngularJS and others as clients too.
Generally the most common rest backend architecture looks something like this:
REST BACKEND
I find this way of development to be modular and very well organized.
In short, the API layer only takes HTTP GET and POST methods, and calls the appropriate functions in the Service layer. The service layer holds all of your business logic and calls the DAO layer, and Dao call anb works with the DB.
There's tons of examples for how to build web services, and it's highly dependent on your language of choice for your web tier. There are also tons of examples for consuming web services on Android. You should look it up.
But whatever language you choose the API -> Service -> Dao -> Database scheme should work fine.
If you don't know where to start take a look at Python Flask or Java Spring as good candidates for developing web services. (I use Spring because there is a ton of great documentation on whatever you may need.)
Hope this helps a bit. Good luck!
We're planning on implementing a server-side notification mechanism that pushes out to iOS and Android via ANH. We will have no code footprint on our mobile clients, short of a call to our server API for "registration". In this way our approach is looking similar to this MSDN discussion.
I also see the alternate, more bare-bones, approach noted on MSDN.
Is it fair to conclude that the two approaches will have similar performance on the 'send' side?
It appears the main difference is this:
The former approach has already done the work of integrating with the Task and Async mechanism, presenting a callable C# mechanism that has taken on more of the RESTful API layer,
The DirectBatch/Send API is just that -- the raw RESTful API for you to use as you see fit.
For operations that are available as both REST API and SDK, you shouldn't see any significant difference in performance on the client side because the SDK is just a wrapper around the REST APIs. There are SDKs for both iOS and Android and it's recommended to use those so that you don't have to re-write the wrapper.
Direct Send is only available in .NET SDK at the moment and for other platforms as REST API, so you'd have to implement your own wrapper in case you're using something other than .NET for the operation. You can use the sample to help you in the process.
In terms of performance it depends on what you mean by that.
Direct send will most likely be delivered to customers a bit faster because ANH service doesn't have to do any registrations in the process, it just delivers notifications with your parameters. But it has it's limitations in terms of number of handles you can provide and also you need to manage handles yourself.
If you only mean performance on the client side, then there should be no difference as all calls are asynchronous. And if you take advantage of tags, then you can do really tricky sends in one server call and let ANH figure out the details behind it.
But without knowing your scenario and requirements there's no way to give a proper recommendation.
My company is big on sharepoint. but server side controls have inherent problem with performance. I want to move page rendering responsibility to client side with concept similar to SPA. what is best framework or architectural style for this.
Single Page Applications are gaining immense popularity these days mainly because of their fluidity and responsiveness. Clearly the framework and architectural style depends heavily upon the requirements.
Framework:-
There are host of frameworks available that can be leveraged depending upon the complexity of the SPA you are planning - Backbone, Angular, Knockout, Ember etc. I personally prefer Angular and Knockout frameworks because of their simplicity and data binding and directive capabilities. Moreover you can also efficiently handle REST calls to SharePoint using Breeze.js. Refer to this link for more details.
Architecture Styles:-
Typically SPAs use MVC or MVVM patterns to decouple the UI aspect from the business logic, but this again is requirement driven. Regardless of the style/pattern it is important to keep the code modular and no to expose implementation details as much as possible.
Packaging:-
As far as SPAs for SharePoint are concerned, the best way to package and deploy them is in the form of SharePoint Hosted Apps. SharePoint Hosted Apps only allow client side code and hence leveraging Javascript object model and REST API for SharePoint making them ideal for deployment of SPA over SharePoint.
References:-
https://www.pluralsight.com/courses/building-sharepoint-apps-spa-angularjs
Not sure if this is the most effective place to ask this question. Please redirect if you think it is best posted elsewhere to reach a better audience.
I am currently building some tooling in Visual Studio 2013 (using NuPattern) for a project that implements standard REST service using the ServiceStack framework. That is, the tooling helps you implement REST services, that meet a set of design rules and guidelines (in this case advocated by the ApiGee guidelines) for good REST service design.
Based on some simple configuration by the service developer, for each resource they wish to expose as a REST endpoint, with any number of named verbs (of type: GET, PUT, POST or DELETE) the tooling generates the following code files, with conventional names and folder structure into the projects of your own solution in Visual Studio (all in C# at this point):
The service class, and the service interface containing each named verb.
Both the request DTO and response DTOs, containing each named field.
The validator classes for each request DTO, which validates each request DTO field.
a manager class (and interface) that handles the actual calls with data unwrapped from DTOs.
Integration Tests that verify each verb with common edge test cases, and verifies status codes, web exceptions, basic connectivity.
Unit Tests for each service and manager class, that verify parameters and common edge cases, and exception handling.
etc.
The toolkit is proving to be extremely useful in getting directly to the inner coding of the actual service, by taking care of the SS plumbing in a consistent manner. From there is basically up to you what you do with the data passed to you from the request DTOs.
Basically, once the service developer names the resource, and chooses the REST verbs they want to support (typically any of these common ones: Get, List, Create, Update, Delete), they simply jump straight to the implementation of the actual code which does the good stuff rather than worrying about coding up all the types around the web operations and plumbing them into the SS framework. Of course we support nested routes and that good stuff so that your REST API can evolve appropriately.
The toolkit is evolving as more is learned about building REST services with ServiceStack, and as we want to add more flexibility to it.
Since there is so much value being discovered with this toolkit in our specific project, I wanted to see if others in the ServiceStack community (particularly those new to it or old hands at it) would see any value in us making it open source, and let the community evolve it with their own expertise to help others move forward quicker with ServiceStack?
(And, of course, selfishly give us a chance to pay forward to others, out of respect for the many contributions others have selflessly made in the ServiceStack communities that have helped us move forward.)
Let us know what you think, we can post a video demonstrating the toolkit as it is now so you can see what the developers experience is currently.
Video walkthrough of the VS.NET Extension
A video walking through of the workflow is available on:
http://www.youtube.com/watch?v=ejTyvKba_vo
Toolkit Project
The toolkit is now available here:
https://github.com/jezzsantos/servicestacktoolkit
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've been trying to do some research on REST and SOAP web service supporting frameworks for CentOS/Redhat that would also be able to reasonably support a management Web application along side the services themselves.
We haven't determined if REST or SOAP will be the way to go for service communication. The communication requirements are pretty straight forward, so a heavier SOAP interface may not be required. (but wouldn't be complex either)
I've done work with Ruby on Rails in the past (on the side currently) but the technology isn't as familiar to the rest of my group as J2EE would be.
ServiceStack is also interesting (I'm looking into it now) but I've worked on .Net/Mono projects in the past and have run into all kinds of Mono implementation and runtime issues. (I'm sure it's come a long way in the last 2 years, but I'd like to see if there's a better alternative)
Basically I need a stack/framework which supports REST or SOAP, (both would be amazing) and can support a MVC style Web app. The idea is the Web service and Web app would have access to the same database. The Web app would be an end-user/admin management interface, and the Web service would be for remote system/automated access to controlled data.
Finally, about 80% of the application database schema will be predefined and won't follow any MVC style modelling. So a framework which is intended to tightly model the schema data for MVC only use, like Ruby on Rails, wouldn't be preferable as we'd end up having to re-create the Models or write an entirely separate database query handling library which both the Web service and Web app would have to use. It would be great if existing data could be modelled more flexibly. (in case the existing schema changes at a later date)
Sorry if I'm being too generic. (or specific) I'm just interested in opinions. Thanks!
ServiceStack services can be consumed by REST, SOAP or MQ clients
REST and SOAP are different methodologies although ServiceStack's message-based DTO-first approach is the only .NET framework that allows your same service to be called by both REST and SOAP endpoints. Since your ServiceStack web services are pure C# services the same service can also be hosted in an InMemory or Redis MQ Host. (There's also a RCON non-http context host option).
Inherent limitations in SOAP
Although as SOAP routes everything through HTTP Post you need to define your services around this limitation with a new class for every service you want available in your SOAP endpoint. Here's an example of how you would create a REST service that was also available via SOAP.
REST and SOAP are very different in many ways.
REST is an architectural style, SOAP is a protocol. SOAP defines how things communicate, REST defines how the're described statelessly.
I do prefer REST with HATEOAS (Hypermedia As The Engine Of Application State). An application with that architecture exposes resources with specific URIs (like http://example.com/users) and representations (in JSON, XML, HTML, etc) for these resources using content-negotiation (Accept headers on HTTP).
The HATEOS part is the linking between resources, like <a href= on HTML or <link href= on ATOM or JSON Schema for linking in JSON.
A good reference implementation is the Netflix API http://api.netflix.com/. They're awesome.
Frameworks for RESTful implementations are available for several languages. On Ruby, Sinatra is probably the best choice. Flask would be the guy for Python. On node.js, expressjs is getting very popular.
I'm a PHP guy. Of all frameworks I know (including Zend, Symfony, Slim, Code Igniter and many others), the best REST implementation is this http://documentup.com/Respect/Rest. It's the single one that implements content-negotiation in a sane manner. (Disclaimer: I've coded it, my opinion may be biased. Get your own opinion using something like the Litmus Test for RESTful Frameworks http://code.google.com/p/implementing-rest/wiki/LitmusTestForFrameworks).
There is a single case in which I do prefer SOAP communications: when the client consuming my service already uses SOAP for anything else. Consistency wins on this case. Java guys would probably prefer SOAP as well, I believe.