We are trying to determine the best approach for adding a complex API layer to a modified version of nopCommerce. To back up a step, we're building out a custom site for a fashion/apparel manufacturer that has a lot of front-end application requirements and also needs to integrate with their cross platform apps (iOS, Android, Windows) which we're building with Xamarin. We've tentatively decided to start with nopCommerce as the base of our application to which we will add an API layer.
What we are unsure about is what is the best approach for implementing this in nopCommerce (or other similar .NET package)? The options we are considering are MVC vs WebAPI vs ServiceStack. We've been going thru many of the tutorials on PluralSight.com to get up to speed on app dev and API creation best practices, but there seem to be so many options, we're not sure where to start. We seem to be somewhat lost in a sea of implementation options for the API and how each is to be evaluated based on choice of the JS packages/frameworks used on the front-end for the web site and the tools chosen to create the apps.
If it matters, our basic requirements are:
Expand core of basic e-commerce package with some custom ERP style functionality
API layer that can work effectively with both a web front end (possibly as a SPA) and all cross platform apps built using Xamarin
Insure OAuth authentication across all interface types so we can just use social media logins consistently everywhere and can authenticate the user in any environment
Given this...
My question boils down to which of the three API methods (MVC vs WebAPI vs ServiceStack) is best for this?
In my humble opinion you should go with service stack, it´s easier to implement and a lot more flexible than web api, you can add/remove plugins for different functionalities you get a lot of infrastructure code OOB such as mechanisms to handle cache, loggers and other not just related to infrastructure such as validators and IOC container, etc.
you'll get a single mechanism for authentication including custom auth, oauth, oauth2, etc which works for linked in, facebook and google +, in that situation you´ll find yourself reusing a lot of code in across all your apps.
One other thing that I like about SS is that practically is just you and your IOC, nothig else, everything is quite simple to understand and to implement (there could be more than one hidden option or configuration you may miss in the documentation but you get a lot of support from the community in google groups or stackoverflow)
its easier to test (Unit testing) you already have abstractions for httprequest and httpresponse and a lot of more, you won´t find yourself doing wrappers for all the legacy web impl that are shipped with mvc.
SS is better than mvc web api in terms of performance, it got one of the fastest json serializers out there for .net
I´m working on a SPA app for the time beign and I have no regrets about my desition to get into the SS framework.
just my 2 cents.
I would say Web API is best option for the Services Layer
- http://www.asp.net/vnext/overview/aspnet-web-api
There are many advantages
- Web API has been in release cycle as separate component with latest features
- Security
- Versioning
- Attribute based routing
- OData integration
Related
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
I'm building an API that's intended to be consumed by an iOS app as well as a browser-based Web Application (using React / AngularJS). The API is being developed in Laravel.
What is the best way to structure this? Should the API and the Web Application be apart of the same Laravel Application, or should the API be an entirely separate entity that just returns JSON to whatever client requests it? In that case, I suppose my Web Application would interact with the API as though it were a 3rd party API
We we've had a grown monolithic application and decided to split the code up, into repositories called "core", "frontend" and, new to our family, added "api".
That is, we are using the Microservice pattern and it works well for "us".
Our core/frontend repositories are CakePHP but the API is written in Laravel 5 using the jsonapi 1.0 spec.
We're quite, if not to say, very happy with this approach. The only canonical thing it the representation in the database. Business logic and code is redundant. But an interesting lesson learned is that we uncovered quite some bugs due this in the existing code base.
The clean separation is important to not be bound too much to one technology. We may want to replace the "frontend" stack with a node application talking to the API. We may want to replace the API with something else later.
Of course this comes with huge amount of work, resources, etc. but not being able to act due a monolith is worse in our view.
I wanna use KooBoo for my web platform and for that combine it with Servicestack (Servicestack).
Servicestack should act as the REST API framework and Kooboo as the user frontend framework.
I would like to build a independent service layer within that, where Kooboo controllers and servicestack services are leliyng on and share for instance the same session.
So my questions are
How to integrate a webservice framework in Kooboo in general (Change
source, Module, Plugin...)
How to use / integrate layered architecture ? (Because you persist Models directly with your data API, is there a way or what is the recommended way of usinf business objects and ViewModels separated)
Can I integrate other editors instead of tinyMCE
When I use other js framworks like angularJS or kendoUI, can I still use the "inline edit" functions ?
I know, a lot of questions. If you want me to split up these into separate threads I will do that of course!
I've never heard of KooBoo before but seeing that it's built on ASP.NET MVC, the ServiceStack Integration and MVC Integration docs shows how you can access ServiceStack's dependencies, plugins, execute Services etc. from outside of ServiceStack, e.g from within ASP.NET MVC.
The documentation goes through to explain different ways you can integrate with ServiceStack from an ASP.NET MVC web application and also includes a live demo of different techniques at http://mvc.servicestack.net (source code).
What is the best way to use live id authentication with azure based asp.net mvc project?
I find the options
1) With in Live SDK, there are options like REST, JavaScript, C# etc.
2) Since my project will be hosted in azure, there is another way "Securing Web Applications with ACS" http://msdn.microsoft.com/en-us/library/gg185928.aspx
Please suggest the design and also support with pros when an particular approach is good.
You definitely want to work with ACS. Not only is it intended for this purpose, there's a fully worked up example at
http://msdn.microsoft.com/en-us/library/gg185975.aspx
which will give you a flying start.
ACS, and Windows Identity Foundation in general, lets you take the approach of separating identity verification from your application altogether. This saves a ton of code and means that you have much less "plumbing" to support.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?