There is not a YES or NO answer to your question. The decision to introduce a second level of indirection in the form of an xml/json API depends on what you are about to do with your project.

As you mentioned, many projects go mobile these days, however, isn’t there a simpler way to provide mobile functionality by simply presenting a customized version of your web interface? I can’t answer this but maybe you can.

Other questions you may ask yourself include: Are there any others willing to write clients to my application? If the answer is yes, than an xml/json API may be a good way to go.

EDIT: PS – whatever way you go, separating the business logic from the MVC has the same importance. An API would force you to do that, but also without a second level of encapsulation you should be able to do it just fine.

It depends on your application. A lot of businesses simply don’t need a web API services layer and can use standard MVC practices to serve up rendered pages from well designed thin controllers. This can be much faster to create and easier to maintain than something like a view layer written entirely in unmaintainable javascript(most is) that hits your API.

Most frameworks assume the view will be rendered in the same application so you’ll be fighting that assumption and losing out on a lot of ‘free’ functionality. Business logic can leak either way so it’s a question whether the extra layer of abstraction gives you anything.

No.

XML/JSON are just data formats.

It makes sense to have a clear separation between business logic and presentation (unless it’s a small project). If you have procedures/functions/methods whatever that expose the operations in you application, which are not “contaminated” with presentational matters (i.e. they take primitives, business-logic objects instead of HTTP requests, GUI events, etc.), it’s fairly easy to expose them in different manners- XML, JSON, whatever, and of course you can invoke them directly from the applicable presentation layers.

You don’t need to force a “hard” separation- it really doesn’t require that much discipline, and even if you required separate projects for other reasons (e.g. different teams, etc.), I would favor using the backend as a “library” instead of as a service if possible- direct method invocation has less overhead in all senses and is highly desirable.

Yes, I think it makes really good sense and is an excellent architecture. It’s so simple to return JSON/XML to the client transparently from the server – it does not require writing an additional layer. Javascript clients easily consume JSON. You have a clean separation of concerns. You can generate code from the shared model for compile-time validation if you choose. And of course you have the flexibility mentioned in the question of supporting additional clients e.g. mobile. Don’t forget the backend technology can change too. We swapped out a .NET backend for a java/spring/tomcat backend at my last job.

No, don’t expose all business services ‘blindly’, with the one possible exception is if your app has a 100% smart-client front-end (i.e. only consider this if NONE of your dynamic Html is rendered from the server).

Rationale is:

• This will slow down the performance of Controller rendered screens unnecessarily due to the additional TCP/IP stack ‘hop’
• It creates a larger surface area for attackers – you may forget to lock down services which you aren’t actually using.
• Exposing of services must be done in a formalised manner (e.g. off your controllers for JSON / browser clients, or a formal set of integration services, e.g. web services). If you don’t do this, in an enterprise, you may find yourself with a bunch of consumers of your services who you don’t even know about.
• In many instances (in .NET anyway), exposing JSON services to a browser is best done from the MVC controller, since Ajax services are often tightly coupled to views. This isn’t the right place for exposing integration services (e.g. SOAP / WSE) to other systems.

In short, you are right about moving logic out of your views and controller into a ‘back end layer’, but the coupling between controller and back end isn’t necessarily across a web service boundary.

With the rise of the Javascript client-side UI rendering frameworks like backbone.js and other various tricks like pjax, this option is becoming more and more popular.

It’s always a good idea to separate business logic from presentation concerns.

Depending on your budget/time, you may want to skip the public API (fiddling with OAUTH stuff is a big time sink by itself), and build your controllers and views to consume the json result set returned by your application specific code. I’m going with this approach for some time, and it pays back sooner than I expected.

You might want to read The Clean Architecture, a great blog post from Robert Martin(UncleBob). Some good advice in there.

Most probably yes, if your clients are going to consume Restful HTTP services.

There is a growing trend in web/mobile applications to extensively use HTTP services with json/xml formatted data exchange. Thus, if you are developing on .NET platform there is ASP.NET Web API technology that will ease your development, and provide a most fundamental features out of the box.

Even if you are developing for different platform, still http services and mentioned data formatted data exchange type is starting to play important role, and it is getting more and more important to move toward that direction.

Every time I have had to re-purpose a screen in a web application, the new purpose has needed slightly different queries and different business logic. The idea of reuse is great, but I haven’t seen it play out that way in the 12 years I’ve been a professional Web Application Developer. Your mileage may vary.